The 'Composition Application - Missing Manuals' initiative hosted on the SDN Code Exchange Platform aims to create a productivity starter kit and sandbox system for the development of Composites by providing technical libraries and an easy demo app documenting its features & how-to use them.
Links: Composition Application - Missing Manuals | Twitter
In Composite Application Layering Part - I of this series, we have seen how important the structuring of Software Components (with respect to Composite Application) is and why it is important for flexible architecture to be able to evolve in the future. In this second part of the series, we will have a detailed look on componentization of Development Components.
How Development Components (DCs) should be structured?
Till now, we have discussed how-to define the different components (SCs) that the application will be made of. The next question is how-to structure the source code into different Development Components (DCs).
SAP NetWeaver supports separate DC types for different use-cases. For example, all Process Content is located in a Process Composer DC; all Web Dynpro content is part of Web Dynpro DC. The picture shows all available DC types with in SAP NetWeaver CE 7.1 EhP1.
A DC is the very initial thought to plan for reusability. For example, separate DCs should be created for generic functions (such as utility classes) so that they can be reused across all layers. After a change, the entire DC must be rebuilt; therefore we also have to take care of the size carefully so that it does not contain too many objects. It’s preferable to have a fine granular DC structure but don't overdo it either.
Next I am going to explain the recommended DC structure for the Software Components typically found in most applications – Common/Model, Business Logic and the UI.
First, we will see how the content should be structured within the Software Component that contains the domain model and the common utility classes (think of logging, tracing, formatting etc). All the stuff of this nature goes to a separate DC (utils).
Domain models (Application specific models) are typically Java beans describing the structures and data types, which comprise the Data Transfer Objects (DTOs) across different layers, therefore it is really recommended to put all domain models into separate DC (model). These structures should be independent from backend systems; preferably Global Data Types (GDTs) as defined by SAP.
For a composite application to interact with backend systems, we need to define the service contract (interfaces). It is always preferred to separate the implementation from its interfaces in order to allow customers to come up with their own implementations and replace the default ones, therefore a separate DC (srv interfaces) is introduced for the service contract definition. The core business functionality of the application implements the data from the backend systems based on this contract definition.
The recommended DC structuring of the Common/Model Software Component is illustrated below. We need to deploy all these DCs, so we need a deployment unit (app) (EAR Project) for all this content. This deployment unit will also act as facade for all the contained DCs in order to minimize the number of direct point-to-point dependencies by leveraging a concept called Public Part Forwarding. The facade DC is responsible for all the communications to its internal DCs from outside.
On top of the Common/Model layer, we have the BL Software Component. In the example here I have combined Business Logic & Backend Connectivity Logic in one Software Component BL. However, this can also be split up into a separate Software Component (BC) depending on the requirements/size as mentioned above. The BC layer is responsible of retrieving/accessing the data from the backend systems or the persistence repository and mapping it to application specific model (from Common/Model).
The BL layer is solely responsible of processing the data. It really does NOT need to know how this data is fetched, which communication protocol is used to connect to backend systems or the like. Therefore interfaces defined on srv/interfaces DC will be implemented separately in bc/dao and bl/srv impl DC. The concrete implementation (residing in bc/dao) comprises the service contract implementation layer (SCIL). The bl/srv impl is the implementation of core business functionality of the application, which is used by the upper layers (UI). The UI layer should not directly depend on the BC layer; it is the responsibility of bl/srv impl to connect to service contract implementation layer.
The recommended DC structuring of BL Software Component is illustrated below. Finally, we need to create a deployment unit (bc/dao/app) (EAR Project) for the service contract implementation (bc/dao) and a deployment unit (bc/srv/app) for the business logic services. Again these deployment units will act as façades.
On the Presentation layer side (if Web Dynpro for Java is used), the recommendation is to place UI utilities, Web Dynpro models, Web Dynpro components, component interface definitions and Local Dictionaries in separate Web Dynpro DCs. Therefore, content related to UI utilities for example Object Work Lists (OWLs); error handling etc. should be combined in to a separate DC (ui/utils). It is recommended to create separate DC(s) (ui/model) for the EJB/WS Models (generated from the service interfaces). Finally the User Interfaces (WD components, Views etc) can be created in a separate WD Development Component (ui/xyz).
The recommended DC structuring of UI Software Component is shown below.
Distributed development with XXL projects
We have discussed the application structuring on Software Component level, now let’s have a closer look on the granularity of Development Components. Usually a big project can be split up into two or three main modules (for example master data and transactional data) and the teams working on these different modules may be distributed across different locations. If we split up some of the Development Components into two (or more) Development Components, the individual development teams can work on their own modules without the need of synchronizing and building the other DCs, which greatly speeds up the development. By having different deployment units one can deploy the stuff individually and keep the content separated from each other. As shown below, this kind of structuring is the most recommended way for the extra large projects especially in distributed development projects. Nevertheless, it always depends on various factors like team size, team expertise and of course the number of locations in distributed development projects.
To summarize it all, we have seen how the artifacts of a composite application should be structured according to the SAP Component Model. The more Development Components there are, the higher the time it takes to build all these components so there is always a conflict between optimizing either the number of DCs for the fastest overall build (as few DCs as possible) and the fastest build for developers (as many DCs as possible). By using Public Part Forwarding it is possible to change that transparently through-out the development phase as required in the current phase! The actual guidelines are highly dependent on the application use cases, but the build time and infrastructure aspects still have to be taken into account during the composite application structuring.
Outlook
In my next blogs, I will elaborate on how Development Components should interact with each other and how Deployment Units can help in reducing Point to Point Dependencies (façade paradigm). Stay tuned….
- SAP Managed Tags:
1 Comment
