OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services


Rather than comparing SOA to "a discussion" generally, which includes "discussions" that could be random or trivial or could veer off topic, we might think of it more like a "structured, organized, and purposeful discussion".  

Take any given TC at OASIS, for example, and you'll see that there are well defined inputs, rules and business processes, as well as outputs like minutes and specs, to go along with each group.  We have a single Moderator service and a single Logging service.  We have well-defined goals that are supported and well-understood by our business stakeholders.

We communicate primarily in a very asynchronous mode using intelligence-rich documents.  Only occasionally do we meet in real time, and then it is mostly for purposes of discovery, synch, gaining a quorum, and polling.  These activities can be carried out asynchronously as well, but it can be more expedient to run them synchronously.

At the messaging layer, communications occur via a well-defined fabric.  In our case, it includes a Wiki, the OASIS members page, teleconferences, etc.  In a way, the Internet and the Plain Old Telephone System have invisibly become the messaging fabric, so perfectly ubiquitous and standards-based that it could even be considered "The Grid" if you want to get really abstract about it.  

In terms of the orchestration, each member representing him- or herself or some organization acts as an agent or as a façade pattern that may handle complex workflows behind the scenes, within the firewalls of each organization, but then emerging with responses (and occasional requests) for this composite application called a TC.

Anyway, the analogy is not perfect but it is rather interesting.

What I've noticed on this TC so far is that we struggle with semantics in a way that's similar to what first-time SOA implementers face.  We are looking for standard definitions, e.g., give me one standard definition of a service, one standard definition for SOA, etc., so I can document my patterns in a consistent manner.  I see organizations adopting SOA who are trying to solve these semantic problems as well:  one definition for order, one for customer, etc.  Short-term, we in the Blueprints TC have agreed to look to SOA-RM for standard definitions, and I see that as a welcome development.  Patterns and semantics should enjoy a separation of concerns.


/Marc

-----Original Message-----
From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com] 
Sent: Tuesday, November 01, 2005 7:47 AM
To: 'dnickull@adobe.com'; 'Marc.Davies@uk.fujitsu.com'; 'mmatsumura@infravio.com'; 'steve.g.jones@capgemini.com'; 'Theo.Beack@softwareagusa.com'; 'klaskey@mitre.org'
Cc: 'soa-blueprints@lists.oasis-open.org'
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services

To get even more abstract a conversation with a group of people could be considered an SOA.
You have a predefined protocol to follow with input and outputs to the appropriate "service", "asset", "resource" or person.

It is by far the greatest example of orchestration.

:)

- Dan

-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Tuesday, November 01, 2005 7:25 AM
To: Davies Marc; Miko Matsumura; Jones, Steve G; Beack, Theo; Ken Laskey
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services



<post>
-----Original Message-----
From: Davies Marc [mailto:Marc.Davies@uk.fujitsu.com] 

I think Duane's example of the Internet perfectly underscores this
principle
- inasmuch as the Internet is a collection of millions of services - it
is
(IMHO) *not* an SOA - unless we're talking Service Oriented Anarchy :-)

... it doesn't conform to architectural disciplines, anyone can code how
they want, anyone can deploy what they want, there are no checks to
ensure
services deliver on their promised capability (I could go on). Sure, its
an
excellent example of how millions of services can be operating - but,
its
also an illustration of how millions can end up delivering very poor
service, to analogise - if you google the 'wrong' search string - you
end up
with 1 million 'hits' = meaningless.
</post>
Marc:

Hmm - I strongly disagree with this assertion.  The internet has the
same patterns as web services.  Request-response is the primary
mechanism, returning either a success state or a possible error code.
It is message oriented and event driven.  Each service may have specific
policies, metadata (<meta> tags along with the search engines synopsis),
a contract for use (in most cases it is freely available to everyone who
asks) and there are multiple mechanisms for advertising the availability
of services.

One of the core tenets of interface based design is that anyone can
implement whatever they want behind the service interface.  It is not
limited to just coding either - you could deploy chimpanzees with
abacuses who then serialize a response back into html.  The point is
that the interface hides the implementation and insulates the consumer
from those details.  This is another of the core tenets of SOA.

Your claim that the internet delivers poor services is also
unquantifiable.  From a pragmatic architectural standpoint, the value of
the content is moot.  It is the architecture that is SOA, not the
usefulness of the content.

Google roughly equates to the concept of the advertising/discovery
mechanism in the SOA Reference Model.  Yes - getting hundreds or
thousands of results is sub-optimal, however the patterns are the same.

The internet is the single largest SOA on the planet.

Duane




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]