Re: [ebsoa] SOA and Patterns

[Paul Denning <pauld@mitre.org>]

At 04:09 PM 2004-05-17, Chiusano Joseph wrote:
> On the subject of patterns, which
> we've talked about:
>
> The following recent FTPOnline article [1] titled "SOA Offers
> Competitive Advantages" discusses the benefit of using design
> patterns
> when building an SOA.
>
> [1]
> http://www.ftponline.com/special/soa/overview/default_pf.asp

I discussed "SOA Patterns" at [2].

I like the notion of patterns.

I think there also is a need to formalize (identify with a URI) what I
call "Binding Patterns", as well as, "Binding
Algorithms".

Web service consumer applications must be designed with some way to get
the URI of the service it will use.  (For simplicity, visualize SOAP
messages sent using HTTP request and response.)

The application can hard code a default URL.  For example, I might
hard code the SOAP UDDI inquiry URLs for IBM, Microsoft, SAP, and NTT
endpoint for the UDDI Business Registry.  I may override these on
the command line if I'd rather use a private UDDI server.  Perhaps
the application uses an environment variable, or java .proprties
file.  These are a few examples of Binding Patterns.  These do
not expect any associated infrastructure (note, I'm treating UDDI as an
arbitrary web service in this example).

Other Binding Patterns would rely on some infrastructure:

• Use DNS-SD to get a DNS TXT record containing the URL of a service.
• Use an ebXML Registry
• Use a UDDI registry using a find_binding( <tModelBag>)
• Use a UDDI registry using a find_service(<categoryBag>)

An application may support several Binding Patterns, and use them in a
particular order.  A command line parameter may override any URL
that could be discovered through UDDI, for example.  Or, I might
look in UDDI for bindings with a particular fingerprint.  If I don't
find anything, maybe I'll try looking for services with a particular
categoryBag.

Binding Algorithms are orthogonal to Binding Patterns.  For example,
if I use UDDI find_binding, and I discover more than one binding, which
one do I use?  A particular Binding Algorithm would dictate which
one I use.  One binding may include a value for the
"instanceParms" that indicates it is "primary", and
another binding's instanceParms would indicate a
"backup".  A different Binding Algorithm may call a
"helper service", passing in the list of bindings it discovered
and getting back a single binding to use.

These binding patterns and algorithms expect certain ways of modeling the
registry entries.  For UDDI, there are four building blocks
(business, service, binding, tmodel) that can be organized in various
ways.  If one "service" entry in UDDI has two (or more)
bindings, should I assume that both bindings are associated with the same
underlying "resource".  Say an organization provides two
mapping (GIS) service endpoints, both implement the same abstract
WSDL.  One endpoint would contain maps of USA, and the other
contains maps of Canada.  Each endpoint would have a UDDI
binding.  If I put the two bindings under the same UDDI service
entry (e.g., "map service"), then I cannot assume the two
bindings are associated with the same underlying
"resource".  One provides maps of USA, the other Canada;
two different "resources".  Alternatively, in UDDI this
can be modeled as two services: USA map service, Canada map
service.  Each service entry would have one binding.

The binding patterns and algorithms are designed to expect a particular
arrangement of registry entries.

In the example above, perhaps a taxonomy could be created to be used in
the categoryBag of the service entry.  The service categoryBag would
tell people that "all bindings refer to the same resource" or
"bindings may refer to different resources".  In the
latter case, perhaps a tModelKey is added to each binding to specify what
"resource" it refers to.  It is valid to assume that the
bindings listed under a service entry have something in common, but its
not clear exactly what they have in common unless we figure out a way to
make it more explicit (so we can factor it into searches).

At one point W3C WSDWG considered a "targetResource"
[3].

Perhaps WS-ServiceGroup [4] addresses this, but its not clear how the
"implied resource pattern" relates to a SOA Pattern that uses
UDDI or ebRS.

[2]
http://lists.oasis-open.org/archives/wsbpel/200403/msg00047.html
[3]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0121.html
[4]
http://xml.coverpages.org/ni2004-03-31-b.html

Paul