http://oraclearchworld.wordpress.com/ Oracle SOA Reference Architecture By Kathiravan Udayakumar Introduction to SOA Service Oriented Architecture is a buzz word in IT industry for few years now. What is SOA? Do we really get benefited a lot by designing applications using this fashion? What is the business significance of this new architecture? Do we need to learn new languages in doing this? These are questions we like to discuss before getting deep into SOA. What is SOA? SOA can have different definitions based on the context in which it is viewed and applied. Application Integration Context: Service Oriented Architecture is a principle by which applications are integrated seamlessly using the services exposed from the application using a standard plug and play model. Application Design Context: Service Oriented Architecture is a principle by which the functionalities of the applications are exposed as a service to be consumed by applications to extend and reuse the features. Composite Application Context: Service Oriented Architecture is a principle by which distributed systems are built together to form a composite large system with fine-grained and coarse-grained services from different layers of the enterprise applications. Business Process Orchestration Context: Service Oriented Architecture is a principle by which the business process automations are built using the services exposed from the application to complete a business process transaction. Do we really get benefited a lot by designing applications using this fashion? Reusability and Loose Coupling are keys to design applications in Object Oriented world, this holds true in Service Orientation too and they are the corner stone for building SOA Architecture. IT has progressed through long way from creating languages for specific domains to generic purpose languages. This had led to application being developed using different languages in different platforms. With Advent of Java Virtual Machine the constraints to recode the applications to various operating systems was removed, which provided platform independency, but still the question of applications communicating to each other written in different languages exist before Service Orientation. Designing the application in service orientation fashion helps the application functionalities to be exposed to other applications and allow the application to be accessed from the external application or the integration components in a standard way.
Traditional P2P Integration Architecture The below snapshot shows the AS-IS ( Non-SOA Architecture). It is includes Be-Spoke and Stove-Pipe Architecture which are tight coupled. It does not allow the applications to change independently and makes it complex for business to change and adopt new business process model and industry standards. Required agility in the enterprise cannot be achieved through this architecture. SOA Architecture helps to overcome this through Layered Architecture approach. 2
Lack of SOA Architecture & its Results Data Governance Challenges Poor Business Insights Poor Master Data Management and Information Governance Lack of Data Stewardship and Information Management. Poor Visibility into Business due to lack of 360-Degree View of Customer, Employee and Partners Information and Interaction Lack of Visibility into SCM of Business due to lack of Global Business Process Definition which cannot be achieved through P2P Architecture Technical Challenges Tight Integration leads to error prone Business Process Definition and Process Change. Too many integration Points to be managed and Developed. In-Efficient Partner Integration Lack of skilled workforce to meet complex integration requirements. Business Data from partners is non-standard format and lacks validation Standards that enable SOA Lack of visibility into Business Process definition of Partner which leads to mismatch fulfillment of regulatory needs. Standards that enable SOA are not evolved in a big-bang model, they evolved over a period of time and they contribute towards the SOA standards and its improvement. Below Table describe the list of very important standards that enable SOA. Standard Standard Description 1 WSDL Web Service Description Language is a XML based language used to describe about the service exposed by the application. 2 SOAP SOAP is a platform neutral transport protocol used to access remote service. 3 MTOM Message Transmission Optimization Mechanism. It is a method of efficiently sending binary data to and from Web services.
4 XOP MTOM is used with XOP, it is used to transmit larger messages. XML-binary Optimized Packaging is a means of more efficiently serializing XML Infosets that have certain types of content. This is used to optimize the XML data manipulation. 5 UDDI Universal Description Discovery and Integration is a specification provided to store the service information available in the organization. This is registry specification facilitates the registry, discovery and integration of services in a standard XML based implementation. 6 WS- WS-Coordination is the protocol used to describe about the Coordination context that needs to be co-ordinated between different services. 7 WS-Security WS-Security is a specification to apply security on the Web Services. 8 WS-Reliable Messaging WS-Reliable Messaging is a specification to describe about the reliable delivery of messages to different services or between services. 9 BPEL4WS BPEL4WS is new standard to defined to execute the Business Process using Web Service orchestration model 10 XML XML is a standard used to represent the business data in the industry standard fashion to exchange the information among the application. 11 XSD XSD is a standard to define the structure of an XML 12 XSLT XSLT is a standard used to describe the data transformation from one data format to other. 4
Principle Drivers of SOA Open Standards Loose Coupling Reusability All Service Components should adhere to Open standards to enable loose coupling and reusability. Oracle SOA Components adhere to below list of Open Standards very well accepted by most of the Software Product Vendors (XML,WSDL, BPEL, BPMN, JCA, SCA, SOAP) Loose Coupling can be achieved through designing services in an agnostic fashion to allow them to be composed together open standards. Composite Application can be achieved through SOA Components through loose couple architecture. Fine Grain and Coarse Grain Service designed and can be encapsulated through SCA model. Oracle SOA Components allows loose coupling and reusability of service through Service Definitions (WSDL, JCA, and SCA). Agility Abstraction Discovery Statelessness SOA Architecture style allows each component to change independently; it allows agility in business process change through technology components that adhere to SOA Standards. SOA standards provide ability to define business components in abstract form helps to provide a business view of the software components. Oracle BPMN helps to define the business process, executables Business Process (BPEL) can be extracted from this abstract form. Abstraction helps in extension of the business process and allows for reusability as well. Service Definition and UDDI Standards helps to achieve discovery of services.osr and OER helps in building Service Registry and Self Discovery of Services. Stateless in SOA is achieved through HTTP and SOAP Protocols.
Service-Oriented Architecture (SOA) Concepts We have discussed in detail about, what is SOA, its benefits, its significance and etc in detail in previous section of this chapter. In this section we will discuss the concepts that enable a Service Oriented Architecture. Service Oriented Architecture is broad term and concepts involved in enabling the technology require deeper understanding from various perspectives. Interoperability: Ability for the technology to interoperate with various application standards is one of the inherent characteristics that are required for enabling SOA. Web Service Description helps to achieve these characteristics for the enabling interoperability among various enterprise applications. Loose Coupling: Ability to independently operate the functions with minimal dependency is characteristic that need to be consider during the service design. Loose Coupling can be achieved through asynchronous interaction patterns among application. JMS and Oracle AQ can help in implementing such patterns in SOA architecture Reusability: Ability to reuse the services among different application functionality is required for the components to interact with the each other. This characteristic is also required for building composite application where the services from different enterprise applications are composed together. Granularity: Service should be defined with required level of granularity. Services should be designed at fine grain or coarse grain level based on the application of the service and layer in which the service would operate. This is an important characteristic of Service that needs to be identified during the service requirement definition phase. Versioning of Service: Versioning of the services are required for the services to be consumed and managed in right fashion.
SOA Reference Architecture The below snapshot shows layered SOA Architecture that allows integration of data across different domains of the enterprise through open standards. SOA Integration Layer SOA Integration Layer provides the features to define business object definition of business object attributes and business data and enable them as service through service enablement layer. Orchestration Layer helps to compose services to form composite services which can be consumed by different application client components. Data and Application Layer Enterprise Component Layer Data and Application is part of Service Provider Section of the SOA Integration Layer. They are source data for consuming applications. Enterprise Component Layer is a layer through which abstraction of data is achieved through various technology means such as EJB, COM, XSD, Canonical Object Representation and etc. This allows the Business Object Representation of data and application components.
Service Enablement Layer Process Orchestration Layer Presentation Layer Service Enablement Layer is still a Service Provider Layer in SOA Integration Layers. It provides the features to access the data and enterprise business components in a open standard fashion through Web Service Definition. OSB and native Weblogic WebService Definition techniques can be used in this layer Business Process Definition and Composition of the Services to form composite application can be achieved through this layer. Layer through which the data accessed through service can be exposed to the client application through portal; custom applications, Mobile Devices and etc. SOA Quality of Service Layer SOA Quality of Service Layers helps to manage the Quality aspects of the Services. The below snapshot shows the different functions of these layer which includes process monitoring; Policy management and SLA definition and management of the same.
Process Monitor Policy Management Alerts and SLA Management Service Monitoring is achieved through SOA Dashboard Provided by Product vendors such as Oracle Enterprise Console, SOA Management Packs, Service Dashboard in OSB and etc. Process Specific Attributes can be monitored using the sensor and logs that are generated from the application. Fault, Security, Performance and SLA Definition can be achieved through the WSM framework provided in most of the Products. WS-Policies can be used to support the Policy Management. SLA Definition can achieved through the SLA definition framework provided in most the SOA Products. Oracle Service Bus provides SLA definition criteria through OSB Console. Alerts can be raised when SLA s are not met. SOA Governance Layer SOA Governance takes care of managing People, Process and Technology associated in Service Oriented Architecture. SOA Governance is combination guidelines, process and tools to achieve high level of maturity in establishing SOA Practices in an Organization. Below snap-shots shows the various key components that define the SOA Governance Layer..
SOA and Externalization - Reference Architecture Standardizing internal process through SOA Architecture may not be sufficient to attain the higher state of maturity in SOA Maturity Model. Service enabling external communication with the business partner is also essential to attain this state. Below snap shot shows the reference architecture to establish SOA based integration for external communication. Service Enablement Layer Security Layer B2B Interface Layer Externalization Layer Service Enablement Layer is Service Provider Layer in SOA Integration Layers. It provides the features to access the data and enterprise business components in a open standard fashion through Web Service Definition. Security Layer is the layer through which data, message and transport security is achieved. B2B Interface Layer is the layer in which B2B specific protocol transformation of messages are executed and handed-over to Externalization layer. Externalization Layer is the layer through which external trading partner communication is established.