ne crawled the Web.
The web site itself may have changed. You can check the current page or check for previous versions at the Internet Archive. Yahoo! is not affiliated with the authors of this page or responsible for its content.
Operation-state modeling Operation-state modeling
The busy developer's guide to writing service specifications
Skill Level: Introductory
Brian Maso
(
brian-dw@blumenfeld-maso.com
)
SOA and Services Guru
Blumenfeld & Maso
10 Jun 2008
Operation-state modeling is a technique for writing detailed and consistent service
specifications. Learn how to objectively verify the validity of a service implementation
by checking its behavior against the operation-state model.
I am continually discouraged and frustrated by the lack of any technique for
describing Web service behavior other than prose. A service designer today is no
more capable of describing how each operation of a service interface is supposed to
act than he or she would have been 250 years ago. Today, the designer would use a
word processor to write a specification document. If the same designer had been
alive 250 years ago, he or she would have written the same document in long-hand
using ink and quill. Editing technology aside, the service designer would produce
substantially the same document.
Take Listing 1, a Java interface equivalent to a simple servicethe
TellerServicewith two service operations. Imagine that this interface had been
scribed by a service architect for a typical banking company. Now take a moment to
read the description of the two service operations,
debit
and
credit
. Armed with
these service descriptions, could a service implementer develop a service with
conforming
debit
and
credit
operation implementations?
Listing 1. Java equivalent of a TellerService with two operations
public interface TellerService {
/**
* Operation to debit an account by amount
Operation-state modeling
© Copyright IBM Corporation 1994, 2007. All rights reserved.
Page 1 of 13 **/
public void debit( String accountNumber, double amount
);
/**
* Operation to credit an account by amount
**/
public void credit( String accountNumber, double amount
);
}
No, not without more information. Although the descriptions are short and sweet and
the operations simple, it's ambiguous whether the term debit means "add money to
the account" or "subtract money from the account." Maybe debit means something
altogether different.
A more important issue is the problem of the other guy. Imagine that the confused
service implementer has a dictionary. He looks up debit and credit. He thinks he
knows what the terms mean and implements the service operations accordingly. In a
different engineering team in the same company, another engineer (the other guy) is
tasked with creating a debit/credit service client. This client engineer doesn't own the
same dictionary. She develops his client implementation using a definition of debit
and credit that she got from her cousin the accountant, whom she e-mailed for help
after encountering the unfamiliar terms in the specification.
The big questions are, are the service implementer's and the client implementer's
definitions of debit and credit consistent or conflicting? How will they know? If the
definitions conflict, when will they find out? How will the difference affect each
engineer's project timeline if the definitions conflict? How will the conflict be
resolved?
Typically, such conflicts aren't discovered until late in the development
cycleusually during integration testing. The project timeline for both service and
client projects will be negatively affected, possibly quite badly, very late in the project
cycle. This is exactly when a project manager does not want timeline problems
showing up!
We're in a bizarre situation with services descriptions today: We must rely on the
written word to describe service behavior. The written word is subjective, in that
each specification reader has his or her own interpretation of the spec. Although two
different interpretations may be reasonable and logical, there's no guarantee they
don't conflict. More importantly, there's no objective standard for determining
whether a service implementation conforms with the specification! I find this
intolerable.
Operation-state modeling
Operation-state modeling is a general technique for describing service behavior that
developerWorks®
ibm.com/developerWorks
Operation-state modeling
Page 2 of 13
© Copyright IBM Corporation 1994, 2007. All rights reserved. targets the problem of inconsistent, ambiguous, subjective, and vague service
specifications that invariably come with written-word specifications. Inconsistency,
ambiguity, subjectivity, and vagueness in the service specification can severely
hamstring service implementation projects. An implementation project that begins
with a prose spec will require many more hours (or months or even years!) to
implement and will have a comparatively longer project timeline than the same
project begun with a spec containing an operation-state model.
Input, output, and behavior
A Web Services Description Language (WSDL) document describes valid input and
output messages: what messages make valid operation input and what messages
make valid operation output. Message schemata contained in the WSDL file are
objective and machine-readable. But WSDL schemata are barely half of what is
needed to describe a service adequately. Much more is needed to describe service
behavior consistently and without ambiguity.
If you think about it, an operation's WSDL-based input/output message description
basically says, this operation accepts any valid input message and will return any
valid output message. For any possible valid input, a service might respond with any
valid output message and still conform to the service WSDL. A service
implementation that always responds with a fault message regardless of the input
would be useless but completely conform to its WSDL.
A vital piece is missing: something to glue the input to the output message. That
missing something is the description of the operation's behavior. WSDL's two data
points (input and output message schemata) are important, but we need more in
order to fully describe an operation.
Operation-state modeling views an operation with four data points:
Initial service state
Input message
Final service state
Output message
In the operation-state modeling view, a service operation invocation goes like this:
1.
Before the invocation begins, the service is in some initial state,
conforming to an interface data model.
2.
The service begins an operation invocation when it receives some input
message conforming to the WSDL input message model for the
operation.
ibm.com/developerWorks
developerWorks®
Operation-state modeling
© Copyright IBM Corporation 1994, 2007. All rights reserved.
Page 3 of 13 3.
As part of the service invocation, the service is put in to some final state,
which also conforms to the interface data model that defines the initial
state. Moreover, the final state can be calculated from the initial state and
the input message.
4.
The service responds with some output message conforming to the
WSDL output message model for the operation. Moreover, the output
message can be calculated from the input message, the initial state, and
the final state.
Figure 1 illustrates how an operation-state model expands the traditional WSDL
model of a service operation. Where the WSDL model includes input and output
message schemata, the operation-state model expands this with an interface-state
data model and two functions that link the input message, initial state, final state,
and output message.
Figure 1. An operation-state model expands the WSDL model's input and
output with additional operation-behavior information
Interface operations share an internal data set
Question: Why does WSDL group service operations into interfaces? Consider that
you could define a single interface with a set of n operations or alternatively could
define n separate interfaces with just one of n operations each. There would be no
behavioral difference between these two extremes for partitioning n operations into
interfaces: The exact same service can be described by WSDL employing either
interface-operation partitioning technique. Figure 2 illustrates 1:n interface-operation
partitioning, and Figure 3 illustrates n:1 interface-operation partitioning, showing that
you can use either to describe essentially the same servicethat is, a service URL
developerWorks®
ibm.com/developerWorks
Operation-state modeling
Page 4 of 13
© Copyright IBM Corporation 1994, 2007. All rights reserved. that services the same n operations.
Figure 2. One interface, many operations
Figure 3. Many interfaces with one operation each
The WSDL specification says nothing about why interfaces exist or how you should
use them; but intuitively, you understand that an interface groups operations that
query or modify related service data. That's another way of saying that there's a
common data set backing the operations defined in an interface. Each interface
operation extracts