CSC/ECE 517 Fall 2010/ch6 6j ps

Introduction

SOA is an architectural approach to creating systems built from autonomous services.SOA brings the concentration to the integration of services to form an application. SOA usually seems like a natural development to all the existing methods to do enterprise wide integration of applications. Concepts of SOA like services, discovery and late binding etc are from older middleware solutions like corba. The SOA design principles too are similar to the previously existing OOA/OOD techniques like encapsulation, abstraction and well defined interfaces.

Need for SOA??

To appreciate SOA, one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture. Consider the example of bank.Say the bank is currently handling credit card division , and it developed a software to handle all its transactions. This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process payments and so on .Say at some later point of time, bank started debit card division and again now to handle all its debit card related functionality it need one more software and it does almost have similar functionality as credit card ,with some differences in functionality. Now the possible solutions bank can think in developing the software for debit card division would be :-

• Take same code and make changes to it : The problem with this approach is code duplication and maintainablity.Say if bug crops in one of the module we now need to change at 2 places one in credit card software and another in debit card software.If company thinks of developing the debit card software using new programming language ,then even code reuse is not possible.
• Object oriented approach of inheriting objects: One might say bank can use Object oriented approach and derive class and functionalities and so on.Even then we have problem with this approach, we can't tamper the existing credit card software and even maintainability is problem over here.As discussed previously, if bank thinks of writing new software in different programming language then this solution also gets ruled out.

This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service .Each service to exploit the functionality of other service communicates to it using languages like 'xml' as compared to function calls in convention programming language.With this approach we have many advantages

• Reusable code in the form of services: Code is reused in the form of services.
• Code is easily maintainable:- as functionality is offered as a service and it is single place .
• Support for legacy functions:We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
• Platform and language independant services - as services interact with each other through xml so there is no requirement of both functions in same programming language.

Without SOA

With SOA

Technical jargons associated with SOA

Lets explain this using the above example itself.

• Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
• Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
• Directory services: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.

SOA vs Enterprise Architecture

SOA to be understood well in the present scenario is often compared and contraseted with the enterprise architecuture frameworks. We would like to discuss some points about this here. EA is defined as "The EA discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals". So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and stratagies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.

Design principles of Services in SOA

Overview of key principles of services

• Service Loose Coupling - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
• Service Abstraction - service should be like a black box, it should hide the implementation details from the outside world.
• Service Reusability - services should be implemented in such a fashion that it should be more reusable.
• Service Statelessness - Service should be implemented in such a fashion that it tries to minimize the amount of state information it store. It should store the state information if its really necessary.
• Service Discoverability - Each service should be associated with meta data, this allows us to discover the service and what it does, its i/p requirements.
• Service Autonomy - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

Deep dive into some of the key principles involved in SOA

Following are some of the key tenets that needs to be discussed in details:-

• Boundaries are Explicit
  

A service's boundry is its interface to the outside world which is published using a WSDL(Web Services Description Language). Principles which we have to keep in mind while we design SOA systems which come under this tenet are, Services should be easy to consume. That is a developer should be able to write software easily by consuming the services. The services should be designed keeping evolution in mind. Services built should be granular so that they can be easily reused.

• Services are autonomous

Services are independtly designed, implemented, deployed and versioned. A designer should not make any assumptions about the service and its capabilites other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided. Services should be versioned independent of the systems that consume them.

• Services Share Schema and Contract, Not Class:

Make sure that a service contract remains stable and use the extensible properties of XML and SOAP(optional headers) to add any exceptions. We are refering to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.

• Service compatibility is based on policy :

WSDL can communicate only syntactic for consuming a service. Many cases this is not good enough especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the WSDL. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.

• coupling:
  

Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules. Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and so on.Good service in SOA should exhibit low coupling as in message coupling a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less knowledge of the recipient.

• cohesion

Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion: a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable. b)Sequential Cohesion: module does several tasks and that must be in order. c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

Design Patterns associated with SOA

Now Lets study some of the design patterns associated with SOA:-

• The Document Processor: The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

• The idempotent message: This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure impotency the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system

• Reservation: This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

References

• Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
• Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
• Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

External links

• http://en.wikipedia.org/wiki/Service-oriented_architecture
• http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html
• http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci929153,00.html