[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
But it wasn't the wonders of SOA that saved them but SOA as an excuse
to restructure their faulty solution.
Ken
At 03:18 PM 8/4/2005, John Harby wrote:
>Well they were using what they thought was a modular OO approach but
>found all the dependencies introduced by inheritance and other OO
>relationships did not provide as much modularity as they thought.
>
>On 8/4/05, Ken Laskey <klaskey@mitre.org> wrote:
> > So basically what they relearned was the concept of modular design :-)
> >
> > Ken
> >
> > At 02:24 PM 8/4/2005, John Harby wrote:
> > >I agree. For example, I had a client that is an insurance claims
> > >processor, they service
> > >many large insurance companies. They found that every time they
> > >acquired a new customer, they had to rewrite their code that did the
> > >agent assignments and estimation handling. Their solution was to move
> > >to an "SOA" where they designed many services and used the
> > >orchestration to handle their processes. What they were able to
> > >accomplish was reducing the problem of significant changes to
> > >orchestrations only. In other words, the services were not changed,
> > >only new BPEL was created for the most part. This was a tremendous
> > >value add for the company. But although some services such as
> > >DataTransformation were orchestrations themselves and you could
> > >interpret that as integration, the highest level container would be
> > >the integration, not the service. Also, many services were not
> > >compositions so would not qualify as containers.
> > >
> > >On 8/4/05, Chiusano Joseph <chiusano_joseph@bah.com> wrote:
> > > > Depends on what we mean by "integration" - looking back at the messages
> > > > below, I don't believe that the notion of a service "containing the
> > > > integration" makes logical sense, as a service is "integrated" with
> > > > another service and therefore the "integration" really exists
> "external"
> > > > to the service.
> > > >
> > > > Joe
> > > >
> > > > Joseph Chiusano
> > > > Booz Allen Hamilton
> > > > O: 703-902-6923
> > > > C: 202-251-0731
> > > > Visit us online@ http://www.boozallen.com
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: John Harby [mailto:jharby@gmail.com]
> > > > > Sent: Thursday, August 04, 2005 12:49 PM
> > > > > To: soa-rm@lists.oasis-open.org
> > > > > Subject: Re: [soa-rm] Definition(s) of "service"
> > > > >
> > > > > Why does the service need to contain the integration? I would
> > > > > see it as the other way around. I would think many services
> > > > > should be able to run standalone with no integration
> > > > > knowledge whatsoever.
> > > > >
> > > > > On 8/4/05, Ken Laskey <klaskey@mitre.org> wrote:
> > > > > > 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.
> > > > > >
> > > > > > 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
> > > > > > > >
> > > > > > > > At 10:35 AM 8/4/2005, Chiusano Joseph wrote:
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Ken Laskey [mailto:klaskey@mitre.org]
> > > > > > > > > > Sent: Thursday, August 04, 2005 10:18 AM
> > > > > > > > > > To: soa-rm@lists.oasis-open.org
> > > > > > > > > > Subject: RE: [soa-rm] Definition(s) of "service"
> > > > > > > > > >
> > > > > > > > > > I'd still like to emphasize service as the access to
> > > > > > > > > > capabilities for which there are extra-service
> > > > > motivations for
> > > > > > > > > > their existence and requirements for use of the
> > > > > capabilities
> > > > > > > > > > that must be navigated by the service. Thus,
> > > > > > > > > >
> > > > > > > > > > "A service is a mechanism to enable access to a set of
> > > > > > > > > > capabilities,
> > > > > > > > >
> > > > > > > > >I would say that access control mechanisms enable such access,
> > > > > > > > >and that the service *provides* the capabilities.
> > > > > Note: Use of "access control"
> > > > > > > > >is too concrete for our RM - I stated it only to
> > > > > illustrate the point.
> > > > > > > > >
> > > > > > > > >Joe
> > > > > > > > >
> > > > > > > > >Joseph Chiusano
> > > > > > > > >Booz Allen Hamilton
> > > > > > > > >O: 703-902-6923
> > > > > > > > >C: 202-251-0731
> > > > > > > > >Visit us online@ http://www.boozallen.com
> > > > > > > > >
> > > > > > > > > > where the access is provided using a prescribed
> > > > > interface and
> > > > > > > > > > is exercised consistent with constraints and policies as
> > > > > > > > > > specified by the service description."
> > > > > > > > > >
> > > > > > > > > > Ken
> > > > > > > > > >
> > > > > > > > > > At 11:15 PM 8/3/2005, joe@pantella.net wrote:
> > > > > > > > > >
> > > > > > > > > > >Just trying to sort through this; some common themes that
> > > > > > > > > > >seem to be
> > > > > > > > > > >acceptable:
> > > > > > > > > > >
> > > > > > > > > > >A service provides capabilities.
> > > > > > > > > > >A service is accessible. (If this is true, then service
> > > > > > > > > > >cannot be a
> > > > > > > > > > >verb.) A service has an interface. (If this is
> true, then a
> > > > > > > > > > service has
> > > > > > > > > > >a boundary.) A service interface is prescribed. (Then a
> > > > > > > > > > service and its
> > > > > > > > > > >interface are distinct, and the interface has associated
> > > > > > > > > > >rules. I'm not sure this is true, the interface
> > > > > may describe
> > > > > > > > > > >the rules,
> > > > > > > > > > but Im not
> > > > > > > > > > >sure it has rules. In fact, I'm inclined to suggest that
> > > > > > > > > > the interface
> > > > > > > > > > >defines the rules for accessing the service. Which would
> > > > > > > > > > >lead me to suggest that the service interface is
> > > > > more than a
> > > > > > > > > > specification of the
> > > > > > > > > > >data model, but also of the policies associated with the
> > > > > > > > > > >service.) A service is a set of behaviors. (Not
> > > > > sure I'm on
> > > > > > > > > > >board with this, something about behaviors doesn't
> > > > > sit well.)
> > > > > > > > > > >
> > > > > > > > > > >Given this, perhaps something like:
> > > > > > > > > > >
> > > > > > > > > > >"A service is a bounded set of capabilities that are
> > > > > > > > > > accessible through
> > > > > > > > > > >a prescribed interface."
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >-- JJP
> > > > > > > > > > >
> > > > > > > > > > >P.S. I think this definition might just be flexible enough
> > > > > > > > > > to navigate
> > > > > > > > > > >the service offer/contract discussion also.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >-----Original Message-----
> > > > > > > > > > >From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> > > > > > > > > > >Sent: Thursday, July 28, 2005 12:32 PM
> > > > > > > > > > >To: Frank McCabe; SOA-RM
> > > > > > > > > > >Subject: RE: [soa-rm] Definition(s) of "service"
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >Frank,
> > > > > > > > > > >
> > > > > > > > > > >While I believe that the previously proposed definition is
> > > > > > > > > > sufficient,
> > > > > > > > > > >I offer the following as a compromise. Hopefully,
> > > > > the notion
> > > > > > > > > > >of "capabilities" addresses your issue of needing
> > > > > to get things done.
> > > > > > > > > > >
> > > > > > > > > > >"A service is a set of behaviors to provide capabilities
> > > > > > > > > > accessible via
> > > > > > > > > > >a prescribed interface."
> > > > > > > > > > >
> > > > > > > > > > >Ron
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >-----Original Message-----
> > > > > > > > > > >From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> > > > > > > > > > >Sent: Thursday, July 28, 2005 10:10 AM
> > > > > > > > > > >To: SOA-RM
> > > > > > > > > > >Subject: Re: [soa-rm] Definition(s) of "service"
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >I hesitate to spoil this party ... but I'm going to :)
> > > > > > > > > > >
> > > > > > > > > > >1. There is a distinction between action and result. (Just
> > > > > > > > > > >ask any
> > > > > > > > > > >roboticist) Behaviour sounds a child misbehaving with no
> > > > > > > > > > >discernible effect. Computer Scientists have a tendency to
> > > > > > > > > > >focus on the purely technical aspects of their work: bytes
> > > > > > > > > > >shuffling around at random within hopefully
> > > > > enormous memories.
> > > > > > > > > > >2. Also, we have to bear in mind that nobody invests
> > > > > > > > > > millions of $s (or
> > > > > > > > > > >even 100's of them) in systems that contemplate
> > > > > their navels
> > > > > > > > > > or have no
> > > > > > > > > > >business payoff. I think that we have to directly
> > > > > address the
> > > > > > > > > > >reason that services are deployed.
> > > > > > > > > > >3. One of the movitating best practice aspects of SOAs is
> > > > > > > > > > that clarity
> > > > > > > > > > >and 'separation' between the providers of services and the
> > > > > > > > > > consumers of
> > > > > > > > > > >services leads to more scalable and robust architectures.
> > > > > > > > > > >
> > > > > > > > > > >All of the above is fuzzy language; but, at the same time,
> > > > > > > > > > "A service
> > > > > > > > > > >is a set of behaviors accessible via a prescribed
> > > > > interface."
> > > > > > > > > > >sounds a lot like bureauspeak.
> > > > > > > > > > >
> > > > > > > > > > >I believe that there is strong consensus on the following
> > > > > > > > > > >characteristics:
> > > > > > > > > > >a. The concept of service is 'at the boundary' between
> > > > > > > > > > >service providers and consumers.
> > > > > > > > > > >b. The service is 'there' to get things done; but doesn't
> > > > > > > > > > itself denote
> > > > > > > > > > >the engine that performs the tasks.
> > > > > > > > > > >c. There is a reason for using a service.
> > > > > > > > > > >d. There is a lot of extra metalogical information about
> > > > > > > > > > services that
> > > > > > > > > > >make it possible for third parties to develop
> > > > > partners for services.
> > > > > > > > > > >
> > > > > > > > > > >I, for one, would prefer a strongly anglo-saxon
> > > > > phrasing of
> > > > > > > > > > >the definition of service that speaks to these points.
> > > > > > > > > > >
> > > > > > > > > > >Frank
> > > > > > > > > > >ti
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > >
> > > > > --------------------------------------------------------------
> > > > > > > > > > -------------------
> > > > > > > > > > / Ken
> > > > > > > > > > Laskey
> > > > > > > > > > \
> > > > > > > > > > | MITRE Corporation, M/S H305 phone:
> > > > > 703-983-7934 |
> > > > > > > > > > | 7515 Colshire Drive fax:
> > > > > > > > > > 703-983-1379 |
> > > > > > > > > > \ McLean VA 22102-7508
> > > > > > > > > > /
> > > > > > > > > >
> > > > > > > > > >
> > > > > --------------------------------------------------------------
> > > > > > > > > > --------------------
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > >
> > > > > --------------------------------------------------------------------
> > > > > > > -------------
> > > > > > > > / Ken
> > > > > > > > Laskey
> > > > > \
> > > > > > > > | MITRE Corporation, M/S H305 phone: 703-983-7934 |
> > > > > > > > | 7515 Colshire Drive fax:
> > > > > 703-983-1379 |
> > > > > > > > \ McLean VA 22102-7508
> > > > > /
> > > > > > > >
> > > > > > >
> > > > > --------------------------------------------------------------------
> > > > > > > --------------
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > --------------------------------------------------------------
> > > > > -------------------
> > > > > > / Ken
> > > > > > Laskey
> > > > > \
> > > > > > | MITRE Corporation, M/S H305 phone: 703-983-7934 |
> > > > > > | 7515 Colshire Drive fax:
> > > > > 703-983-1379 |
> > > > > > \ McLean VA 22102-7508
> > > > > /
> > > > > >
> > > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > > ------------
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> > --
> >
> ---------------------------------------------------------------------------------
> > / Ken
> > Laskey \
> > | MITRE Corporation, M/S H305 phone: 703-983-7934 |
> > | 7515 Colshire Drive fax: 703-983-1379 |
> > \ McLean VA 22102-7508 /
> >
> ----------------------------------------------------------------------------------
> >
> >
> >
> >
--
---------------------------------------------------------------------------------
/ Ken
Laskey \
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax: 703-983-1379 |
\ McLean VA 22102-7508 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]