Concepts for Automating Systems Integration
Rule-based models are an alternative to finite-state automata for specifying the behavior of components formally,
and they may be useful in specifying the behavior of interactions or protocols. But for integration support tools,
rule-based models are most likely to be used in expert system s (see 6.5.1).
and they may be useful in specifying the behavior of interactions or protocols. But for integration support tools,
rule-based models are most likely to be used in expert system s (see 6.5.1).
6.3.2 Service and Interface specifications
Service models are weak behavior models that describe a component in terms of the distinct functions it can
perform, the information required to perform each function, and the information produced on completion of each
function. They assume that a function is performed in response to an explicit request, either from another system or
from a human user. The definition of a function in service modeling languages is usually limited to its name and its
"signature," that is the names and data types of inputs and outputs.
perform, the information required to perform each function, and the information produced on completion of each
function. They assume that a function is performed in response to an explicit request, either from another system or
from a human user. The definition of a function in service modeling languages is usually limited to its name and its
"signature," that is the names and data types of inputs and outputs.
Most service models use a one-request/one-response paradigm, although there may be several kinds of responses for
a given kind of request. Such a system performs only one function at a time, and only responds once to any given
request, on completion.
a given kind of request. Such a system performs only one function at a time, and only responds once to any given
request, on completion.
Services are modeled using an interface definition language. Several of these are in common use:
Java [110] and
C# [126] are programming languages frequently used to develop software for remotely accessible
services. It is common in those communities to specify the service interfaces in the programming language itself.
services. It is common in those communities to specify the service interfaces in the programming language itself.
The OMG/ISO Interface Definition Languag
e (IDL) [61] is an abstraction of the interface specification capabilities
of several programming languages, and it is characteristic of IDL compilers that they can generate the equivalent
formulations in the target implementation languages (Java, C/C++, Ada, etc.). Similar languages are used in the
X/Open DCE [107] and Microsoft DCOM [108] environments.
of several programming languages, and it is characteristic of IDL compilers that they can generate the equivalent
formulations in the target implementation languages (Java, C/C++, Ada, etc.). Similar languages are used in the
X/Open DCE [107] and Microsoft DCOM [108] environments.
All of these IDLs assume the following rules:
· A particular system the
server offers a specific set of services (functions) to other applications. The
behavior of the application that uses the service the
client is implied or unspecified in the language, although
it may be specified in surrounding text.
it may be specified in surrounding text.
· The set of services is described in a single
interface specification schema, along with all information and objects
necessary to specify the services.
· Each service is modeled as a procedure call, which includes the name of the service, a list of inputs and their
data types, a list of the principal output results and their data types, and possible alternative responses, together
with their associated results.
with their associated results.
The Web Services Description Language
(WSDL) [79] presents a somewhat different view of the service interface.
It defines message types with names and required and optional content specified in terms of named information units
and their datatypes. A message can be classified as a notification, a service request, or a response to some request
message type or types. Messages can be collected into a port (an interface to a component) which attaches to each
message an indication as to whether that port can send it or receive it or both. Ports can be paired to define a client-
server contract, with explicit request-response rules. More generalized forms of n-party contract with rules for
which party sends which messages to whom are possible. So any interaction specified in any of the earlier interface
definition languages can be specified in WSDL, but more general interactions can also be specified and more
information can be provided.
It defines message types with names and required and optional content specified in terms of named information units
and their datatypes. A message can be classified as a notification, a service request, or a response to some request
message type or types. Messages can be collected into a port (an interface to a component) which attaches to each
message an indication as to whether that port can send it or receive it or both. Ports can be paired to define a client-
server contract, with explicit request-response rules. More generalized forms of n-party contract with rules for
which party sends which messages to whom are possible. So any interaction specified in any of the earlier interface
definition languages can be specified in WSDL, but more general interactions can also be specified and more
information can be provided.
The important characteristic of these specification languages for integration purposes is that they define the
information that can be obtained from, or provided to, the components the specified interface, and the means by
which that information can be obtained or provided.
information that can be obtained from, or provided to, the components the specified interface, and the means by
which that information can be obtained or provided.
57