Its all about heterogeneity & change

The Business Drivers

There are two underlying themes behind all IT initiatives: heterogeneity and change. Most enterprises today contain a range of different systems, applications, and architectures of different ages and technologies. Integrating products from multiple vendors and across different platforms were almost always a nightmare.

Change is the second theme underlying the questions that today’s IT executives face. Customer needs and requirements change more quickly, driven by competitive offerings and wealth of product information available over the Internet. There is a focus on the extended supply chain, enabling customer and partner access to business services.

Services-Oriented Architecture: as a solution

Ever since the ‘software crisis’ prompted the beginnings of software engineering, the IT industry has been struggling to find solutions to solve the above problems. The following, short list of core technology advancements has brought us to where we are today. We will briefly discuss those core technologies and our focus will be on how such technologies help resolve IT problems.

• Object Oriented Analysis and Design

Larman describes the essence of the object-oriented analysis and design as considering "a problem domain and logical solution from the perspective of objects (things, concepts, or entities)" in Applying UML and Patterns — An Introduction to Object-Oriented Analysis and Design. Jacobson, et al defines these objects as being "characterized by a number of operations and a state that remembers the effects of these operations" in Object-Oriented Software Engineering: A Use Case Driven Approach.

In object-oriented analysis, such objects are identified and described in the problem domain, while in object-oriented design, they are transitioned into logical software objects that will ultimately be implemented in an object-oriented programming language.

With object-oriented analysis and design, certain aspects of the object (or group of objects) can be encapsulated to simplify the analysis of complex business scenarios. Certain characteristics of the object(s) can also be abstracted so that only the important or essential aspects are captured, in order to reduce complexity.

• Component based Design

Component-based design is not a new technology. It is naturally evolved from the object paradigm. In the early days of object-oriented analysis and design, fine-grained objects were marked as a mechanism to provide ‘reuse’, but those objects are at too lower a level of granularity and there are no standards in place to make widespread reuse, practical. Coarse-grained components have become more and more a target for reuse in application development and system integration. These coarse-grained components provide certain well-defined functionality from a cohesive set of finer-grained objects. In this way, packaged solution suites can also be encapsulated as such "components".

• Service-oriented Design

A service is generally implemented as a course-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled, message-based communication model.

The following terminology exists for Service Oriented Design —

Services:

Logical entities, the contracts defined by one or more published interfaces.

Service provider:

The software entity that implements a service specification.

Service consumer (or requestor):

The software entity that calls a service provider. Traditionally, this is termed a ‘client.’ A service consumer can be an end-user application or another service.

Service locator:

A specific kind of service provider that acts as a registry and allows for the lookup of service provider interfaces and service locations.

Service broker:

A specific kind of service provider that can pass on service requests to one or more additional service providers.

• Interface-based Design

In both component and service development, the design of the interfaces is done such that a software entity implements and exposes a key part of its definition. Therefore, the notion and concept of ‘interface’ is key to successful design in both component-based and service-oriented systems. The following are some key interface-related definitions:

Interface:

Defines a set of public method signatures, logically grouped but providing no implementation. An interface defines a contract between the requestor and provider of a service. Any implementation of an interface must provide all methods.

Published interface:

An interface that is uniquely identifiable and made available through a registry for clients to dynamically discover.

Public interface:

An interface that is available for clients to use but is not published, thus requiring static knowledge on the part of the client.

Dual interface:

Frequently interfaces are developed as pairs such that one interface depends on another; for example, a client must implement an interface to call a requestor because the client interface provides some callback mechanism.

• Layered application architectures

As mentioned before, object-oriented technology and languages are ways to implement components. While components are the best way to implement services, though one has to understand that a good component-based application does not necessarily make a good service-oriented application. A great opportunity exists to leverage component developers and existing components, once the role played by services in application architecture is understood. The key to making this transition is to realize that a service-oriented approach implies an additional application architecture layer. The technology layers (Object/Class layer, Component layer, Service layer) can be applied to application architecture to provide more coarse-grained implementations as one gets closer to the consumers of the application.

Service-Oriented Architecture: a closer look

Service-oriented architecture presents an approach for building distributed systems that deliver application functionality as services to either end-user applications or other services. It is comprised of elements that can be categorized into Functional and Quality of service. These elements are described in detail as follows:

Functional aspects include:

Transport: is the mechanism used to move service requests from the service consumer to the service provider, and service responses from the service provider to the service consumer.

Service Communication Protocol:

is an agreed mechanism that the service provider and the service consumer use to communicate what is being requested and what is being returned.

Service Description:

is an agreed schema for describing what the service is, how it should be invoked, and what data is required to invoke the service successfully.

Service:

describes an actual service that is made available for use.

Business Process:

is a collection of services, invoked in a particular sequence with a particular set of rules to meet a business requirement. Note that a business process could be considered a service in its own right, which leads to the idea that business processes may be composed of services of different granularities.

Service Registry:

is a repository of service and data descriptions, which may be used by service providers to publish their services, and service consumers to discover or find available services. The service registry may provide other functions to services that require a centralized repository.

Quality of service includes:

Policy:

is a set of conditions or rules under which a service provider makes the service available to consumers.

Security:

is the set of rules that might be applied to the identification, authorization, and access control of service consumers invoking services.

