First SOA Success: Principles of Composite Application Design

Introduction
In a survey conducted on 106 organizations by Nucleus Research in 2007 to measure the success of SOA implementations, more than 70 percent of enterprises failed to achieve the desired ROI. While the reuse of published services is a major design principle in SOA, the survey found fewer than 35 percent of the published services get re-used. In order to successfully develop composite applications using SOA, organizations need to understand and effectively follow specific SOA design principles.

Composite applications form a good and simple proof of concept in adopting Service-Oriented Architecture (SOA) within an organization. Composite applications, if implemented properly, can work well for business users by making the user-interface navigation easy and less time-consuming. A composite application is an application built by combining functionality from various sources. The functionality can be taken from an individual source, an entire system, or application, whose output has been packaged as web services.

Oracle Application Integration Architecture (AIA) provides the framework for composite, service-oriented applications in the form of “Foundation Packs” on which they can be built.

Principles of Composite Application Design
Composite application architecture relies heavily on the following three principles: Service Reusability, Standardization, and De-Coupling.

Service Reusability
Reuse means putting existing software and knowledge to work to build new software. Composite applications save time and money by reusing existing logic and operations in an enterprise system. This can be in the form of components that are provided by a vendor or application, or of custom built services and methods. Oracle AIA process integration packs are an example of such system artifacts, which can be reused at different layers of the system, for example:

Integration/Orchestration Layer

Type of component	Oracle AIA/PIP Reusable Artifact
Connector	Technology and application adapters available Technology - DB, File/FTP Application - SAP, Oracle eBS
Business Objects	Standard EBO (Enterprise Business Object) definitions available More than 50 objects definitions available as of FP 2.2
Mapping	As part of Pre-built PIPs (Process Integration Packs)
Error handling	Error handling framework Notification Logging Retry
Testing	CAVS (Composite Application Validation System) framework Integration testing Simulation testing

Backend Layer

Type of component	Oracle AIA/PIP Reusable Artifact
Extraction Logic	Currently restricted to prebuilt PIPs Composite applications relying on AIA Foundation Pack have to create on their own ABCS (Application Business Connector Service) to extract the required data
CRUD Logic	Currently restricted to prebuilt PIPs Composite applications relying on AIA Foundation Pack have to create on their own ABCS (Application Business Connector Service) to perform the Create/Replace/Update/Delete operations

Composite applications need core functions like routing, error handling, security and metadata, which are all part of the Oracle’s AIA foundation pack. Services can be exposed and registered in a service repository called BSR (Business Service Registry). Business rules can be written using the Business Rules Engine provided by Oracle AIA. Similarly, orchestration of the services and processes can be performed using Oracle BPEL Process Manager (BPEL is the standard for assembling a set of discrete services into an end to end business process) which again is a part of Oracle AIA infrastructure.

Standardization
Oracle AIA is based on industry standards. At the message level, Enterprise Business Objects (EBO) support industry standards like Open Applications Group Integration Specification (OAGIS) and United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT). By using these industry standards, the canonical model exchange of information between applications inside and outside the enterprise becomes easy. For instance, if we are interested in integrating customer information across the enterprise, no change is required to the business logic on the participating application side. Applications participating in integration know how to process the message as long as industry standard format has been used for exchanging information.

Layer	Oracle AIA Supported Standard
Data	XML XSLT
Messaging	SOAP WS-Addressing
Service description	WSDL
Policy	WS-Policy
Security	WS-Security
Discovery	UDDI WS-Discovery
Management	WSDM
Orchestration	BPEL
Modeling	BPMN

De-Coupling
A composite application is said to be tightly coupled if one-to-one mapping exists between the data fetched from the end system and the data represented in the composite. In a one-to-one mapping, any change to one application would impact the other system as well. AIA provides a common data abstraction layer in the form of Enterprise Business Object (EBO) and Enterprise Business Service (EBS) and provides loose coupling between systems. By de-coupling, the requester system need not know the provider system details.

Conclusion
By following the three design principles of SOA — service reusability, standardization and de-coupling — enterprises have showcased quicker and more effective ways of adopting SOA using composite applications. Service reusability in building composite applications is bound to increase as Oracle AIA Foundation packs continue to built-in core components like EBO, EBS and other core services. Standardization also increases by adopting Oracle AIA based solution as Oracle AIA heavily relies on industry standards.

---

Ramesh Chandra Revuru is global head of Integration & Data Warehouse/Business Intelligence at Sierra Atlantic. He has published various articles on integration and was a speaker at the Oracle User Conference, TIBCO User Conference and Oracle Open World. Before joining Sierra Atlantic, he worked at Infosys, Computer Associates, and Oracle.