|
|
|
Cohesive architecture
A lot has been written about the new software paradigm, namely “web services,” in these pages. To recap, web services allow organizations to interact with each others’ systems on deterministic levels, without human intervention and according to pre-defined frameworks. Web services will allow automation of supply chains in a more open yet secure way to enable advanced B2B transactions.
Although the web was initially built around the premise of human interfaces requiring active human interventions, the sheer volume of business transactions made possible via automatic web services paradigm, will cause web services to evolve on self-executing levels.
Services provide a framework of distributed orchestrated applications, which work in close tandem and execute business processes in a coherent and structured way. This opens an abstract concept of Service-Oriented Architecture (SOA), which, when deployed, emerges into Service-Oriented Computing (SOC).
We can view SOC from different perspectives, depending on the deployed platforms. These may range from those that concern services within an enterprise, to those that concern service applications interacting across enterprises.
Let us consider the retailer and cola manufacturer example, where the cola manufacturer deploys web services and the retailers’ systems access those web services to ask for quotations and if the bid is right, place orders for deliveries — all being done automatically, of course.
In this example, the retailer would set up its ordering system to interact with its internal inventory, purchasing, ordering and payment systems. For obvious reasons, these systems must work together. Such retailer systems provide services within an enterprise. Hence, the retailer can deploy the web services architecture to facilitate SOC within its own corporate computing borders.
Retailer’s SOC
If we just look at the inter-operation aspects in our retailer example, we will find that there are several hurdles which must be overcome. The first is connectivity among the applications, which protocols such as HTTP can readily ensure. The second is the ability of various components to understand each other. XML, particularly XML Schema, can handle communication formatting, but it cannot decipher the meaning behind a given message. In the example, various enterprise policies must readily authenticate and authorize the parties involved in different interactions, within the retailer organization.
A service-oriented architecture, by ensuring that policies are made explicit, can enforce compliance, thus simplifying the system’s management.
In fact, “SOC provides abstractions and tools to model the information and relate the models, construct processes over the systems, assert and guarantee transactional properties, add flexible decision-support, and relate the functioning of the component software systems to the organizations that they represent” (Michael N. Huhns "Service-Oriented Computing: Key Concepts and Principles," IEEE Internet Computing, vol. 9, no. 1, 2005, pp. 75-81).
Cross-enterprise deployment
Now consider a case, where the retailer realizes that the movement of cola is tied to the movement of a brand of chips, say, Doritos. Let us suppose that retailer wishes to tie the cola order to certain quantities of Doritos on the Doritos' manufacturer's web services as well. This is called choreography.
SOC provides the ability for interacting parties to choreograph their behaviour, so that each can apply its local policies autonomously, yet achieve effective and coherent cross-enterprise processes.
Programming these web services as components and exposing them as web services obviously carries advantages of component-based, software development such as reuse, and tested robustness. When a programmer uses the full complement of semantic representations for services, the resulting modules are easily customizable. The result is that SOC provides the benefits of component-based software development.
As a basis for service-oriented architecture, web service models incorporate the way web services are advertised, discovered, selected and used.
Michael H. Hyuns asserts that SOC deployment is characterized by core attributes:
1. Loose coupling. Tight transactional properties — maintaining and guaranteeing data and state consistency.
2. Implementation neutrality. A service-based approach cannot be specific to a set of programming languages, which cuts into the freedom of different implementers and rules out the inclusion of most legacy applications.
3. Flexible configurability. The configuration can change dynamically as needed and without loss of correctness.
Although SOAs might not be new, they address the fundamental challenges of open systems, which are, operating efficiently and achieving coherence in the face of component autonomy and heterogeneity.
SOC adds the ability to build on conventional information technology in a standardized way, so that tools can facilitate the practical development of large-scale systems.
Current specifications for web services do not address transactions or specify a transaction model. Emerging standards include the Business Transaction Protocol8, as well as IBM, Microsoft and BEA's WS-BusinessActivity and allied standards. More information is available on
However, most implementers believe that this will manage transactions, somehow. Without guidance from a standard or an agreed-upon methodology by the major vendors, transactions will be implemented in an ad hoc fashion, thus unnecessarily complicating interoperability and extensibility.
To publish effectively, our cola manufacturer must specify services with precision and greater structure. Retailers from market will eventually invoke the service, and differences in assumptions about the service's provisions could be devastating. Hence the need for central web services registry mechanisms becomes obvious.
The registry must be able to certify given providers, so that it can endorse them to the registry's users. Service requesters should then be able to find a registry they can trust, which means dealing with considerations of trust, reputation, incentives for registries and most importantly, for the registry to understand the requester's needs.
Current registry implementation ranges from the Liberty Alliance Project (LAP) to Federated Systems, whereby each web service provider become part of a pre-authenticated federation of trust providers.
Once a service is selected, the requester and provider must develop a finer-grained sharing of representations. They must be able to participate in conversations to conduct long-lived flexible transactions, in such a manner so that they can establish and monitor a service-level agreement.
The writer is vice-president and head of information technology at the NDLC-IFIC Bank Ltd. Email:
