Service Oriented Architecture - an Overview

In this article by Ayanthi Anandagoda, she makes a case for SOA, elaborating its principles and the underlying architectural style. This is an article that assumes no prior knowledge of the technology concerned and therefore ideal for the beginner.

Table of Contents

• Introduction
• The Traditional Approach and the Need for SOA..
• Services and Interactions
• Web Services
• SOA Infrastructure
• Principals of SOA
• SOA Benefits
• SOA Challenges
• Conclusion
• Bibliographies
• References
• Resources

- Introduction

The architecture of a software system specifies components and their interaction at a high level. In other words, an architectural definition describes the configuration of components and connectors of a system, in a structural and a behavioral view point.

Referred to as the next generation of distributed computing, Service Oriented architecture (SOA) is an architectural style that guides the creation of collaborative services that are loosely-coupled and independent of their implementation technologies. The creation of such an infrastructure gives rise to a new wave of IT, that brings IT investments more in line with business strategies, thus creating increased business agility. One of the major drawbacks of the more traditional approach to IT has been in silos of information systems, that cripples the business use of such systems. With integration as a forethought, SOA aims to provide an accurate and comprehensive insight into businesses and increased ROI in IT projects. The concept of service-oriented architecture is an evolution of much older concepts of distributed and modular programming and represents a model in which functionality is decomposed into distinct units called services, where a service can be classified as an automated computing action that provides computing logic to content. The story of Service Oriented Architecture is a powerful one.

- Traditional Approaches and the Need for SOA

The Object-oriented principal of hiding information at the object level, works well for all but small systems.The approach still causes integration issues for larger projects, when connecting large numbers of objects together. The granularity at which objects are created tends to makes dependencies between them, creating issues even with the presence of well-defined interfaces providing controlled access.

A different approach, that we refer to as 'component-based development', offers us better tools in managing such dependencies in large environments. A component is considered a group of objects working together designed to provide business functionality with Enterprise Java Beans, .NET and CORBA as examples. Component based architecture still struggles when presented with dependencies of enormous scale, where large numbers of clients operating on heterogeneous platforms attempts to communicate as one.

Why Now?

The notion of services sitting in isolation, awaiting interaction and the delivering of services on-demand  - may not have been so interesting a decade or so before. It is such concepts as low-cost bandwidth, dynamic content and a diverse collection of computing devices operating on arrays of different platforms that makes the proposition an interesting one.

- Services and Interactions

Fundamental building blocks of a service oriented architecture, are services. In layman's terms, a service is a unit of work done by a service provider to achieve a desired end result for a service consumer. Core assets of an IT system including legacy systems, data and packaged applications of yours and those that of your partners - all qualifies for services. In essence, an application’s business logic is modularized to represent as services in SOA.

When designing services to be exposed in a SOA, usability and re-usability requirements need to be analyzed with greater care. Interactions between service providers and requesters in a SOA occurs as well-defined message exchanges. With these exchanging of messages adhering to standards, service orientation binds together, disparate sources of information independent of their underlying technology, operating system or transport protocol. Further on, individual services can be aggregated in an incremental fashion, through orchestration, providing additional composite functionality with varying levels of service granularity.

- Web Services

Web services, is atechnology to deliver the architectural style defined in SOA. Although there seems to be a general confusion about the relationship between SOA and Web services, it is important to know that Web services are an implementation methodology that adopts standard protocols to execute SOA. With a diverse array of middleware platforms providing greater implementation vehicles for services, no one platform emerges as the winner. Web services intend to re-connect the fragmented middleware arena, making interoperability the highest priority.

Web services include HTTP as the primary network protocol, SOAP/XML for the payload format and WSDL to describe the service interfaces. They rely upon such universally accepted standards like XML and SOAP, to provide broad interoperability among solutions belonging to different vendors. Communication amongst consumers and providers of services, typically takes place in heterogeneous environments with little or no knowledge about service providers.

Sequence of Activities for the Creation and Consumption of Web services in a SOA:

1. A service provider creates a Web service
2. Service provider describes the service using a WSDL
3. Service provider registers the service within a registry
4. Service consumers lookup for services in the registry and obtain information required to consume the service (read the WSDL)
5. Service consumers locate the service and makes requests the service.
6. Provided the service requester agrees to the specification published by the service provider, the service provider will start serving client requests. Exchange of messages during these communications takes place in the form of SOAP messages.

- SOA Infrastructure

An SOA infrastructure must support all the relevant standards and runtime containers required. The complete Web services stack comprises of:

Simple Object Access Protocol (SOAP) and XML are the  two key pieces of a Web service. Simple Object Access Protocol (SOAP) is a protocol for initiating conversations with remote clients. Evolving from the structured representation of information, XML has now emerged as the structured representation of cross-application messaging within Web services and SOA. XML is also the foundation for the Web Services Description Language (WSDL). WSDL is a language that is used for describing and locating Web services. It specifies the location of a service and operations a service exposes. These self-contained and self describing application components communicating through open standards can be consumed by other services to create more composite services, as and when needed. Quality of Service (QoS) for enterprise services demand such requirements ranging from security to authentication and reliable-messaging, each defined using a related policy. Numerous specifications related to QoS for Web services are in development with standards bodies, like the World Wide Web Consortium (W3C)1and the Organization for the Advancement of Structured Information Standards (OASIS)2.

- Principals of SOA

For a pool of software components to passed as components belonging to service oriented architecture (SOA), the following guidelines are used:

