Download (direct link):
o Above and beyond the type of application server
envisioned for the operational environment, there will be special requirements and constraints concerning the existing operational environment. These requirements usually will affect the development of the assembly installation set and may affect the tuning of the assembly model at the UML level.
o In addition to standard application-server
features that are set in the UML model, a particular system environment may require special instrumentation to enhance monitoring and logging capabilities. This proprietary instrumentation can be activated via a separate module in a technology projection cartridge for a particular environment without polluting the standard-based aspects of the UML model. If these features need to be adjusted at the UML model level, then the modeling style also can be extended modularly to expose these features in the UML model view of the architectural IDE.
o Special accessors and utility components may be
desired to allow a portable diagnosis or runtime tuning at the level of convergent components, regardless of the underlying application-server infrastructure or the particular access channel.
■ Assembly components are designated as the intelligent deployment units in the architecture. In the default J2EE/EJB technology projection, these units are enterprise archives (EARs). In the case of highend J2EE/EJB application servers, EARs may be deployed automatically and configured into the J2EE/EJB containers via several paths, each path accommodating a particular phase of development and its deployment requirements. Assembly components can be generated to support three deployment paths: an ANT-script-driven deployment to be used for automated test cycles (such as assembly tests), a Java-IDE-driven deployment to support the implementation cycle workflow within the test environment, and a release-level deployment via the console of the operational application server to support the transition workflow and operational deployment.
■ After release, the steady-state operation of the assembly is handled by the assembly operator in coordination with the container operator. Two aspects are important when considering runtime monitoring and the adjustments to an assembly as a result of monitoring:
Chapter 6: The Development Process
o Some tuning parameters, such as EJB
transaction modes and caching parameters, which were set in the UML model and generated into the runtime infrastructure, may be modified in the runtime EJB container environment from the monitoring console. Based on changes in the runtime environment, these parameters may require short- or long-term adjustments. In the case of long-term adjustments, a change is also fed back to the assembly developer for a permanent change in the source model for the next release. More important, if a change in the runtime environment is dubious or uncertainty exists regarding its possible side effects, the assembly developer can provide proactive, high-quality advice based on the originating UML model.
o The convergent components are visible in the
management console of the application server. Here again, their convergence with the upstream models simplifies the monitoring and feedback channels. All stakeholders can communicate rapidly and unambiguously the source of problems to the responsible organizations. This is so because the convergent component is visible, so its resource owner, beginning with the assembly developer, is also clear. Also, the component in question can be located and inspected easily at any position along the development stream. This enables more rapid and professional responses to problems and suggestions from the field.
■ Lastly, feature requests and major change requests may
arise during the deployment and monitoring activity. Requests not willingly absorbed by assembly development teams are relayed to the requirement manager, as described in the global requirement management activity previously.
This chapter covered the system development process aspect of the Convergent Architecture. This is known as the CA process and is the third and last component in the development model. The introduction pointed out the rest of the architectural style, which enables both the optimization and simplification of the development process. This simplification is due to the inherent continuity between all elements of the style, a property referred to as reference-frame continuity.
The CA process is not a new development process; instead, it is a derived refinement of several other modern process frameworks and methodologies. Above all, it is a style-specific instance of the RUP (Kruchten 1998). In addition, it was influenced by OPEN (Graham 1997), EPM (Gilb 1988/1999), and catalysis (D'Souza 1999).
As an instance of RUP, the CA process consists of workflows that are subdivided into activities. The workflows are organized in terms of two major categories: