CSC/ECE 517 Fall 2010/ch6 6j SO

Service-oriented architecture

Introduction

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive in and talk about what SOA is and what the essentials behind SOA are, it is a useful first step to look back at the evolution of SOA. To do that, we have to simply look at the challenges developers have faced over the past few decades and observe the solutions that have been proposed to solve their problems.

The Problem

Early programmers realized that writing software was becoming more and more complex. They needed a better way to reuse some of the code that they were rewriting. When researchers took notice of this, they introduced the concept of modular design. With modular design principles, programmers could write subroutines and functions and reuse their code. This was great for a while. Later, developers started to see that they were cutting and pasting their modules into other applications and that this started to create a maintenance nightmare; when a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. After the fix, the deployment nightmare began. Developers didn't like that; they needed a higher level of abstraction.

Researchers proposed classes and object-oriented software to solve this, and many more, problems. Again, as software complexity grew, developers started to see that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

Key Components of SOA

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

Service

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1.1). The last property of a service is that the service be self-contained.

Message

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

Dynamic Discovery

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

Web Service

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

Benefits of SOA

SOAs offer the following advantages over other approaches:

They offer business services across the platforms They provide location independence Services need not be at a particular system or particular network Completely loosely coupled approach Authentication and authorization support at every level The search and connectivity to other services is dynamic

Short-term benefits of implementation:

Enhances reliability Reduces hardware acquisition costs Leverages existing development skills Accelerates movement to standards-based server and application consolidation Provides a data bridge between incompatible technologies

Long-term benefits of implementation:

Provides the ability to build composite applications Creates a self-healing infrastructure that reduces management costs Provides truly real-time decision-making applications Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

Benefits from the perspective of Business Value

Ability to more quickly meet customer demands Lower costs associated with the acquisition and maintenance of technology Management of business functionality closer to the business units Leverages existing investments in technology Reduces reliance on expensive custom development

Areas in SOA Implementation where OO Concepts are used

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications. The main areas where OO concepts come into picture are

1. Interface Orientation The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

2. Interoperability This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

3. Autonomy and Modularity An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

OO Concepts in SOA

Cohesion in SOA?

Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable. Sequential Cohesion: when a module carries out several tasks that must be ordered. Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]." Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|" Logical Cohesion: where a module's activities are grouped because they appear to share common implementations. Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module. As Steve goes on to say: Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object. The paper concludes with: Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t matter, because we can just go back to the days before objects, dig up measures like coupling and cohesion, and apply them all over again — for the first time, of course. Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work: Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain: On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA. Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response: Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad. The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA: I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008. And goes on to discuss Steve's original article as well: ... a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model. The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?

Design Patterns in SOA

A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

1. Service loose coupling This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

2. Service Abstraction Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

3. Service Reusability Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

4. Service Autonomy The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

5. Service Composability As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

Service Oriented Architecture in contrast with Enterprise Architecture

Similarities

SOA and EA domains share many similarities.

• Both address similar architectural domains. • Both are intended to closely align IT with business. • Both use input based on business objectives. • Both require similar strategies and planning activities.

Conclusion

Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.