Arvind
Krishnan Ramesh
Saahil Khanna
Shriram Jayaraman
Sneha Bhandarkar
Arvind
Krishnan Ramesh
Saahil Khanna
Shriram Jayaraman
Sneha Bhandarkar
Service Oriented Architecture
New Models of Enterprise Architecture (Group 2)
Service Oriented Architecture
New Models of Enterprise Architecture (Group 2)

Service Oriented Architecture

Building an enterprise-scale software system is a complex undertaking. Despite decades of technological advances, the demands imposed by today’s information systems frequently stretch to breaking point a company’s ability to design, construct, and evolve its mission-critical software solutions. In particular, few new systems are designed from the ground up. Rather, a software architect’s task is commonly that of extending the life of an existing solution by describing new business logic that manipulates an existing repository of data, presenting existing data and transactions through new channels such as an Internet browser or handheld devices, integrating previously disconnected systems supporting overlapping business activities, and so on.

Service Oriented Architecture (SOA)
SOA is a way of designing a software system to provide services to either end-user applications or other services through published and discoverable interfaces. In many cases, services provide a better way to expose discrete business functions and therefore an excellent way to develop applications that support business processes.

SOA architecture adheres to the Four Tenets of Service Orientation.
Service Orientation (SO) is an architectural paradigm that employs the following four principles: 1. Boundaries are explicit 2. Share Schema and Contract, Not Types 3. Policy defines Service Compatibility 4. Services Are Autonomous
Principle 1 – Boundaries are Explicit
In this, services interact by exchanging messages. Each message exchange traverses boundaries and may have costs. Service orientation formalizes intentional and explicit interaction.
Principle 2 – Share Schema and Contract, Not Types
Services expose schemas defining data structures and contracts defining available operations. The Contracts and schema may be independently versioned over time.

Principle 3 – Policy defines Service Compatibility
Policy is the statement of communication requirements necessary for service interaction. Service capabilities and requirements are expressed in terms of a policy expression. A policy can contain multiple assertions.

Principle 4 – Services Are Autonomous
Autonomy and independence are not the same. Topology of a system evolves over time. Unlike OO, services do not share behaviour. Services gracefully handle failure.

Benefits of Service Oriented Architecture
Technical issues:
Integration time decreases and development time is also saved. It also serves as a future proof against new technologies. It also works in heterogeneous environment and supports new devices.
Business issues:
The benefits would be increased customer focus. It also services as a competitive advantage to out-deliver competition. It also increases the return on investment on the project.
Decreased cost
It reduces TCO and increase ROI on evolving systems. It adds value to core investments by leveraging existing assets. New systems can be built faster for less money because existing services can be more easily reused. It is built for flexibility and long term value of interoperability.

Productivity
It increases employee productivity by unlocking data, Building on existing skills and consolidating duplicate functionality.

Partnership
It is built for partnerships using standards based and business relationships expressed via service interactions. Integration is driven by what is needed, not what is technically possible.

Agility
Agility or, Built for change, helps applications evolve over time and last. This is done by abstracting the backend and replacing over time. It provides access to the business value, no matter what technology delivers it. There is focus on core-competencies. Use of incremental implementation approach is supported.

Shift to Service Orientation
Businesses use IT, both as a strategic change agent (for competitive differentiation) and as tactical change agent (for operational effectiveness) leading to a business transformation. Such a transformation is an evolutionary process that includes harnessing of technology, processes and people.
The shift to Service orientation is described in the table below: From | To | Connections is cost | Connections in value | Function oriented | Process oriented | Build to last | Build for change | Prolonged development | Incrementally deployed | Application silos | Orchestrated solutions | Tightly coupled | Loosely coupled | Object oriented | Message oriented | Service oriented Enterprise Architecture
Enterprise Architecture is the practice of applying a comprehensive and rigorous method to decisive a structure for an organization’s process, information systems, personnel and organizational sub units, to align them with the organization’s core goals and strategic direction. EA must adopt SOA as the architectural style for the organization to meet its stated goals and benefits. Analysis of as-is business, governance processes and the application portfolio are critical inputs in defining a roadmap. EA is a framework that covers all the dimensions of IT architecture for the enterprise, while SOA provides an architectural strategy that uses the concept of service as the underlining business IT alignment entity. SOA is applied to an enterprise by being adopted as the overarching style for any architecture within that enterprise – business architectures, information systems architectures and infrastructure architectures
SOA is an architectural strategy that helps achieve business alignment by taking a three dimensional perspective of the enterprise viz. technology, people and processes. Thus, A service oriented architecture is an architectural style for creating an EA IT architecture that exploits the principle of service orientation to achieve a tighter relationship between business and information systems that support business.
Thus, from this definition of service, service-orientation is a way of integrating your business as a set of linked services. If you can define the services (including the business processes that compose services) in each of your vertical and horizontal lines-of-business, you can begin to link those LOBs by composing their services into larger business processes. Likewise, you can decompose the main services of your LOBs into a set of more basic services that can then be easily recomposed either to change LOB processes, or to interlink your LOBs at a lower level of their capabilities. Similarly, you can use the same principles of composition to create links with your business partners to both automate those relationships and to gain more efficiency from them.
The next important step in SOA is to define what “service” is. An underlying premise in the application of SOA to information technology is the principle of loose coupling – that is, avoiding or at least encapsulating temporal, technology and organizational constraints in the information system design. This same principle applies also to our definition of service – the rules we use to define services in one context may not be applicable in another. What is important is that whatever definition we arrive at, it should originate from the primary concerns and constraints of that context. As a gross generalization, a service is a repeatable task within a business process.
SOA Value Proposition from Different Perspectives
To understand the complete value of SOA you have to look at it from different perspectives – from each of the perspectives of the major participants in the business-to-IT relationship. There are various degrees of adoption of SOA including, for example 1. Implementations of individual services in which your business experiments on a limited basis with the use of SOA concepts by building new service implementations 2. Service Integration in which your business composes services through business process flows or state machines to implement complex business processes. 3. Enterprise Wide IT Transformation where SOA concepts are exploited enterprise wide and pervade the business application deployments.

Logical Architecture Model
We will, however, initially focus on the parts depicted in light-blue in the diagram below – the boxes labeled, Interaction Services, Process Services, Information Services, Partner Services, Business Application Services and Access Services. These are the parts in which you will deploy application software to capture the domain logic specific to your business design.

1. Interaction services: Interaction services are about the presentation logic of the business design –components that support the interaction between applications and end-users. Interactions may be tailored to role-sensitive contexts – adjusting what is seen and the behavior presented to the external world based on who the user is, what role they are performing, and where they are in the world. 2. Process services: Process services include various forms of compositional logic – the most notable of which are business process flows and business state machines. 3. Business Application Services: Business application services implement your core business logic. These are service components created specifically as services within a business model and that represent the basic building blocks of your business design – services that are not decomposable within the business model, but that can be composed to form higher level services. 4. Information Services: Information services contain the data logic of your business design. On the surface, information services provide access to the persistent data of your business. 5. Access Services: Access services are dedicated to integrating legacy applications and functions into the service-oriented architecture. 6. Partner Services: Partner services capture the semantics of partner interoperability that have a direct representation in the business design.

Physical Topology of SOA

It consists of various components such as : a. f. Process server
g. Application Sever
h. Information integration server
i. Security server
f. Process server
g. Application Sever
h. Information integration server
i. Security server
Gateway
b. Firewall server c. Proxy server d. Portal server e. Management server

This is the blueprint of the physical manifestation of the SOA to be implemented on an enterprise level.