RE: [soa-rm] Definition(s) of "service"

[Ken Laskey <klaskey@mitre.org>]

Joe,

I have no problem with your description of various services but what 
your example points out is that you will likely have underlying 
decision support capability that is accessed through a service rather 
than being integral to the service itself.  This only makes sense 
because decision support is an area of active research and we want 
ways to access evolving capability without having to rewrite and 
rewire our processes that depend on it.  More to the point, if we 
have to wait for the evolving technical capability to be codified in 
a new version of a standard (so we can build the service to the 
standard) we will always be way behind the curve and people will 
short-circuit the restrictive service framework.  There goes interoperability.

So from a specific architecture standpoint, I concur with your 
descriptions but not from the perspective of a general SOA definition.

Ken

At 12:35 PM 8/4/2005, Chiusano Joseph wrote:
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Thursday, August 04, 2005 12:26 PM
> > To: soa-rm@lists.oasis-open.org
> > Subject: Re: [soa-rm] Definition(s) of "service"
> >
> > The service is the container for the integration if the
> > integration is simple or the access to integration instructions (e.g.
> > orchestration/choreography) if the integration is more complex.
>
>Attached is a posting I just sent to the XML-DEV list (has not yet hit
>archives) - it highlights the various types of services (simple to
>complex integration), and may/may not resonate given your point above.
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>O: 703-902-6923
>C: 202-251-0731
>Visit us online@ http://www.boozallen.com
>
> > Ken
> >
> > At 11:47 AM 8/4/2005, John Harby wrote:
> > >But what responsibility should the service have in this "bringing
> > >together of the parts"?
> > >I would be very concerned about levying too much
> > responsibility on the
> > >service for the integration.
> > >
> > >On 8/4/05, Ken Laskey <klaskey@mitre.org> wrote:
> > > > Somehow saying service *provides* capabilities  misses the SOA
> > > > motivation to provide an effective way to bring together
> > the parts I
> > > > need to solve a problem.  Integration is often of disparate parts
> > > > that exist for their own purposes.  Service can help
> > coordinate but
> > > > the challenge is to make use of the tools/resources/capabilities
> > > > that already exist, not to create new stovepipes.  Saying the
> > > > service provides all this is a tempting simplification
> > but I fear it
> > > > will trivialize  the concepts most in need of clarification.
> > > >
> > > > Ken
> > > >
>
>Subject: RE: [xml-dev] SOA and the Single URL
>Date: Thu, 4 Aug 2005 12:32:19 -0400
>From: "Chiusano Joseph" <chiusano_joseph@bah.com>
>To: "Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>,
>         <xml-dev@lists.xml.org>
>
>Ah - now I see where you're going. Yes, a "dispatcher" service can
>categorized in three ways:
>
>(1) a "composite" service, (2) a "coordinator" service, or (3) a
>"process" service.
>
>With (1), multiple services are invoked as needed by a "primary" (for
>lack of a better term) service. This is a classic case in which - for
>example - a primary service invokes another service to execute some
>calculation, and the result is returned to the primary service.
>
>With (2), a service (called a "coordinator" service) whose sole mission
>is to coordinate the interactions among multiple other services as part
>of a single activity exists. This coordinator service is more of an
>"infrastructure"-type service in that it is not carrying out domain- or
>application-specific functions. An example of an emerging standard in
>this area is OASIS WS-CAF (Web Services Composite Application
>Framework), while an example of a specification is the combination of
>WS-Coordination/WS-Transaction (with the understanding that
>WS-Transaction is comprised of 2 specifications, WS-AT (WS-Atomic
>Transaction) and WS-BA (WS-BusinessActivity)). And WS-CAF, given the "C"
>in its name, can be considered as category (1) above, although I think
>it is more (2) since it is infrastructure.
>
>With (3), the service's functionality, when carried out, actually causes
>a state change in one or more resources. That is, inventory may be
>reduced, an account may be debited, etc. This is also different from (1)
>in that (3) involves orchestration (sequencing of activity steps,
>dependencies among services, etc.). An example of a service in this
>category would be a Purchase Order service that may be expressed using a
>specification/emerging standard such as OASIS WS-BPEL (which is not yet
>ratified - but will be soon), or its predecessor BPEL4WS.
>
>Hope that helps--
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>O: 703-902-6923
>C: 202-251-0731
>Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
> > Sent: Thursday, August 04, 2005 12:14 PM
> > To: Chiusano Joseph; xml-dev@lists.xml.org
> > Subject: RE: [xml-dev] SOA and the Single URL
> >
> > Too bad.  You missed a really fine party and a really bad war.
> >
> > The question is a good one.  Services.  In some approaches, a
> > single service may be acting as a dispatcher to other
> > services and the SOA is only exposing the one to the world.
> >
> > len
> >
> >
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> >
> > Sorry - I was born in the late 60s;)
> >
> > > but the
> > > question is, given an Enterprise Service Bus and an SOA, should one
> > > use a single URL to identify multiple processes?
> > > Yes, I know what a dispatching service is, but given REST
> > vs SOA, what
> > > do you think the consequences of a single URI approach are?
> >
> > Sorry Len, not following you 100% here - are you referring to
> > run-time processes, or separate services?
> >

--
      ---------------------------------------------------------------------------------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------