Duane Nickull wrote: (01)
>> Ed wrote:
>>
>> With all due respect, I think the request/response interaction paradigm is
>> fundamental to "service-oriented". As discussed in other venues, the actual
>> technical interaction can be more complex than request/response, but the
>> fundamental paradigm cannot be.
>
> Did you read this white paper on other message exchange and interaction
> patterns for SOA? Publish subscribe is quite normal now and sometimes it
> can be straight server push based on events such as timeouts. Why should
> SOA be constrained to one MEP? (02)
The problem here, at least for the business conceptualization of SOA, is
not to confuse the nature of the interaction with the technical details
of the communication. You can communicate a request by a direct
message, or by publishing it to a blackboard, or by writing it to a file
that you know some agent will read. (03)
You can "publish" a request to a notification area that you know will
have exactly one interesting subscriber, namely *the* participating
service provider, or a broker who will choose one. And you can
subscribe to another notification area that will receive the response.
The response area can be pre-negotiated, or the request can identify the
area to which the response is to be posted. In all of those cases, you
have a request/response paradigm implemented by blackboard
communication. (We NIST used exactly that technique for communicating
hierarchical control commands and status responses in the Automated
Manufacturing Research Facility 1982-87.) (04)
Whether the requestor knows who will respond is irrelevant, but it is
critical that the requestor assumes that exactly one provider will. The
rest is configuration management. And it is also useful, but logically
a separate concern, that a logging agent can monitor both "mailboxes",
by simply subscribing to them, and log the interactions to a file.
Note, BTW, that many so-called "agent architectures" are actually just
service-oriented architectures -- one responder for each kind of request
-- with blackboard communications and dynamic configuration. I don't
deny that this is an important (and incompatible) implementation
architecture; I just want to separate that from the "business
participant interaction" paradigm. (05)
But when the client publishes a "notification of requirements" with no
certainty of any response, and possibly needs to sort out multiple
responses from diverse unforeseen responders, you have a real
"autonomous agent architecture", not a service-oriented architecture.
The agents also provide the functions, but they are actively seeking
contracts, and there is a mechanism for dealing with competition. And in
many situations, there must also be a mechanism for dealing with an
"impaired system" in which no agent responds to a posting. (06)
It may be to certain organizations' political advantage to confuse these
architectures, as they did with blackboard SOAs when "agents" were "in",
but from an architectural point-of-view, you are talking about a
significant change in the required behaviors of clients and providers,
not just the software technology. (07)
That said, I think "discovery" is a separable can-of-worms. (08)
In the SOAs that we envisage, a client new to a service marketplace can
go to a catalogue of services and providers and using reasoning
mechanisms to validate the ability of some catalogue entries to meet his
needs, then choose one and integrate it into his "system". Or he can
post his requirements on a bulletin board and await responses from
active service agents claiming ability to meet them, by reasoning from
their capabilities to the posted requirements. This latter is an
agent-oriented architecture for implementing the discovery process, and
OBTW, it is much harder to implement. Both architectures involve
ontologies to match requirements to capabilities. Both result in
identification of one or more specific suppliers to be the receipt of
specific service requests. So the "discovery architecture" _may_ be
different from the operating SOA. (09)
Finally, the real business processes for implementing Discovery in
supply-chain environments are much more complex and arcane. Some
elements are catalogue lookups, some elements are RFPs, some elements
are referrals from other business partners, some elements are sales
calls, some elements are chance meetings at conferences, on subway
trains and in airplanes. With the exception of one-time purchases from
catalogs, all of the other "initial contacts" are followed up with
evaluation of the supplier's capability over the expected term of need,
identification/development of a useable joint business process, and
finally by creation of a basis contract for procurement of goods and/or
services over the expected term. All of that, together with
development/configuration, deployment and testing of the supporting
software, if any, is part of the process of "integrating" the supplier
into the client's supply-chain. And it all takes place before the
recurring product/service requests and other interactions begin to flow.
When the requests actually flow, each goes to a specific preferred
supplier first, and to another only if the preferred supplier declines.
This behavior has "emerged" in the marketplace over 150 years or more. (010)
And when businesses use SOA internally, there is no "discovery" process;
there is only design. So it is _very_ important to recognize that
"discovery" must be separable from operation of the SOA for both inter-
and intra-enterprise architectures. (011)
I believe SOA is a great guideline for how to think about the problem.
And the simpler we make the basic model, the greater the takeup will be.
The more complex the model, the more incompatible subarchitectures
and options we introduce, the more we dilute the message and therewith
the value of the work. There will be multiple incompatible
implementation architectures, of course, but with luck that will shake
out to three in a few years. (012)
-Ed (013)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (014)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (015)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (016)
|