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
Think about loose coupling from the start!
In my Flexible Design - Know Componentization and SAP Component Model, I have talked about componentization; why it is important for flexible design and why it is vital to take care of it at the beinning of a project. In today’s blog post of two part series I will provide architectural recommendations on how to best use the SAP Component Model to structure an application (particularly composite application) in a loosely-coupled, extensible and flexible manner.
The entire idea about application structuring is Separation of Concerns (SoC). Maintaining separation of concern is one of the key concepts to achieve flexibility. SoC enables us to break down the complexity of a particular solution into easier-to-solve sub problems.
Definition of SoC according to Wikipedia: “In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible.”
Based on this definition we will discuss in this blog series how- to best use the SAP Component Model to break the application behavior/features (Concerns) in to different components (SCs & DCs). The entire idea of componentization revolves around the concept of Innovation without disruption. You might be interested to read about Enterprise Innovation by steinermatt/blog in First SAP Mentor Initiative quarterly magazine which can be found here.
Applications should be built based on this design principle to be able to evolve in the future. It should be easy to replace one component with another (without affecting the other parts of the application) according to business needs.
How granular Software Components (SCs) should be?
Before we start, let’s have a quick recap on the concept of Software Component; it represent both the installation and deployment unit and comprise the smallest package of functionality that can be shipped individually to the customer. The first question during application design is how many Software Components one shall use. The granularity to apply on Software Component level depends on various factors. One of the most important ones is application size. A close second is life-cycle operation considerations; one may need to be able to maintain separate code-lines/releases, so it is always a good idea to have a fine granular structure of the application to cater to this aspect and to be able to only branch the SCs that really differ from one code line to the other.
Usually a SC should be created if different parts of the application can be executed on different servers or if these parts can be deployed independently of each other e.g. if some of the functionality is optional.
For (very) small applications (e.g. if you are developing a prototype or an in-house project) it may be pragmatic to only use a single Software Component (APP) as shown below to avoid unnecessary complexity.
If you are developing a customer project or a medium to large product you may want to consider separating the functionalities into more reusable and distinct components. In such cases you may be best advised to break down your SCs based on traditional application layering as shown in the picture.
Separate components such as BPM (Business Processes) and Portal should be introduced if these technologies are required by the application. UI is the container for the presentation logic, which is (just one) consumer of the functionality exposed by the BL (Business Logic) layer. (I emphasize on this aspect as treating the UI as just one possible consumer help to keep the right mindset to properly service-enable an application.)It is considered best practice to have a separate component (Common/Model) for common utilities/domain models used across all layers of the application as they provide the domain model , which the interfaces (and public API) is based on. Having a separate Software Component for Quality Management (QM) stuff (unit tests etc.) enables you to mark the QM Software Component as an internal component that is not intended to be shipped to the customer.
If you are building an extra large application, it may even make sense to separate the Backend Connectivity (BC) logic (including persistence) from the main Business Logic (BL) as shown in the picture. In this case having a separate Software Component for backend connectivity logic will route the application design towards flexibility and which can be replaced as needed without affecting the Business Logic layer.
To wrap up, these distinct components can be replaced as needed, they can be combined with other components and ultimately they can be reused across different projects. For example for the same business logic layer implementation there can be separate UI technologies which you may want to use in future. With the presented approach we also get the option to deploy the Portal Content on SAP NetWeaver 7.0 server and the rest of the application may be deployed on SAP NetWeaver CE 7.1 EhP1 or EhP2. (Prior to the Global Availability of the unified stack that is shipped as SAP NetWeaver CE 7.1 EhP3 lots of customers still have a central SAP NetWeaver 7.0 portals system.)
In the Composite Application Layering Part - II in this series, I will continue having a closer look on the componentization of Development Components.
- SAP Managed Tags:
1 Comment
