ASPnews Home





ASP Directory


About Us

Search ASPnews:
Internet Lists
Internet News
Internet Resources
Linux/Open Source
Personal Technology
Small Business
Windows Technology
xSP Resources
Corporate Info
Tech Jobs
E-mail Offers
Be a Commerce Partner
Cheap Plane Tickets
Digital Camera Review
Register Domain Name
Memory Flash Cards
Online Education
Remote Access
Advertising Trucks
Online Degrees
Best Digital Camera
Cheap Web Hosting
Digital Camera Review

ASPnews Focus
Top News:
» SOAs So Close, Yet So Far

» Why SaaS Is Making a Comeback

» Join the Discussion:'s industry forums

» More ASP News

TOP 50
Top 20 Providers
 & Top 30 Enablers
Free Newsletter!

ASPnews Shortcuts
Week's Top News

ASP News at

Industry Events

Discussion Forums

Industry Basics

Site Guide

FREE activePDF Download: Dynamically Convert 280+ File Types to PDF


Dev: Service-Oriented Architectures: An Overview
By K. Mani Chandy and Jonathan Lurié Carmona and Robert Alexander

February 17, 2005

Continued from Page 1

How SOA Works

A service is quiescent awaiting requests; when a request is received, the service responds with an appropriate reply. The coupling between caller and called components is “tight” in function calls in programming languages but “loose” in Web services in the following sense. A function call in C is made by one function written in C to another function written in C within the same program running within the same process. A call to a Web service can be made by a process written in one programming language on one machine to a service offered by a process implemented in a different language on another machine. A Web service can be registered in a directory at one point in time, and then discovered, bound, and invoked later.

During the past 50 years, programmers have been given access to procedural composition structures that are increasingly loosely coupled. All of these compositional structures — function calls, procedure calls, method calls, remote procedure calls, and service calls — have a common ancestry, which is the strength of service-oriented architectures (see Figure 4). The familiarity that programmers have with synchronous request/reply calls ensures that SOA is here to stay.

Click here for a larger image.

Figure 4: What Service-Oriented Architecture Looks Like

The key component of SOA is the service, and the key compositional operator is the service call. Simple services are called and composed within programs to obtain more powerful services, just as simple functions are composed in procedural programming languages to get more powerful functions. The contract of a service call (see Figure 5) specifies the schema for a call to the service and the relationship among:

  1. the parameters passed by the call to the service,
  2. the state of the service prior to the call,
  3. the parameters returned by the service to the call, and
  4. the state of the service after the call.

Click here for a larger image.

Figure 5: What a Service Contract Looks Like

For example, consider a consumer’s call to a producer to ship an item (see Figure 6): The call schema specifies the format of the request and reply. The parameters that the consumer’s call pass to the producer include the consumer’s ID, the ID of the item, the quantity, shipping information, and so forth. The parameters that the producer returns to the consumer include the date that the item will be delivered, the account number charged, and so on. The relation between states before and after the call is captured by the states of the warehouse and logistics systems: the warehouse has one fewer of the specified item and the logistics system has one more of the item after the call.

Click here for a larger image.

Figure 6: Service Contract Example: Ship Item from Warehouse

For decades, programmers have been developing programs that call functions; thus, the contracts and compositional structures for SOA are well understood.

Powerful services can be constructed in a systematic fashion by composing simpler services, and the validity of contracts for the composed services can be demonstrated from the contracts of the simpler services and the compositional structure. For example, a service that returns the value of a portfolio of currencies — say, in euros and yen — in dollar terms can be composed from simpler services such as a service that converts only euros to dollars, and another service that converts only yen to dollars. Programmers can demonstrate the validity of the contract for the portfolio-of-currencies service from the contracts of the euro/dollar and yen/dollar services and the compositional structure (see Figure 7).

Click here for a larger image.

Figure 7: Service Composition

Next, consider the architecture of the business network of SOA (see Figures 8 and 9). The components of the business network are processes and bindings where a process can be a service provider, a service consumer, or a service broker.

Click here for a larger image.

Figure 8: SOA of Business Networks

Click here for a larger image.

Figure 9: SOA Trinity

A process can be both a service provider and a service consumer. A service broker is a special type of service provider; it provides a brokering service (see Figure 10).

Click here for a larger image.

Figure 10: SOA UDDI as Service Broker

A producer can make a call on a broker to register a service with the broker. A consumer can make a call on a broker to find the address of a provider that offers a particular kind of service. For example, a consumer can make a service call on a brokering service to get addresses of providers that offer services to convert currencies (for example, from euros to dollars).

A consumer that uses a service type — say, converting currencies — binds to a producer of that service: the binding specifies which producer the consumer will employ for that service. A consumer invokes a service by making a call to the producer specified in the consumer’s binding for that service, and the producer responds to the call with an appropriate reply.

The business network for SOA can be represented by a dynamic labeled, directed graph where the components (processes and bindings) of the business network are components (nodes and edges) of the graph. Nodes represent processes and the edges represent bindings (refer to Figure 9). An edge is directed from a consumer of a service to a producer of that service, and the label of the edge identifies the service. Since a process can be both a producer and a consumer, a node may have both incoming and outgoing edges. The graph is dynamic because over time bindings can change, new processes can be created, and processes may be deleted.

A compositional operator in the business network is the creation of a “service binding” between a consumer and a producer of a service. In terms of the graph, the creation of a binding creates a new edge. Other compositional operators include the creation and deletion of services. Executions of these compositional operators determine how the graph evolves over time.

Page 3: More to Come

Go to page: Prev  1  2  3  Next  

Email this Article
View Printable Version
Back to Strategies


Featured Links
Learn the secrets of the popular search engines!
Free Web Hosting Buyer's Guide -- Click Here!
Enhance your Web site with the Dynamic HTML HierMenus Code

JupiterWeb networks:

Search JupiterWeb:

Jupitermedia Corporation has three divisions:
Jupiterimages, JupiterWeb and JupiterResearch

Copyright 2005 Jupitermedia Corporation All Rights Reserved.
Legal Notices, Licensing, Reprints, & Permissions, Privacy Policy.

Jupitermedia Corporate Info | Newsletters | Tech Jobs | Shopping | E-mail Offers

Give us your Feedback