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