Submitted on February 4, 2008 - 21:51.
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.
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.
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.
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, 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.
An SOA infrastructure must support all the relevant standards and runtime containers required. The complete Web services stack comprises of:
| Process | BPEL4WS (Business Process Execution Language for Web Services), WS-CDL (CHOREOGRAPHY DEFINITION LANGUAGE for Web Services), WS Mashup technology |
| Discovery | WSO2 Registry, UDDI (Universal Description, Discovery and Integration) |
| Description | WSDL (WSDL Web Services Description Language) Messaging – XML (Extensible Markup Language) + SOAP (Simple Object Access Protocol) |
| Transport | HTTP (Hyper Text transfer Protocol), FTP (File Transfer Protocol), JMS (Java Messaging Service) |
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.
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.
The power and flexibility that SOA offer the enterprise is substantial and includes:
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.
Ayanthi Anandagoda is a Senior Content Specialist at WSO2. ayanthi at wso2 dot com.