SOA ARCHITECTURE APPROACH

TABLE OF CONTENTS SOA ARCHITECTURE APPROACH ............................................................................................................................1 1. 1.1 1.2 2. 3. SOA HIGH-LEVEL ARCHITECTURE .............................................................................................................2 SOA ARCHITECTURE GUIDING PRINCIPLES ..................................................................................................2 SOA IN DETAIL.............................................................................................................................................2 SOA ARCHITECTURE .....................................................................................................................................4 SOA RECOMMENDATIONS ............................................................................................................................5

1. SOA HIGH-LEVEL ARCHITECTURE

1.1 SOA Architecture Guiding Principles
Architecture Principals Loose Coupling Message Model Separate the interface from the implementation. If a service implementation changes, the clients are not impacted. There will be a standard set of messages that are sent and consumed by Services. This should be aligned with the Enterprise Data Model from a large grained entity perspective, but not tightly coupled. Services will be created that can be consumed by multiple clients, both internal and external. The architecture standards should simplify the way that systems are created, but not over simplify which could limit extendibility. The architecture standards should support flexible designs that can be easily updated to respond quickly to business requests. Architecture standards should enable QTR systems to be better aligned with the Business. The architecture standards should result in more efficient software development which reduces IT costs.

Reuse Simplicity

Agility Alignment with Business Reduce Costs

1.2 SOA in Detail

Service-Oriented Development of Applications is estimated to reduce total IT expenses over the long term by as much as 20% compared to traditional development methods and the savings becomes exponential over time as library of business services expands and greater degree of reuse is achieved. The main principle of SOA is to deliver software components in form of web services - small, selfcontained modular applications that support direct interaction with other software agents through exchange of XML messages in a platform and programming language independent manner. SOA have experienced many of the following benefits: Technology Perspective More flexible architecture Integration of existing applications

Improved data integration Supports business process management Facilitates enterprise portal initiatives Speeds custom application development

Business Perspective More effective integration with business partners Support customer service initiatives Enable employee self service Streamline the supply chain More effective use of external service providers Facilitate global sourcing

RESTful WebServices The WebService based integration was chosen, because it allows for integration of heterogeneous tools and platforms, both web based and desktop applications, both internal and external. Web services are often used to implement a SOA. In terms of implementation and invocation, the REST architectural style was chosen. With REST (REpresentational State Transfer), all service interfaces are resources accessible by URLs, HTTP is used for service invocation, and XML for encoding the response from the web service, according to agreed XML schemas. All web services (URLs) are fixed, and no dynamic registration and discovery of web services will be implemented initially, all web service APIs and their location are assumed not to change. RESTful web services have several advantages over SOAP ones, especially due to its operating straight on top of HTTP: require little infrastructure support apart from HTTP and XML which are supported by most programming languages, operating systems, servers Proven scalability, simplicity and low performance overhead.

RESTful web services communicate with the UI via HTTP APIs have been implemented on top of business layer, in the form of RESTful web services Every resource is uniquely addressable through an identifier which follows the universal syntax of hypermedia links (i.e. URIs). Communication is stateless, i.e. the server treats each request independently from previous one and does not store state information between requests.

2. SOA ARCHITECTURE

SOA is a business-centric IT architectural approach to integrate business processes through the implementation of repeatable tasks. Patni will expand its use of services to meet the business needs of the enterprise and promote reusability. SOA architecture has been divided into 3 layers Presentation Layer Service Layer Business Layer

Process Flow 1. The end user will send the request from UI(Presentation Layer)
2. Then the request will be routed to Service Layer and the basic functionality is provided as common functions for accessing the Business layer via Restful Invocation (e.g. retrieving and storing information KM). 3. Common Security framework having the capabilities of Identification, Authentication, Authorization, Integrity & Confidentiality will be delivered across the layers of SOA Architecture

4. Policies and Validations can be handled in the Validation Layer where Business Rules can also be configured to validate the data. Each and every request will be handled at the validation layer that avoids business layer involvement.

5. Data modeling and transformations can be handled. An XML-centric transformation from xml format to another is essential. It is an actual core layer, where in all the data will be sent to business layer and response will be sent back to UI. 6. The Business layer consists of actual legacy java implementation and service layer will communicate using the APIs that are already developed

3. SOA RECOMMENDATIONS
SOA can be applied to OMD architecture as follows:

ESB based services design Rules engine can be an ESB based service, XML/JAVA ESB service,
data services, external system integration services will be bound to ESB as a service which provides higher flexibility, extensibility, scalability and maintainability.

Applying SOA patterns OMD system can be a layered application separating the business,
service and data layers by defining business processes within different sub systems, service contracts, lifecycle definitions and generic data modeling.