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 this blog I will talk about software componentization in general, why it matters and how to best use the capabilities provided by the SAP Component Model to build scalable and flexible Composite Applications.
Software componentization, also known as component-based development focuses on the structuring of software as a composition of individual reusable parts (components) that are assembled and bundled together to achieve the required business functionality of a given business scenario.
The whole idea of Software Componentization is structuring the individual building blocks of an application into separate and distinct components (Separation of Concerns) with well-defined interfaces and dependencies to ease the development, deployment and maintenance. By dividing the software project into components, you can organize them right from the start in comprehensible and reusable units. Components can use other components in a controlled manner or even encapsulate child components.
Why Componentization?
1.) Componentization aims to distribute the complexity of the whole application into sub components.
2.) Reuse: Reusable components can be directly fitted in-to new application to improve productivity and efficiency.
3.) Components contain encapsulated functionality so the overall supportability is improved. A shared set of proven components caters to both quality and maintenance aspects of development costs.
4.) Flexibility: The replacement of components (ultimately at runtime) enables to achieve scalability and extensibility.
5.) With more of integration tasks (with some of already available reusable components), TCD (total cost of development) can be reduced significantly.
In the same context, if we talk about Service Oriented Architecture (SOA), it is implicitly referring to componentizing the functionality within durable and reusable services.
SAP Component Model
The SAP Component Model is a component model to build applications on the Java 5 Enterprise Application Server shipping with SAP NetWeaver. It is based on dividing the source code of software applications into components in order to manage the life-cycle operations of software.
As Composite Application development is fully based on components, SAP NetWeaver Development Infrastructure with SAP Component Model is promoted way to organize and build Java based applications.
It goes beyond pure Java language visibility concepts by having different components exposing their functionality in the form of public parts, which provides more fine-granular control of access control lists.
The picture here shows SAP Component Model and its elements.
Till EhP1 (SAP NetWeaver Composition Environment 7.11), the composite application development starts from Software Components and these software components together comprise the final product. With the release of EhP2 (SAP NetWeaver Composition Environment 7.20), the topmost entity is called Product which can be created in Composite Designer and then referencing different software components into it.
Refer Composite Designer (Major Part of SAP NWCE) and Do you Know Composite Designer for complete information about Composite Designer.
How-to achieve a flexible Design
The whole idea is about making the life easier in the evolving world of changing business processes. Flexible application design makes it future proof when we developing-in agile methodologies or when facing change requests (CR). Technically, this is taken care of by the SAP Component Model, by using Software components (SCs) and Development components (DCs). These are the main elements which help composite applications to adapt to changes in an ever-increasing complexity of change. Ultimately these components can be extended and replaced to fit in the future requirements without re-writing the entire application again.
Software Components (SCs) are the components which are reusable units across different products. If a software component is already available for a part of the required functionality, it can be easily imported and integrated with other components. SCs are meant for deployment and installation. The functionality contained within a SC can be executed on a totally different server and can be shipped alone without affecting other components. As such, they are the smallest unit of providing patches, upgrades or enhancements from a life-cycle perspective.
A Development Component (DC) may be best described as an enhanced Java project (from an eclipse perspective) with additional metadata, public parts (describing the visibility and accessibility of Development Objects) and dependencies to other DCs. These are mainly development and build units. DCs are the components which act as a container for all kinds of source artifacts (Java files, deployment descriptors, dictionaries etc). The functionality exposed by a DC – via Public Parts - is encapsulated qualifies as black box for other components, which refer to the fact, that all other components can only access the objects which are exposed via public parts of a particular DC.
In nut shell, SAP Component Model emphasis on component based architecture which ensures flexible application design.
Finding the right balance between SCs and DCs can be quite challenging and is influenced by several factors. In the next blog, I will talk about application layering in general and cover composite application specifies, and elaborate on how to structure a composite application in conjunction with the SAP Component Model to achieve scalability and flexibility by applying loose-coupling principles.
- SAP Managed Tags:
1 Comment
