Wednesday, October 18, 2006

Composite Services Vs Composite Applications

Recently one of my friends questioned me what is the difference between composite services and composite applications. Are they same ?. If they are different, what is it?

On top of my mind, I could say both are different. But I couldnt explain it very well.

When I did some (re)search, this is what I understand - Composite services are micro-flows. When multiple elemental/basic services are combined to be offered as a single service, then it is called as a composite service. These services are stateless, unlike 'Process' services where also orchestration of services takes place, but in stateful nature.

While composite service is a design pattern in SOA, 'Composite Apps' looks like a new way of 'architecting solutions'. There are several vendors in the market who provide tools & platforms for building composite applications.

Typical example, that I find in many sites - is integrating the set of distinct applications used by a contact center representative in Banks/sales. Typically, the contact center agent needs to shuttle between multiple applications in his desktop to service a client. The service process might include - duplicate entry of customer data, different security levels, fragmented/manual steps. How nice would it be, if the contact center agent gets a single unified application interface that enables him to accomplish the business process?. How good it would be, if the agent doesn't need to switch between apps to accomplish a task/process?. The solution cannot be just a 'dashboard' that provides links to access multiple apps via single interface. The solution needs to be much more intelligent in terms of automating steps, encapsulating business rules, eliminating redundant data entries, seamless integration of back-end systems, seamless presentation flow across different apps.

Ok, now you may be wondering, this is what 'Portals' are supposed to accomplish. Yes, Portals can also be the platforms of composite applications. But so, far Portals have been used only as 'Dashboards' or 'Lightweight EAI' of applications. It has not been utilized to an extent where Portals can be used to automate a complete business process, where each step of a process, draws logic from several layers (presentation, business logic and data access) of participating discrete applications.

But, the apps need not be always built on 'Portals'. It can be built as a 'Desktop' solution as well. Some of the tool vendors promise to integrate the native user interfaces of participating applications (thick client/green screen emulators) in a composite application.

The Gartner definition of Composite applications goes like this - "Composite applications differ significantly from multistep processes because they integrate vertically among the tiers within one step of a business process, rather than horizontally across multiple steps".

Some of the characteristics of composite applications are :
- Built on SOA standards
- Integrates with various enterprise applications
- Model driven development, minimal coding
- Applications can be assembled from reusable artefacts that are already available in the enterprise.
- Can include Workflows, BPMs, and Microflows

While there are many vendors out in the market, there seems to be little emphasis on 'Standards' for building those apps. While Portal standards JSR-168 has been enhanced to include inter-portlet communications, that is vital for building composite apps, Other forms (e.g Desktop) of composite apps remain properietary solutions of vendors.

No comments: