Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

convergent architecture Building model driven J2EE Systems with UML - Hubert R.

Hubert R. convergent architecture Building model driven J2EE Systems with UML - Wiley publishing , 2002. - 289 p.
ISBN: 0-471-10560-0
Download (direct link): convergentarchitecturebu2002.pdf
Previous << 1 .. 62 63 64 65 66 67 < 68 > 69 70 71 72 73 74 .. 142 >> Next

-118-
Convergent Architecture
Chapter 4: The Convergent Component Metamodel
differentiates itself from run-of-the-mill code generators by providing expert tuning of the features of a particular J2EE/EJB implementation. Such tuning is complex but important because the various J2EE/EJB application servers do differ significantly in the implementation and tuning of their standard-conform J2EE features.
In the second approach, the same basic rules apply to processes and resources. Processes are, of course, much more challenging to map than resources. In fact, processes are the place where the most compromises must be made when using current J2EE/EJB technologies. Several major problems can occur when implementing EPCs (discussed previously) using current state-of-the-art standards and their implementations. These problems range from coordinating concurrency in the presence of isolated transactions (the so-called lost update problem) to the severe limitations on multithreading that arise as a side effect of transactional constraints in the EJB standard. The list of problems here is long and complex, but the bottom line is that without proprietary extensions, projecting processes modeled along the lines of EPC is out of the question. This is improving, but the currently available technology just does not make it possible using standard-compliant features. Instead, the modeling style in the second approach requires process models to be simpler. Currently, this translates to some restraints in the concurrency and asynchronous behavior of processes. Since the UML modeling style is explicit as to its capabilities, the architectural IDE can still check whether a process in the UML model complies to the specific constraints of a projection or not. The advantage of this approach is found in the long-term perspective. When standards and their implementations improve, the modeling style and the technology projections can cash in immediately on these improvements. This is so because they have not deviated previously from the mainstream flow. The restraint and resistance to the temptation of proprietary features can result in significant returns in the long run. The only prerequisite to this payoff is a clear, consistent path, a consistent architectural style.
[7]Object orientation adds three powerful modeling tools to traditional procedural representations. One of these tools is type abstraction, also known as inheritance.
The other two are class-level data abstraction (encapsulation) and function abstraction (polymorphism). See Taylor (1997) for a pragmatic introduction to these concepts.
[8]Another well-known style defines driving on the left side of the road as its standard.
[9]With respect to current OMG/MDA concepts, the business components begin with a core model at the level of a responsibility-driven design at the CRC business model level and evolve along a structured path, via mapping patterns, into UML along the course of convergent model refinement (see Chapter 6).
Utility Components
Utility components, short for technical utility components, are convergent components without any business-domain relevance. They are not (do not inherit from) business components and as such do not possess any predefined business behavior or relationships. Similar to accessors, utility components encapsulate external technology to explicitly ensure the integrity of the architecture. In contrast to accessors, the technologies encapsulated by utility components are
-119-
Convergent Architecture
Chapter 4: The Convergent Component Metamodel
coinstalled as part of the convergent system: They are either physically part of an assembly, that is, installed as part of the assembly, or they are part of the prerequisite installation platform required by the assembly.
Utility components are used to implement any purely technical aspects of a convergent system and to abstract the other convergent components from fast-changing aspects of implementation technologies. Thus, as shown in several of the preceding figures, a utility component does not normally implement a business dimension; its only active dimension is its IT dimension. Typical examples of utility components include logging facilities, administrative or monitoring facilities, security servers, key servers, and configuration servers used uniformly by all convergent components.
Summary
The convergent component metamodel presented in this chapter plays a major role in the architectural style. It defines convergent components as a vehicle to assist business designers and developers along the path from high-level business modeling to effective design representations to running IT systems.
The metamodel first defines how the concepts of convergent engineering, the UML standard, and component design standards such as J2EE/EJB are combined to model and implement convergent components. It partitions convergent components into architectural layers and specifies how each of these layers contributes to the model-centric development of a convergent system.
Previous << 1 .. 62 63 64 65 66 67 < 68 > 69 70 71 72 73 74 .. 142 >> Next