CSC/ECE 517 Fall 2010/ch6 6j ps

From Expertiza_Wiki
Jump to navigation Jump to search

SERVICE ORIENTED ARCHITECTURE

Introduction

Service Oriented Architecture is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. 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 middle ware solutions like CORBA. The design principles of SOA too are similar to the previously existing OOA/OOD techniques like encapsulation, abstraction and well defined interfaces.

Need for SOA?

Now we know the definition of SOA from the previous section, with just the definition or 2 line statements we can't praise SOA . To praise and know the real power of SOA, one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. 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,a bank started debit card division and again now to handle all its debit card related functionality it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality. Now the possible solutions the bank can think of in developing the software for debit card division would be :-

  • Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules 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 the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.


This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like XML(extensible Markup Language) as compared to function calls in the conventional programming languages. 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 in a single place. It is also autonomous.
  • 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 independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability... As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).

Technical jargons associated with SOA

Before digging deep into SOA concepts like services ,design patterns associated with SOA , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.

  1. Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
  2. Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
  3. Directory services or Broker: - 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.
  4. Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
  5. Basic SOA MODEL:

This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

Design principles of Services in SOA

Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".

Overview of key principles of services

  • Service Loose Coupling - According to this principle, services 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 Re-usability - 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 stores. It should store the state information if it is really necessary.
  • Service Discover-ability - Each service should be associated with meta data, this allows us to discover the service and what it does, its input 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 the design principles of services

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

  • Boundaries are explicit

A service's boundary is its interface to the outside world which is published using a WSDL(Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and 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 independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities 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 version-ed 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 referring 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 syntactically for consuming a service. In 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 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.

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 high 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

With the background of general design principles of service from the previous sections now let's study deeper and more involved subject - "Design pattern associated with service" in this section.

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 we need to 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.

Example: Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified. According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output. Input for above example case would be, search term in the form of regular expression. Output for the example would be list of tweets. Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.


  • 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 idem-potency, 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.

Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost, so it tries to re-send the request. The problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be to design a service in idempotent fashion .In the above example the "oder request" service could be split into

  1. createOrder - it returns unique identifier for each request.
  2. setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent.


  • 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.


SOA vs Enterprise Architecture

SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture 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 strategies. 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.
Lets summarize some of the highlighting things and close this section Some of the similarities and differences between SOA and EA: Similarities:

  • Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
  • Both are used in the field of IT business and they align with IT business.
  • Both of them work using businness requirements/business objective as input.
  • Both SOA and EA need similar planning and strategies to work.

Differences: To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

Enterprise Architecture Service Oriented Architecture
EA deals with application frameworks and enterprise applications SOA's scope is on service modeling only
EA focuses on defining business components, SOA focuses on business services
EA addresses enterprise integration patterns and when they should be used. SOA provides an integration approach based on using services.
EA deals with enterprise-level infrastructure including servers, databases SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.


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

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch6_6j_ps&oldid=42749"