Composite Applications

Transaction Management Issues While Dealing with Underlying Database and Proposed Resolutions in CE 7.1.1 SP03

Sunit K Roy — Mon, 23 Jul 2012 18:44:02 GMT

SAP NetWeaver provides a framework called the Composite Application Framework which supports the development of composite applications on SAP NetWeaver platform based on SAP assets like SAP ERP, SAP CRM, etc as well as non-SAP assets available in the landscape. This framework also comes up with a persistence layer for storing business data. Transaction management while dealing with business data is a major challenge. This write-up is about pinpointing some pain points in that area.

Business Case

Say, for example I have two CAF Application Services CAF-App Service1 and CAF-App Service2. CAF-App Service1 is calling several other CAF-App services having functionalities like Functionality1, Functionality2… for serving specific business purposes. Now say, CAF-App Service1 is calling CAF-App Service2 for the business functionality Functionality5 where business data needs to be updated in CAF-BO. But Functionality7 needs the updated business data that was updated by Functionality5 which is now not available because of improper transaction management.

Proposed Solution:

Terminate T1 transaction so that CAF BO “UPDATE” operation is completed and data is committed in database. Next call T2 transaction as Asynchronous call to execute CAF BO “READ” operation.
- The above solution could have potential performance impact since this change will impact many DCs and for every create/update operation an Async call has to be spawned leading to potential performance overhead.

For doing that we need to change the transaction type of the CAF Service Operation to REQUIRES_NEW.

2. Use Bean Management Transaction*

Write Annotation @TransactionManagement(TransactionManagementType.BEAN) at the BeanImpl class
Set autoCommit false
Write commit explicitly at the DAO class

DC Interplay and Public Part (PP) usage

Arvind Goel — Wed, 23 Mar 2011 01:05:06 GMT

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 blogs, 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 blogs )

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. Matthias Steiner recently published a blog explaining its CompAppsMM #2 – Architecture Overview to get you started.

CompAppsMM #2 Architecture Overview

Matthias Steiner — Tue, 01 Mar 2011 06:13:58 GMT

Ready-Set-Go!

Having set the tone in my CompAppsMM #1 – Mission Statement a few days back I now would like to get started and talk about the anticipated architecture of the 'DemoKit' sample application. As you remember, one of the main aspects of Composite Applications is their adaptability to change. It's that inherent flexibility of Composites that makes them a good long-time investment and fundamental cornerstone of a Service-Oriented Architecture (SOA). I already shared my stance on this topic in a recent article for the Release of the 1st Mentors Quarterly titled 'Innovation without Disruption' and I see little-to-no value in paraphrasing it here again. Hence, I refrain from repeating that particular topic... and directly jump to the architecture overview.

Architecture Principles

In principal, the 'DemoKit' application design is based on a traditional multi-tier model, which clearly helps to separate the individual concerns that Composite Applications (Composites) have to take care of. We have the good old-known layers for data access, business logic processing and presentation plus an additional process orchestration layer on top (for our BPM needs) - nothing overly fancy or innovative at this point. Sure, this design approach certainly qualifies as a seasoned one, yet it has been highly effective in the Java Enterprise world for years and proven to be a very robust and reliable blueprint to develop enterprise software.

The main idea is simple: we decouple the Composite from a concrete backend system or data model/type system by separating the data access from the business logic processing. This is the first of many level of abstractions we will apply that cater to our flexibility needs from the inside.

We invest into our SOA by steadily nurturing the repository of services/functionality available in our landscape by exposing the new business services provided by the Composite as Enterprise Services. These services comprise the public API of the Composite, which can then be leveraged and build-upon by additional technologies such as BPM. We will also provide means to alter and enhance the processing flow of the Composites by introducing ExtensionPoints that can be implemented by customers/ISVs in a modification-free manner on the business logic layer.

The API is also the foundation of the presentation layer and as such needs to be flexible enough to be tailor-fitted to individual requirements from multi-channel consumers (desktop, mobile, web apps or other composites.) With all the movement we see in the UI/UX domain these days it seems as valid as it ever was to aim for keeping the presentation layer as lean as possible. That being said, this design approach may speak in favor of shifting some of the controller coding (as in MVC) to a facade layer in between BL and UI layer.

