[Top] [All Lists]

Re: [ontolog-forum] The Open Group SOA Ontology

To: Duane Nickull <dnickull@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>, Toby.Considine@xxxxxxxxx
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Fri, 18 Jul 2008 12:12:12 -0400
Message-id: <4880C0DC.8060402@xxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>