Transaction:

is the set of attributes that might be applied to a group of services to deliver a consistent result. For example, if a group of three services are to be used to complete a business function, all must complete or none must complete.

Management:

is the set of attributes that might be applied to managing the services provided or consumed.

Service-Oriented Architecture: Benefits

Businesses are dealing with two fundamental concerns — the ability to change quickly, and the need to reduce costs. With a service-oriented architecture, we can realize several benefits to help organizations succeed in the dynamic business landscape of today:

Leverage existing assets

SOAs provide a layer of abstraction that enables an organization to continue leveraging its investment in IT by wrapping these existing assets as services that provide business functions. Organizations potentially can continue getting value out of existing resources instead of having to rebuild from scratch.

Easier to integrate and manage complexity

The integration point in a service-oriented architecture is the service specification and not the implementation. By providing a service specification in front of existing resources and assets built on disparate systems, integration becomes more manageable since complexities are isolated. This becomes even more important as more business work together to provide the value chain.

More responsive and faster time-to-market

The ability to compose new services out of existing ones provides a distinct advantage to an organization that has to be agile to respond to the demanding business needs. Leveraging existing components and services reduces the time needed to go through the software development lifecycle of gathering requirements, performing design, development and testing. This leads to rapid development of new business services and allows an organization to respond quickly to changes and reduce the time-to-market.

Reduce cost and increase reuse

With core business services exposed in a loosely coupled manner, they can be more easily used and combined based on business needs. This means less duplication of resources, more potential for reuse, and lower costs.

Be ready for what lies ahead

SOAs allows businesses be ready for the future. Business processes, which comprise of a series of business services, can be more easily created, changed and managed to meet the needs of the time. SOA provides the flexibility and responsiveness that is critical to businesses to survive and thrive.

Service-oriented architecture is by no means a silver bullet and migration to SOA is not an easy task. Rather than migrating the whole enterprise to a service-oriented architecture overnight, the recommended approach is to migrate an appropriate subset of business function as the business need arises or is anticipated.

Web Services Architecture

What are Web Services?

Web Services technology is based on open technologies such as:

- eXtensible Markup Language(XML)

- Simple Object Access Protocol (SOAP)

- Universal Description, Discovery and Integration (UDDI)

- Web Services Description Language (WSDL)

The W3C’s Web Services Architecture Working Group has jointly come to agreement on the following working definition of a Web service:

"A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols."

Basic Web services combine the power of two ubiquitous technologies: XML, the universal data description language, and the HTTP transport protocol widely supported by browser and Web servers.

Web services = XML + transport protocol (such as HTTP)

Some of the key features of Web Services are the following:

• Web services are self-contained.

On the client side, no additional software is required. A programming language with XML and HTTP client support, for example, is enough to get started. On the server side, merely a Web server and a servlet engine are required.

• Web services are self-describing.

Neither the client nor the server knows or cares about anything besides the format and content of request and response messages (loosely coupled application integration). The definition of the message format travels with the message.

• Web services are modular.

Web services are a technology for deploying and providing access to business functions over the Web. J2EE, CORBA, and other standards are technologies for implementing these Web services.

• Web services can be published, located, and invoked across the Web.

The standards required to do so are:

— Simple Object Access Protocol (SOAP), also known as service-oriented architecture protocol, an XML-based RPC and messaging protocol

— Web Service Description Language (WSDL) is a descriptive interface and protocol binding language

— Universal Description, Discovery, and Integration (UDDI), a registry mechanism that can be used to look up Web service descriptions

• Web services are language independent and interoperable.

The interaction between a service provider and a service requester is designed to be completely platform and language independent. This interaction requires a WSDL document to define the interface and describe the service, along with a network protocol (usually HTTP). Because the service provider and the service requester have no idea what platforms or languages the other is using, interoperability is a given.

• Web services are inherently open and standards based.

XML and HTTP are the technical foundation for Web services. A large part of the Web service technology has been built using open source projects. Therefore, vendor independence and interoperability are realistic goals.

• Web services are dynamic.

Dynamic e-business can become a reality using Web services because, with UDDI and WSDL, the Web service description and discovery can be automated.

• Web services are composable.

Simple Web services can be aggregated to more complex ones, either using workflow techniques or by calling lower-layer Web services from a Web service implementation.

Web Service interoperability

For the key promise of Web services, interoperability to work, standards need to be carefully managed. The Web Services Interoperability Organization has an important role in this area, as a standards integrator to help Web services advance in a structured and coherent manner.

Web Services Interoperability Organization

Web Services Interoperability Organization (WS-I) is an open, industry consortium of about 150 companies, representing diverse industries such as automotive, consumer packaged good, finance, government, insurance, media, telecommunications, travel and the computer industry. It is chartered to:

• Promote Web services interoperability across platforms, operating systems, and programming languages with the use of generic protocols for interoperable exchange of messages between services



• Encourages Web services adoption



• Accelerates deployment by providing guidance, best practices and other resources for developing interoperable Web services

Conclusion

This article described the basics about Service Oriented Architecture and Web Services. In the future articles I hope to write on advanced Web Services topics.

References —

IBM Redbook: Patterns, Service Oriented Architecture and Web Services