Componentization

As you can see it all revolves around developing a new application based on a set of well-defined, re-usable and loosely-coupled components. Now, that we have come to a common understanding of the fundamental design principles of the application it's about time to map them to our tool set - SAP NetWeaver Composition Environment.

The recommend way of structuring your composite application is to leverage the SAP Component Model in conjunction with the SAP NetWeaver Development Infrastructure (NWDI.) My pal Arvind Goel wrote a series of blog posts on the topic on behalf of the CompApps initiative that I highly recommend:

(For those that prefer video over writing or those who want to get the full scoop I would like to mention the blog post by my fellow SAP Mentor Greg Chase who caught me on tape (or better 'on disk') just after TechEd. In our Video: Lost #SAPTechEd sessions – CD301 “Advanced Composite Patterns” about the Loose-coupling and strong bonding @ TechEd 2010 we talk about Componentization and its importance.)

Application Architecture

Based on the information provided in these blog posts the basic structuring of the 'DemoKit' application is as shown in the screenshot at the right. It illustrates a Development Configuration (aka development track) called CDEMOKT_dev, which consists of the following 7 Software Components (SCs):

[CD_DEMOKIT] This SC is special and only contains the Product Description of our Composite as required by the Composite Designer Perspective.
[CD_DEMOKIT_BC] All the connectivity and persistence related concerns are encapsulated in a dedicated Backend Connectivity (BC) layer.
[CD_DEMOKIT_BL] The business logic (BL) belongs here and the functionality is typically implemented based on Stateless Session Beans (EJB 3.0), which can be exposed as Enterprise Services.
[CD_DEMOKIT_CMN] This SC contains both the technical components (TC) as well as the domain model and service interfaces of the demo application. This will be the first Software Component we will setup as we follow a bottom-up approach. The application specific objects defined on this layer are used across all other layers and as such have been labeled as Common (CMN).
[CD_DEMOKIT_PL] We also separate the process layer (PL) which acts as a container for our BPM process models.
[CD_DEMOKIT_QM] This Software Component is the home of our unit tests and developer tools such as stubs, scripts and configuration tools etc. It may or may not be shipped as part of the application.
[CD_DEMOKIT_UI] The demo app ships with a standard UI (one to start with), which in encapsulated into a distinct SC as well based on our design principles.

We'll have a much closer look on all of these layers/components as me move along. Now that we have a rough overview about our main building blocks it's time to set the foundation of our demo application. As mentioned above, we do that from the ground up - in our case it means we will start with the common layer and more precisely the technical components (please see the screenshot below.)

In the past, we made very positive experiences in laying out this foundation first before expanding the development team. This way, all the required cross-cutting concerns have already been establish and are more likely to be used in a unified manner - by all developers.

That's important: the design of the application emphasizes on Separation of Concerns (SoC) and the development should be setup alike - to minimize redundant work. The sooner the tool set is in place, the higher the chance for broad adoption.

A word on the SAP Component Model and Code Exchange

As mentioned above, the SAP Component Model and NWDI are the recommended way of developing Composites and as such a solid understanding of these concepts is vital to get this important aspect of the application right. It's the first step of the development phase and if you don't do it properly at the beginning it may grow a very long tail. Therefore, we believe this aspect of Composite architecture is too important to be neglected.

Unfortunately, the current toolset around Code Exchange and the underlying Subversion source code repository does not yet provide easy means to use Software Components and Development Configurations. In the perfect world we would have a simple option that would allow us to import software configurations by using the standard wizard directly out of a Subversion repository hosted on Code Exchange. A fresh breeze of reality makes us realize that this day is yet to come and an evaluation of alternatives is required. Fortunately, the SAP NetWeaver Developer Studio (NWDS) provides simple ways to import Software Component Archives (SCAs) and we opted for leveraging this functionality and providing our 'DemoKit' application as SCAs.

I've written a short document that walks you through the process of importing the SCAs into your NWDS to get the 'DemoKit' app installed locally.

Next steps

So, in the next episode - which is already in the making - I'll get started with the COMMON and QM layer. True, we are not really moving in god speed, yet the steady and medium-paced progress should allow the interested followers to catch up on the reading, jump aboard and then move along. Such an excursion is always twice the fun when having good company, isn't it?

CompAppsMM #1 Mission Statement

Matthias Steiner — Thu, 17 Feb 2011 07:06:22 GMT

First things first

In my Composite Apps - The Missing Manuals I introduced the idea of "Composite Applications - The Missing Manuals" and the team behind it. In today's edition of my accompanying blog series I'd like to provide some more details and background information about the concept we have in mind. I'll talk about our vision and then discuss how we approach our first contribution to SAP Code Exchange.

One of the main motivations that drives the team behind the project is to roll-out our experiences gathered in the process of developing Composite Applications over the years. I'd rather avoid the term 'best practices' as there's a bad taste to it and may lead people to believe that there's such a thing as a silver bullet or one-size-fits-all solution. There is not! By that rational, all we can and want to offer is to share with the community what worked for us in the past - there is a great likeliness that it may also work for you or at least provides you with a wider spectrum of lessons-learned to make a more educated decision in the future.

From the Ground up

In a nutshell, our mission statement revolves around documenting our approach to developing Composite Applications based on SAP NetWeaver Composition Environment from the ground-up. As such, it has to be considered as a companion to other resources already available:

So, what is our unique selling proposition (USP) you may wonder? Fair enough.

What we want to accomplish is to develop a complete sample application that illustrates/demonstrates all aspects of developing this type of enterprise applications and to document this process in parallel. We are aiming for a holistic approach that does not only provide results, but also reveals the reasoning behind the design decisions taken.

We believe that flexibility is the key characteristic of Composites and as such some of the recurring terms we will elaborate on are Separation of Concerns (SoC), Aspects, Loose-coupling, abstraction and proper componentization. We have already started doing so by sharing some of these generic design principles that our sample app 'DemoKit' will be based on (please find the complete list of documents here.)

Technical Components

Now that you know what to expect it's time to have a closer look on the details. As always when developing a new application it is a good investment of time to think about the purpose of the to-be-build application for a while before getting started. In our case the 'DemoKit' application is supposed to be an easy and comprehensive demo application showcasing design patterns commonly used to develop composites.

It contains several technical components (TCs) that simplify the usage of cross-cutting concerns and hereby allowing the developers to focus on the business processes. The concept is to provide an application frame set that can be leveraged to more rapidly build applications without having to re-invent the wheel again in regards to all these low-level and non-business related aspects of software development. I intentionally avoided the term "framework" in my last sentence, as we certainly do NOT intend to build another framework on top of a framework!

Video: Lost #SAPTechEd sessions – CD301 “Advanced Composite Patterns”

As a matter of fact, flexibility (our highest-valued good) demands that the entire application is build in a loosely-coupled fashion. As such, every technical component is well-advised to be minimal obtrusive to the application that wants to leverage it. To our experience, a great way to achieve this loose-coupling between technical components and the embedding application is an AOP-like approach of treating cross-cutting concerns as Aspects. My buddy Shobhit has written a great introduction blog about this particular topic a while back: Lower the TCP!

In addition, you may also want to watch the Video: Lost #SAPTechEd sessions – CD301 “Advanced Composite Patterns” that SAP Mentor Greg Chase and I recorded after SAP Teched last year. In the second part/video of the session I talk about the topic of Aspectizing (around the ~ 9:30 minute mark.)

DemoKit Sample Application

But the 'DemoKit' is more than just a set of technical components. Much more. In order to demonstrate the ease of integrating the technical components with any given or to -be-created application we will develop a small sample application for this purpose. As we want the people to be able to focus on the technical aspects without being distracted by overly complex business logic we opted for a simple app. One of the most cost commonly found business object in enterprise applications is the 'business partner' and therefore it was a natural choice to build a business partner cockpit that allows you to search and maintain business partners. Maybe not the most original idea, but certainly one that helps lowering the entry-barrier. And... this scenario is ideally suited to demonstrate the flexibility of the application as we can easily connect various backend systems as data repositories.

Vision

Now, if that by itself didn't get you on the edge of your seats yet then let me share our vision with you. We envision the 'DemoKit' as a sandbox that can be used as a generic starting point to develop proof of concepts (PoC) using emerging technologies. We would love to see other people on Code Exchange to build on-top or around our 'DemoKit' and use it as an accelerator for their own proof of concepts and the like. It's a bold vision - true - but then... a wise man once said one needs to apply high standards in order to meet them.

Based on the flexible nature of the solution and the used concepts the 'DemoKit' allows to extend/replace components of the application in a modification-free manner. Connecting new UIs to the exposed business logic API such as Adobe Flash and Microsoft Silverlight are scenarios that come to mind instantly. Or what about creating a mobile (-friendly) front-end using HTML5 or jQuery/jQuery Mobile - or maybe even project Phoenix? The potential add-on scenarios are certainly not limited to the UI layer either...

Due to the Extensibility framework incorporated into the application it will be feasible to plug into so called extension points to alter or extend the processing flow. I already mentioned backend abstraction and the ability to provide alternative implementations of data provisioning. While the initial release will 'only' come with support for two alternative data repositories (ERP and CRM) in the near future we may see an implementation connecting to SAP Business ByDesign or any other system that exposes API to retrieve and manipulate business partners. The sky is the limit... :)

