4. It was more interesting going down the OSSOSSOAOSSOSOA route...

But seriously.  I'd say that the SOA RM does a good job of saying what a
service is and what capabilities are

Service - "The means by which the needs of a consumer are brought together
with the capabilities of a provider. "
Capability - "A real-world effect that a service provider is able to provide
to a service consumer "

and of course the Execution Context - "The set of technical and business
elements that form a path between those with needs and those with
capabilities and that permit service providers"

So in other words its the Service that manages/arbitrates  access to the
capabilities and there is a bunch of technical & business stuff in the
middle that helps make it happen.  Simply for me a Service is a "What" and
its Capabilities are "Why" someone wants to communicate with it.

The best thing about the SOA RM is that it makes very clear that technology
infrastructure has NOTHING to do with SOA except as the execution context.
That is a powerful way of thinking about the difference between services and
enablement.

Steve





On 01/02/2008, Rob Eamon <[EMAIL PROTECTED]> wrote:
>
>   I can think of three reasons for the complete lack of response to the
> question of "what exactly are 'SOA services'?"
>
> 1. The question is viewed as a troll. As mentioned, my question is an
> honest one and is not intended to bait anyone.
>
> 2. The answer is readily available with simple searches such that I'm
> viewed as lazy for asking.
>
> 3. The answer is not readily available nor one that is universally
> agreed to, so noone wants to risk posting an answer for fear of, um,
> well I don't know.
>
> Michael's statement below, "WS has only some things in common with
> SOA Services", simply begs the question of what are the common things
> and what are the differences? (I'm assuming WS in this context means
> web services, not WebSphere--Michael please correct me if I'm wrong.
> Though if it means WebSphere, the quote really doesn't make sense to
> me!)
>
> In the loosest definition of a service, a facility that is "invoked"
> by dropping off a file in a particular directory and puts any
> possible reply (reply may not be necessary, depending on the details
> of the service) in another directory would qualify as a service.
> While such a service isn't appealling in many ways, it would still
> fit the notion of a service within a service-oriented environment
> (SOA being technology agnostic and all).
>
> In a more strict definition, only facilities that have an explicit
> (possibly machine readable) contract, is dynamically discoverable,
> exposes a business-level function and exchanges documents (as opposed
> to RPC-style) would fit.
>
> It is unclear to me, without elaboration, of why "WS has only some
> things in common with SOA Services." I submit that just about any
> definition of "SOA Service" will be viewed as too constraining by
> some and too loose by others.
>
> -Rob
>
> > Services
>
> --- In 
> [email protected]<service-orientated-architecture%40yahoogroups.com>,
> "Rob Eamon"
> <[EMAIL PROTECTED]> wrote:
> >
> > Hmm. What exactly are "SOA Services"? (Honest question.)
> >
> > -Rob
> >
>
>  
>

Reply via email to