CSC/ECE 517 Fall 2009/wiki2 16 am

Why do we need SOA

The objective of building a system is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. To achieve this principle, we seek the idea of SOA.

Lets define SOA

So with this problem in mind, service-oriented architecture (SOA) can be defined as an architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.

Rather than defining an API or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services[1], which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

Design patterns

A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.

• It is a description or template for how to solve a problem that can be used in many different situations.
• Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
• Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation.
• Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Role of design patterns in SOA

When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions.

Categories of SOA Design Patterns

Category	Objective
row 1, Inventory Boundary Patterns	row 1, It enables you to build all of your services according to the same design conventions to ensure consistent and widespread inter-service compatibility.
row 2, cell 1	row 2, cell 2	row 2, cell 3

Category	Objective
Inventory Boundary Patterns	It enables you to build all of your services according to the same design conventions to ensure consistent and widespread inter-service compatibility.