Composite applications have been talked about quite a bit in industry circles. How would you define the term?
A composite application is a transactional application consisting of business functionality and information from varied information sources. Composite applications are both a form of integration, as well as application development. They are designed to support a company's business processes and map them to underlying information resources. What is the role of composite applications in an SOA?
Composite applications are the end-products of a service-oriented architecture. They represent the business value a company derives from its SOA. Whether the composite application is designed for internal or partner use, it represents how any company can map business needs and processes to underlying information assets using SOA principles. What do you mean by business services?
While Web services do a great job promoting syntax and protocol-level communications, they don't yet provide a way to ensure semantic interoperability. The way a customer is defined in Siebel is very different from the way a customer is defined in, say, SAP. Customers need a way to resolve the data and process disparities between these different Web services into more useful business constructs that can be reused across different scenarios. The notion of business services does exactly that through the mechanisms of semantic leveling and right-sizing of individual Web services. For example, a business service can encapsulate incompatible and individual Web services that span the aforementioned Siebel and SAP systems into a common business concept like 'get customer information.' Various business services can then be assembled together to create composite applications. What should architects and developers be thinking about when embarking on a composite application project?
There are a few foundational elements behind any composite application. The first has to do with the building blocks of composite applications -- what we call 'right-sized' services or business services. Easily and visually building the business services that makes sense to an IT or business analyst is certainly important. Ensuring these business services are reusable across the enterprise via some form of meta data repository is also critical. Finally, providing the ability for companies to assemble these different business services together to form the actual composite application -- without coding -- is also critical. Traditional middleware products to integration are costly and complex to manage. How does a composite application framework simplify integration?
Composite application platforms eliminate a number of the issues surrounding traditional integration.
First, composite application platforms don't require that you copy data from one silo to another, as ETL [extract, transform, load] or EAI [enterprise application integration] products make you want to do. This forces you to keep the data in synchronization between a 'system of record' and a system that you are copying the data to, in order to enable integration. Instead, a composite application platform just gets pieces of data from the various systems of record, precisely and only when needed, to bring [that data] into the composite application for transactions at the time that transactions are taking place. Any data that needs to be written is written straight to the system of record. Composite applications eliminate the need for redundant copies of data, as well as the discrepancies that occur because of such copying and storing of data in multiple systems.
Second, anyone can build business services from the underlying Web services by hand, but that takes time. It's also more difficult to manage, and it adds complexity to the integration problem. Providing a visual means to build these business services and then assemble them together into composite applications is a significant step forward in easing integration challenges.
Finally, composite application platforms deliver a means to store and reuse all the elements, as meta data, associated with the end application. Specifically, they enable the reuse of the individual Web services -- the 'right-sized' business services -- the relationships among the different services, as well as the composite applications themselves. This facilitates rapid response to business change, the goal of every organization.
A composite application platform and an ESB complement one another. An ESB provides core messaging, transformation and routing capabilities, typically using Web services-based protocols. Composite application platforms can interact with the Web services-based messaging protocols that the ESBs support. What composite application platforms do is provide the business service creation and assembly capabilities, in a meta data-driven format, that ESBs don't provide. Your company, Above All Software, has something called a composite server. Can you describe this in further detail?
Developers have their favorite development tools and products, whether they are based on Java or .NET. So once you've built your business services in our environment and assembled them into composite services, we provide the ability for companies to expose the composite services, via Above All Composite Server, as WS-I compliant Web services that can then be consumed by any third-party tool -- whether Visual Studio .NET, Eclipse, Sun Java Studio, etc. Developers can then take these composite services, represented in Web service terms, and manipulate and deploy them within the context of their favorite tools. Major platform players are including composite application frameworks as part of their offerings. Take for instance BEA's AquaLogic and Sun's announced acquisition of SeeBeyond. What are the implications of this for companies like Above All Software?
All of these recent announcements have been extremely positive for us because they've validated and highlighted the importance of composite applications as a critical component of a company's SOA strategy.