Next Stop - Architecture Overview

Alright, let's wrap it up for today... if you would like to stick around and closely witness our progress you may be interested in the next blog post of the series, where I'll provide an overview about the high-level architecture and a recap on Componentization. Stay tuned...

Composite Apps - The Missing Manuals

Matthias Steiner — Mon, 31 Jan 2011 02:21:15 GMT

Introduction

Today I have the privilege to officially announce the kick-off of the 'Composition Application - Missing Manuals' initiative!

Having build Composite Applications on all releases of SAP NetWeaver Composition Environment (NWCE) and its predecessors for several years now we - SAP Custom Development - have gathered a lot of experience in how-to develop this new breed of enterprise software. Since myTalking About Custom Composite Development in 2007 I've been actively rolling out our findings and learnings on behalf of the organisation and in 2011 we want to take our contributions to the next level with this initiative:

Background

Being the lazy developers we are, we try to do things right... and right-away? Right? Great ... thought so! :)

Now, while there's nothing wrong in writing a prototype or PoC - the opposite in fact - as long as they remain prototypes or PoCs and not suddenly get productized afterwards. I think we all heard about these urban legends talking about such incidents happening though... this is where we jump in by providing a toolbox of re-usable components, technical libaries and low-level utilities to get you kick-started!

Our DemoKit comes with several technical components as typically required in any project using NWCE and its core (Java 5 Enterprise Edition application server). The motivation for such a toolset is simple: without having to worry about basic cross-cutting concerns no more, you can exclusively focus on the business logic of your application. These components will be bundled up with a lightweight demo app illustrating and documenting how-to use and integrate them.

We are striving for high standards in both code and source code documentation and we strongly believe that proper documentation goes a long way. (One of rewarding aspects of proper documentation is the implicit permission to reply with RTFM - "Read The *Fantastic* Manual!" ;) ) We have already started our series of blogs providing background information and explaining some of the key concepts; for the complete list please refer to our documentation page. There is plenty of material lined up waiting to be massaged and we will continuously share this information with the SCN community from now on.

The Team

	Reema Mittal is a Senior Consultant at SAP Labs Custom Development. Currently, she is developing Composite Applications using SAP NetWeaver Composition Environment with a focus on JPA and WebDynpro for Java. Prior to this, she has worked on various development projects in the ABAP world in functional areas like finance, GTS, HR for 2 years.
	Katharina Seiz is a Solution Designer at SAP Custom Development. In this role she is supporting customer projects from evaluation to execution. She has more than 10 years of experience across a broad range of SAP technologies such as NW CE, WD4J, Java EE, SOA, BPM, ABAP and WD4A. As core member of the Technology Competence Team she is constantly pushing the edge with her focus areas being User Interface technologies and UX (User Experience.)
	Shobhit Garg is a Principal Consultant at SAPLabs Custom Development. In his current role he is actively engaged in developing custom applications on some of the cutting edge SAP technologies. Prior to this he spent close to two years developing the SAP NetWeaver Mobile 7.1 platform.
	Arvind Goel has been working on J2EE and composite applications developement since 2006 and involved in designing and architecting flexible composite applications.
	Jens Steckhan is a Solution Architect at SAP Custom Development. He has been programming Java from day one and has worked with a variety of SAP and mobile platforms. He is currently working on the integration of digital signatures and the new German electronic ID into NW CE.
	Matthias Steiner is a Principal Solution Architect for SAP Custom Development, where his role is to evaluate SAP's cutting edge technologies and transform them into real solutions for SAP customers using the potential of SOA and composite applications. As a core member of the Technology Competence Network within SAP Custom Development he has been pioneering Composite development since 2004 and has gathered significant experience in numerous enterprise-scaled development projects in both the ABAP and the Java world.

