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
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/blog 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/blog 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?
- SAP Managed Tags:
