Composite Applications continues to make inroads
As I pointed out in an earlier blog http://www.infosysblogs.com/soa/2008/06/sca_java_ee_integration_spec_b.html, composite applications could also be understood as mechanism for enterprise application integration and come in various flavors basically differentiated on the tier at which the integration is taking place. JSR 168 and 286 (portlets and inter-portlet communication), enterprise mashups http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid), etc. are examples of integration happening at the presentation tier. COTS Enterprise Application (ERP, CRM, SCM, etc.) vendors such as SAP, Oracle, IBM, Mircrosoft, etc. came up with ready made composite applications and composite application development suites founded on the sound architectural principles of SOA. These represent integration at the business tier and employ process orchestration and enterprise messaging technologies.
The ready made composite applications work by sitting on top of existing enterprise LOB applications and databases and interfacing with these across interfaces (APIs) designed on SOA principles. SAP xApps http://www.sap.com/industries/oil-gas/pdf/BWP_xEM_29893.pdf is a good example of this style. SAP xApps application consumes web services exposed by the legacy enterprise applications from diverse business functions and creates composite services (using façade pattern) and assembles the services and the composites into the final xApp composite applications. This leads to reusability of existing legacy business logic as well as rapid time to market of cross functional business process through customization (extension of existing logic through more development) and configuration (setting of externalized properties with context specific values such as authorized user roles, exception handling logic, etc.).
Development of composite application from scratch would involve design of the custom business processes unlike the case of xApps where the process definition is provided out of box. It would also involve exposure of the legacy application functionality and data stores as service components which could become first class citizen in the composite application. For example, in SAP CAF http://www.sap.com/platform/netweaver/cafindex.epx the underlying business services are converted into Callable Objects by wrapping them with SAP CAF-GP libraries. Hence, components from diverse types of back end applications (Knowledge management, Business Intelligence, LOB application, etc.) and implemented using diverse technologies (EJB, .Net, Web services, etc.) can all be brought to the same page – Callable Object. Once we have the configurable Callable Object the SAP CAF –GP platform can use these to assemble a new business process.
The role of Service Orientation http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci1189356,00.html in the composite applications is very important. The participating components in the assembled composite applications are service components (SCA/SDO are standards in this space) and not necessarily web services. A service component can use any technology for implementation (and not necessarily HTTP, SOAP, etc. as connoted by Web services) the only important thing is the usage of service orientation principle http://www.soaprinciples.com/p3.asp.
We are also observing the emerging of composite application platforms on the Cloud http://cloudcomputing.sys-con.com/node/746658, http://www.cordys.com/cordyscms_com/composite_application_framework.php, http://www.informationweek.com/news/software/development/showArticle.jhtml?articleID=217701723&subSection=News
In my next, we will look at some of the other composite application platforms.