Composite Application Layering Part - II

Arvind Goel — Wed, 12 Jan 2011 19:27:26 GMT

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….

Composite Application Layering Part - I

Arvind Goel — Wed, 12 Jan 2011 01:24:52 GMT

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 Matthias Steiner 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.

Flexible Design - Know Componentization and SAP Component Model

Arvind Goel — Thu, 09 Dec 2010 13:17:52 GMT

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.

Building Extensible Composite Applications with SAP

Matthias Steiner — Mon, 05 Oct 2009 11:46:05 GMT

My whereabouts

Those who closey follow my blog may have been wondering about my lack of blogging in the last couple of months and the reasons behind it. Well, truth is... the fact that I haven't been as active as in the past in this regard does not mean that I have abandoned this aspect of my job - the OPPOSITE. In fact, I put it to a whole new level... I've been writing a book.

Writing a book

It all started around two years ago with my first few articles and blogs about the topic of extensibility in Java applications being published on SDN, which were well perceived by the community. Shortly after I found myself confronted with the idea about writing an entire book about the topic, which I just couldn't resist. So I jumped on the challenge...

I have always enjoyed blogging, discussing technical topics with my peers and sharing my thoughts and views here on SDN. Yet, writing an entire book takes it to the next level for sure. While I spent more than one late-night session seeing the project's steady progress kept me motivated. The excitement of getting the chance to write an entire book - especially for such a reknown publisher as SAP Press - kept me going for the last couple of months.

The positive feedback I received from my colleagues who reviewed the individual topics rest-assured me that I was on track with my vision of writing a book that offers a unique selling point. Not only does the book cover various extensibility techniques in great detail, but I also managed to incorporate my knowlegde gathered in over 5 years of Composite development projects. As such the book provides insight on best-practices and proven design patterns that help to build flexible Java applications. Despite the title I did not solely focus on extensibility techniques exclusivly, but also point out other topics and concepts typically encountered during Java development projects based on SAP NetWeaver Composition Environment.

Feedback welcome

Enough of the advertizing now... in fact, the main motivation for today's blog has been to setup a place for discussions about the book. I explicitly want to encourage all my readers to post their feedback and questions here. The more, the merrier! :)

PS: Oh, I almost forgot... now, with the book getting into print these days I hope to get back to my routine of blogging on a monthly basis. The potential topics have been pilling up on my desk over the last couple of months and I sure got some very interesting articles up my sleeve... stay tuned!

Extensibility Sessions at TechEd'09

As personally I will not be able to attend TechEd this year due to other assignments I'd like to take the opportunity to refer you to some of the sessions presented/hosted by my colleagues that cover the topic:

BPM300 - Architecture Guidelines (Oliver Mayer, Volker Stiehl)
CD267 - Java Extension Configuration Framework in SAP NetWeaver Composition Environment(Raphael Vogel)

BPM360 - Composite Application Development: the Business Objects and Services Layer (Katrin von Ahsen, Stefan Henke and Volker Stiehl