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 my previous arvind.goel/blog, I have talked about componentization, why it matters and why it is important for an Composite Application to be able to evolve in future. I emphasized on structuring the application code in different Software Components (SCs) & Development Components (DCs) following the design principles of Separation of Concerns (SoC) to achieve flexible design.
It is also important how these different components communicate. In today’s blog, I will focus mainly on how the components within a composite application should interact with each other.
Well, when we talk about the interaction between components within a composite application, we all know it happens through well defined interfaces in the form of Public Parts. Each DC exposes its functionality as Public Parts, which can be used by other components. Keeping this as a baseline, I would like to introduce the concept of so-called Façade DC. Façade DCs do not have any functionality to expose, but instead they act as Deployment Units and they are also responsible for exposing referenced Pubic Parts provided by the internal DCs within the same Software Component. This concept is known as Public Part Forwarding which I will describe here.
I will continue with the same example of Common/Model SC I have elaborated on in detail in my preceding blogs. As said, in this particular SC, each DC (srv/interfaces, model & utils) exposes a Public Part. These Public Parts should not be accessed directly from the outside (from other SCs). However, a façade DC (app) references these Public Parts and make them available for usage to the outside. Any component outside of this Software Component should define dependency to the Façade DC only and all the internal DCs should be unknown to outside world. This design enables us to achieve one more level of flexibility as the internal DCs can be replaced as needed (without modifing the Public Part definition) and this entire replacement is hidden from the consuming components.
You might be interested to read about various Dependencies between DC Types and their usage.
Below are the steps to define dependency to a component using Public Part Forwarding:-
- Each DC exposes its functionality with Public Part (say PP1).
- This DC restricts its usage only to current Software Component and marks it for entity forwarding. This can be done by adding the authorized component in the Permission tab.
- The Façade DC defines dependency to the internal DCs and exposes it as a new Public Part (say PP2). This Public Part should not have any access restrictions.
- Other components use the new Public Part (PP2) defined by Facade DC.
(For details about the Software and Development Components shown in the picture, please refer my previous arvind.goel/blog )
The above picture shows a detailed snapshot of a composite application and its components; how they communicate with other components using Public Part Forwarding. The picture highlights some of the important dependencies which are very common in a Composite Application. You might notice that UI does not define dependency on Business Logic layer, it directly implements the interfaces defined in srv/interfaces DC. Read How to leverage JNDI in Web Dynpro for Java to know how to avoid EJB model binding with Web Dynpro for Java and use plain JNDI calls.
Summarizing it, this kind (Public Part Forwarding) of structuring and dependency usges decouples internal DCs from outside components and reduces the amount of P2P (Point to Point) dependencies, therfore it is always a good practice and recommended way to communicate through Facade DCs.
This blog ends the current series of Composite Application layering. You may first want to read about Flexible Design - Know Componentization and SAP Component Model, then Composite Application Layering Part - I, then Composite Application Layering Part - II & finally DCs Communication described in this blog. If you’re interested to see this design principle being applied you may want to familiarize yourself with the of ‘DemoKit’ sample we are currently developing on Code Exchange. steinermatt/blog recently published a blog explaining its CompAppsMM #2 – Architecture Overview to get you started.
- SAP Managed Tags:
