EA & Services Oriented Computing (SOC)

Services Oriented Computing (SOC)

By J. Schekkerman

There has been an increase in interest recently within the service oriented community towards "Service Oriented'' Computing. Services are often seen as a natural progression from component based software development, and as a means to integrate different component development frameworks. A service in this context may be defined as a behaviour that is provided by a component for use by any other component based on a network-addressable interface contract (generally identifying some capability provided by the service). A service stresses interoperability and may be dynamically discovered and used. According to the "Open Grid Services Architecture" (OGSA) framework, the service abstraction may be used to specify access to computational resources, storage resources, and networks in a unified way. How the actual service is implemented is hidden from the user through the service interface. Hence, a compute service may be implemented on a single or multi-processor machine -- however, these details may not be directly exposed in the service contract. The granularity of a service can vary -- and a service can be hosted on a single machine, or it may be distributed.

Web Services provide an important instantiation of the Services paradigm, and comprise infrastructure for specifying service properties (in XML -- via the Web Services Description Language (WSDL) for instance), interaction between services (via SOAP), mechanisms for service invocation through a variety of protocols and messaging systems (via the Web Services Invocation Framework), support for a services registry (via UDDI), tunnelling through firewalls (via a Web Services Gateway), and scheduling (via the Web Services Choreography Language). A variety of languages and support infrastructure for Web Services has appeared in recent months -- although some of these are still specifications at this stage with no supporting implementation. Web Services play an important role in the Semantic Web vision, aiming to add machine-processable information to the largely human-language content currently on the Web. A list of publicly accessible Web Services (defined in WSDL) can be found at www.xmethods.net. By providing metadata to enable machine processing of information, the Semantic Web provides a useful mechanism to enable automatic interaction between software -- thereby also providing a useful environment for agent systems to interact.

Service Oriented Computing: Objectives

Today we are experiencing a major paradigm shift in the way that software applications are designed, architected, delivered and consumed. Service Oriented Computing (SOC) is the new emerging paradigm for distributed computing and e-business processing that has evolved from object-oriented and component computing to enable building agile networks of collaborating business applications distributed within and across organizational boundaries.

Services are autonomous platform-independent computational elements that can be described, published, discovered, orchestrated and programmed using XML artifacts for the purpose of developing massively distributed interoperable applications.

The application of the service-oriented computing model to Web resources to provide a loosely coupled model for distributed processing is manifested by Web services.

Services are more than just software components; their platform neutral and self-describing nature and particularly their ability to enable business.

Combined with recent developments in the area of distributed systems, workflow management systems, business protocols and languages, services can provide the automated support needed for e-business integration both at the data and business logic level. They also provide a sound support framework for developing complex business transaction sequences and business collaboration applications.

Adopting the service oriented computing paradigm has the potential to bring about reduced programming complexity and costs, lower maintenance costs, faster time-to-market, new revenue streams and improved operational efficiency.

However, before the service oriented computing paradigm becomes reality, there is a number of challenging issues that need to be addressed including among other things service modeling and design methodologies, architectural approaches, service development, deployment and composition, programming and evolution of services and their supporting technologies and infrastructure.

Service Oriented Computing in the GRID community

There has been an increase in interest recently within the Grid community towards "Service Oriented'' Computing. Services are often seen as a natural progression from component based software development, and as a means to integratedifferent component development frameworks. A service in this context may be defined as a behaviour that is provided by a component for use by any other component based on a network-addressable interface contract (generally identifying some capability provided by the service). A service stresses interoperability and may be dynamically discovered and used. According to the "Open Grid Services Architecture" (OGSA) framework, the service abstraction may be used to specify access to computational resources, storage resources, and networks in a unified way. How the actual service is implemented is hidden from the user through the service interface. Hence, a compute service may be implemented on a single or multi-processor machine -- however, these details may not be directly exposed in the service contract. The granularity of a service can vary -- and a service can be hosted on a single machine, or it may be distributed. The "TeraGrid'' project provides an example of the use of services for managing access to computational and data resources. In this project, a computational cluster of IA-64 machines may be viewed as a compute service, for instance -- hiding details of the underlying operating system and network. A developer would interact with such a system using the GridSDK toolkit, derived from Globus, and consisting of a collection of services and software libraries.

Services Transition Path (STP)

Your SOE, SOA and SOC is very much a work in progress, and your transition to Services Orientation will take place over a long period, in many phases. Consequently, transition management is one of the most critical concerns in the long ramp-up to Service Orientation everywhere.

Despite the magnitude of a migration to a services-oriented platform, the continuing uncertainty of critical WS-* standards, and the often thundering impact of large-scale SOA deployments, now is the time to start considering the move. The key to a successful transition is to find a spot of calm amidst the storm of activity surrounding SOA, and develop an intuitive plan that will guide your organization through a path of technical obstacles, organizational resistance, and ever-shifting industry trends.

Invest in an Impact Analysis Before Developing the Transition Plan

In order to assess the feasibility of a transition to Services Orientation, you first need to estimate the real-world impact such a migration will have. Therefore, you should consider holding off any sort of planning until an initial impact analysis is complete. Using the impact analysis results as your primary guide, and factoring in budget constraints, related project requirements, and other external drivers (such as strategic business goals), you should be able to determine the scope of your planned transition. It is not uncommon for an SOA transition plan to apply only to a subset of an organization's technical environment. For instance, there may be several legacy areas of an enterprise that do not warrant any intrusion by service encapsulation. Perhaps your goal is to build a dedicated hosting environment intended only to support new service-oriented applications. More often than not, however, integration requirements drive SOA transitions, in which case the scope of your project could easily see the introduction of SOA affect a majority of your IT enterprise.

Service-oriented principles themselves are not complex, however, the application of these principles can result in relatively complex automation solutions. This is especially the case when services from different solutions are shared and composed to support new or modified business processes. If you're going to live in a service-oriented world, your project team will need to change the way it thinks about fundamental aspects of common architecture, such as componentization, integration, and process automation.

Services Oriented Maturity

Companies are at different levels of maturity in the adoption and incorporation of Services-Orientation (SO). Some are just beginning to explore the world of SO using its technology instantiation: Web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SO, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted. This is level one.

Level two of SO adoption is when the initial testing of Web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of Service-Oriented Integration (SOI). In this world, the enterprise service bus reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections.

Service Oriented Maturity Model

This SOA Maturity Model provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of adoption maturity.

Choreography of Services

With the growing popularity of Service Oriented Architecture (SOA) and Web Services, these diverse assets can be made available as individual enterprise services. How do we build and expose them as such and how do we leverage them in building new service-based applications or business processes? This is the problem Business Process Choreography tries to solve.

Web Services Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions.

Granularity of Services

Stating that Services are the central part of both SOA and SOE will probably not offend anybody. But methods to identify Services are only slowly emerging. When talking about SOA the Services are often seen as a task that will require only a small effort – so small that we almost don’t bother talking about it. The level of detail, in which this task is described, is usually focused on whether to approach this Top-Down or Bottom-up. In practise you will probably use a mix of both, but should have a strong emphasis on the Top-Down – this is necessary in order to control the coherence between the Services.

But how do we actually identify our Services? This is now doubt a discipline normally mastered on the abstraction level of EA. In SOE we need a method to identify Services in a way that supports the paradigm of SOE and utilizes the experience of EA. The important notion here is that we don’t start from scratch!

If you are experienced working with SOE, SOAA and EA you should however not expect any revolution – it is in fact a very simple method. But this is just where I see the strength of the method. The simple message is: when identifying your Services don’t start developing your solution! Keep on track, and identify the Services one level of abstraction at a time

Interesting links