Service Loose Coupling: The principal of service loose-coupling ensures, that services are decoupled from each other, in terms of location, protocol and time. Simply the use of Web services, does not guarantee loose-coupling. Belonging more in the "art" realm of subjective discussion, the following are some guidelines in producing software components that are loosely coupled.

• Service Abstraction that encapsulates logic: Services as abstracts of IT infrastructure representing functionality in terms of coarse-grained, self describing and self-contained components that offer clear business value.

• Well-defined, constrained user interfaces providing black box functionality to remote clients ensuring service Interoperability.

Service Re-usability: Naturally, we want to reuse existing functionality. With SOA, developers have only to figure out the interfaces for existing applications rather than writing new applications from scratch. The concept of re-use in SOA can be compared to the discovery that you can make an entirely new recipe from your existing condiments, much to the delight of your diners, where the diners within the context of a service oriented architecture are, business decision makers. Re-usability is augmented with technologies available to invoke service interfaces stressing interoperability.

Service Orchestration: Combining software components like Tinker Toys, is made possible with the concept of orchestration and choreography in SOA. These enable Web services to be strung together in predetermined patterns, with the ability to carefully coordinate these assemblies to form business processes. With WSDL describing service capabilities at an atomic level, orchestration provides ability to define richer behavioral characteristics for accomplishing larger business objectives.

Service Autonomy and Dynamic Discoverability: Services adhering to a service agreement, as specified in the service description using WSDL, is interpreted by a UDDI server in providing discovery mechanism for a published service. UDDI stores information on services including service location and invocation details.

- SOA Benefits:

The power and flexibility that SOA offer the enterprise is substantial and includes:

1. The ability for the unification of legacy and new applications including data, within and across organizations.
2. In the face of business growth and business change, traditional approaches to integration through code fixing proves tedious and time-consuming. With human resources still ranking the biggest IT expenditure SOA attempts to improve developer productivity replacing this code mesh with a direct and clean approach to integration through services and messages. SOA provides the opportunity for IT to create a more dynamic and collaborative application infrastructure.
3. SOA facilitates the evolution of implementation in services without affecting service interactions guarded by well-defined service interfaces. Fundamental to service-orientation model is the separation between the interface and the implementation, enforcing the avoidance of a single user interface becoming the only consumer of a given business logic. This greatly assists in supporting multiple client types and hence, possess no difference to a .net client accessing a service using http and the same service being accessed by a swing client via http.
4. Opportunity to build up a constellation of re-usable services (a service catalog) that effectively meets business requirements whilst safeguarding existing IT infrastructure investments.
5. Ability to build ad-hoc applications almost entirely from existing software services. The benefit of this code mobile approach is that you can innovate not just your products and services, but even your business model.
6. Ability for the creation automated services by automated services and consumable across different channels
7. Ability achieve enterprise quality services that are interoperable across vendor implementations. Thus breaking barriers that formerly existed with distributed architectures such as CORBA necessitating the decision to work with a single vendor's implementation of the specification.
8. The ROI on Web Services comes from the increased operational efficiency and reduced costs that are achieved by streamlining and automating business processes. Reduced application development cycle time, and increased reusability of applications in the form of services and reduced maintenance cost contributes towards cost savings.
9. Services built with location transparency accounts for higher scalability offering more options for load balancers in distributing service access.
10. Location transparency contributing towards systems with a higher availability factor.

- SOA Challenges

• The process of identifying potential Services is by no means an easy task and requires a fine combination of domain knowledge coupled with IT re-usability concepts and experience.
• Designing services that do not leak implementation details, that are pitched at the right granularity to create re-usable services can be a huge learning curve.
• Designing a well-balanced orchestration layer based on contract-driven messages and policies requires skill and creativity.
• Creating service contracts that empower both sides of ­­­­­­­­an interaction to understand the same definition of a given service can be tricky. Considerable effort is needed to make service contracts as abstract as possible to enable definition of alternative implementations possible.

- Conclusion

Instinctively, it seems appropriate for business executives to ignore IT architectural debates but SOA is one worth understanding. The notion of SOA is comparable with modern day business process outsourcing projects (BPO), where experts take on the burden of executing and maintaining services in their domain of excellence with others simply consuming them on based on agreements. The concepts of BPO makes business processes much more cost-effective, efficient and productive. In retrospect, service oriented architecture calls for increased business agility and improved IT productivity, more in line with Agile Methodologies such as extreme programming, in that it provides building software systems for environments where requirements cannot be very precisely laid out in advance or in those where requirements change frequently. Building and deploying applications using a service-oriented architecture involves loose-coupling of software components and adherence to standards in providing flexible, innovative and more responsive IT solutions for the business. Services are defined as a set of well-defined interfaces that are generic in nature.

Bibliographies:

1. The New Language of Business SOA and Web 2.0 - Sandy carter
2. Understanding SOA with Web Services - Eric Newcomer and Greg Lomow

References:

1. World Wide Web Consortium (W3C)
2. Organization for the Advancement of Structured Information Standards (OASIS)
3. http://www.developer.com
4. http://www.msdn.com

Resources:

1. http://www.infoq.com/presentations/anne-thomas-manes-business-soa
2. Open Source SOA Platform
3. WSO2 Registry
4. WSO2 Mashup Server

Author:

Ayanthi Anandagoda is a Senior Content Specialist at WSO2. ayanthi at wso2 dot com.