标签：des http java os io for art ar
At a coarse level, AS 7 consists of two main elements:
The AS distribution also includes two clients for the management interfaces it exposes (a CLI tool and a web-based admin console). The AS codebase also produces implementations of the SPIs published by the Arquillian project, allowing AS7 servers to run Arquillian-based tests.
The core of the AS consists of the following primary elements:
Most of the functionality that end users associate with an application server is provided AS extensions. Most of the modules in the AS7 codebase are extension implementations, with each extension providing a coherent set of functionality. Many extensions provide support for some aspect of the Java EE specifications.
Extensions implement an interface (org.jboss.as.controller.Extension) that allows integration with the core AS management layer. Via that mechanism, extensions are able to
See the "Extending JBoss AS 7" document for more on extensions. See also https://community.jboss.org/docs/DOC-25627 for more on how extending AS 7 differs from extending previous versions of JBoss AS.
To better illustrate the AS 7 architecture, let‘s walk through the boot process for a standalone server.
When you run bin/standalone.sh from the root of the AS 7 distribution, the final effect is to launch a JVM using the following essential command
If you start the AS and use the ps command to see the actual JVM launch command, you‘ll see a lot of JVM settings (-Xmx and the like) and a lot of system property settings, but the above bits are the key information. Let‘s break that down a bit:
java -jar jboss-modules.jar
We can see from this that the actual main class the VM will invoke isn‘t in a JBoss AS library at all; it‘s in jboss-modules.jar (specifically, theorg.jboss.modules.Main class.) So, when you start the AS the first thing you are doing is setting up a modular classloading environment.
-mp modules
These are arguments passed to org.jboss.modules.Main.main(). The -mp is short for "module path" and the value is a path somewhat analogous to the value of an OS $PATH environment variable. Each item in the path is a location under which jboss-modules will look for a module when needed. If there is more than one item in the path, the items are searched in order, with the search ending as soon as the module is found. In this case there is only one item in the path -- the modules/ dir under the AS distribution root.
org.jboss.as.standalone
This is the name of a module located on the module path. This module will be loaded by jboss-modules. If you look in themodules/org/jboss/as/standalone/main/module.xml file in the AS distribution, you will see it includes this element:
When jboss-modules sees that element in the module.xml for the module passed to its main() method, it knows to load the specified class and to pass any remaining command line arguments into its main() method. So, now we have a modular classloading enviroment set up, and theorg.jboss.as.server.Main.main() method (found in the AS codebase‘s server module) has been invoked.
The org.jboss.as.server.Main.main() method does a number of things, but two are most relevant for people who wish to understand how to develop the AS:
The most important thing BootstrapImpl does is create an instance of the JBoss MSC library‘s ServiceContainer interface. A service container manages a set of running services. A service is simply a thing that can be started and stopped, with start and stop performed via methods specified in the JBoss MSC Service interface. A service also exposes a value of some type T via the Service interface‘s public T getValue() method. The value type T specified by the service is used by default by consumers of the service, and should represent the public interface of the service. It may or may not be the same as the implementing type of the service.
The ServiceContainer provides an API for managing services -- configuring and installing them, removing them, triggering start and stop, looking up already installed services, etc. Configuring a service can involve expressing the dependencies the service has on other services and asking that the service container inject the value of depended-upon services into the service before starting it. If a service depends upon another service, that other service must be successfully started before the service container will invoke the dependent service‘s start method. If for some reason the depended-upon service needs to be stopped, the service container will invoke the dependent service‘s stop method first.
The ServiceContainer maintains an internal thread pool. In order to achieve highly performant management of large numbers of inter-related services, activities related to starting and stopping services are performed as a series of concisely scoped tasks, with the threads in the thread pool used to execute those tasks. For example, executing a service‘s start method would be a task performed by a thread in the ServiceContainer‘s thread pool. Because of this fact, it is important to recognize that any activity related to starting and stopping services will be highly multi-threaded. For example, you can never assume that the thread that asks the service container to install a service will be the thread that calls itsstart method.
So, at this point in our boot, we have in place two of the four main architectural elements discussed in the "AS Core" section of the "High Level Overview" above: a modular classloading environment provided by the jboss-modules library, and a service container framework provided by the jboss-msc library.
Up to this point in the AS boot, all activity has been on a single thread, the JVM‘s main thread. In the BootstrapImpl.bootstrap() method, things get more interesting, since much of the remaining boot work involves installing services, with the ServiceContainer‘s thread pool threads doing the most of that work.
BootstrapImpl.bootstrap() installs two services:
The ApplicationServerService starts a number of other services in its start method. The most significant of these is the ServerService.
ServerService brings in the 3rd and 4th of the four primary components of the core AS listed in the "High Level Overview" above -- the extensible management layer and the deployment framework. For those of you familiar with the "Extending JBoss AS 7" document, ServerService performs many of the same kinds of activities an Extension implementation performs in its initialize(ExtensionContext context) method, but for the core AS management model:
ServerService implements Service<ModelController>. A ModelController is the central execution point for management operations in a managed AS process (i.e. a server or a HostController in a managed domain.)
In its start method, ServerService spawns a separate thread, the "Controller Boot Thread", which is responsible for coordinating the remainder of the boot. It does the following primary tasks
The tasks of the Controller Boot Thread are spelled out in further detail below.
The task of an XML parser for an AS7 configuration document (e.g. standalone.xml, domain.xml, host.xml) is to populate a list of management operations that should be executed by the ModelController to bring the process‘ running configuration in line with the xml. Each of those management operations has the same format as would be read off the wire if the CLI had sent an operation request to the server to invoke an equivalent operation.
The parser for the core AS xml namespace has some special behavior when it comes to parsing an <extension> element in the xml:
Once xml parsing is complete, a list of management operations is ready for execution by the ModelController. Each operation has the same format (address, operation name, parameters) as would be read off the wire if the CLI had sent an operation request to the server to invoke an equivalent operation after boot. The Controller Boot Thread asks the ModelController to execute the operations as a unit, with each individual operation acting as a step in the overall unit of work. Execution proceeds in 3 stages, with all steps in the overall unit completing a stage before execution on the next stage begins. (This execution pattern applies whenever any operation or atomic list of operations is invoked, not just during boot.)
Before the list of boot operations is passed into the ModelController, a check is done for operations that add extension resources (for example, using CLI syntax, /extension=org.foo.extension:add.) When one is found, the relevant Extension implementation‘s initialize(ExtensionContext context) method is invoked. This gives the Extension a chance to register its resource and attribute definitions and its OperationStepHandlers with the core AS management layer before the boot operations are executed.
The final steps in the AS 7 boot are to wait while the JBoss MSC ServiceContainer processes the installation and start of all the services added by the handlers for the boot operations. As discussed in the introduction to the ServiceContainer above, the start of services is performed by threads in the ServiceContainer‘s internal thread pool. Services are not started by the Controller Boot Thread. However, the ServerService attaches a listener to the controller object for each service; using this the ServerService is able to track when all services have reached a stable state. The Controller Boot Thread uses this facility to block until the ServiceContainer has stabilized. At that point, all services are either started or failed, and boot is nearly complete. The Controller Boot Thread switches the state of the ControlledProcessState service from STARTING to RUNNING, writes a log message reporting that the boot is complete, and boot is finished.
When you trigger deployment of some content, one of the management operations supported by the core AS management layer is invoked. The logic responsible for handling that operation will extract relevant information from the operation request (e.g. the name of the deployment) and will then install services into the AS‘s service container:
The RootDeploymentUnitService has injected into it a reference to all the DeploymentUnitProcessor (DUP) implementations that were registered by the core ServerService at boot or that have been registered by subsystems. The DUP implementations are grouped by the Phase of the deployment process in which they execute, and are numerically ordered within that phase. DeploymentUnitProcessors are organized in a chain fashion, with each DUP performing a limited set of tasks to help take a deployment from being a bunch of bits to being a set of useful services.
Deployment proceeds in phases. See the Phase enum for a listing of the phases. For each phase, a DeploymentUnitPhaseService representing that phase that is installed into the service container. Each phase service (save the first) depends on the phase service for the previous phase, and each phase service (save the last) in its start method installs the phase service for the next phase. The RootDeploymentUnitService in its startmethod installs the first phase service, which in turn depends on it the RootDeploymentUnitService. The effect of all this is if theRootDeploymentUnitService is stopped (e.g. by the undeploy management operation), this will trigger a requirement for the service container to first stop the first phase service, which will in turn trigger a requirement to first stop the next phase service, and so on all the way to the final phase service. The effect is the phase services will be stopped in reverse order from how they were started.
The primary thing the phase services do in their start and stop methods is invoke the deploy and undeploy methods of eachDeploymentUnitProcessor registered for their phase. The deploy method is invoked in phase service start and the undeploy method is invoked instop. For each deploy/undeploy call the DUP is provided with a DeploymentPhaseContext that provides context to the call and gives the DUP access to the service container, allowing it to install or remove services.
One of the tasks performed by the DeploymentUnitProcessors is to set up the modular classloading enviroment for the deployment. Each top-level deployment has its own dynamically generated module. For deployment types that include known subdeployments (e.g. an ear can include wars, ejb jars, etc) then in addition those subdeployments also get their own dynamically generated module. What other modules these deployment modules have visibility to depends on the requirements determined by the deployment framework when it analyzes the deployment content (e.g. by parsing deployment descriptors, reading manifests, or scanning annotations.)
The key actor in this process is the org.jboss.as.server.deployment.module.ModuleSpecProcessor, which is a DeploymentUnitProcessor. TheModuleSpecProcessor configures and installs an MSC service that interacts with jboss-modules to dynamically generate the deployment‘s module. Other DeploymentUnitProcessors that execute prior to ModuleSpecProcessor analyze the content of the deployment and add contextual information to the DeploymentUnit that is used by ModuleSpecProcessor to establish what other modules the deployment‘s module can access. So, for example, a DUP registered by the JPA subsystem might recognize that the deployment requires JPA support (e.g. by detecting the presence of a persistence.xmlfile) and record that visibility to the modules that provide the JPA APIs should be added. The effect of all this is the deployment‘s classes have access to an appropriate set of classes located in the AS‘s own modules or in other deployments, but do not have access to classes located in other modules.
原文：https://community.jboss.org/wiki/AS7InternalArchitectureOverview
AS 7 Internal Architecture Overview--reference,布布扣,bubuko.com
AS 7 Internal Architecture Overview--reference
标签：des http java os io for art ar
原文地址：http://www.cnblogs.com/davidwang456/p/3897582.html
