On 05/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> hi all,
>
> I was going through the reference model os soa by OASIS and I found it
> lacking seriously in most of the abstractions it talks about
>
> Lets start with soa definition itself-
> SOA- (SOA) is a paradigm for organizing and utilizing distributed
> capabilities that may be under the control of different ownership domains.
Now I agree with this one, its a bit abstract (but then it has to be)
>
> Till now my general understanding of soa was
> SOA is an architectural approach that seeks to align business processes with
> service protocols and the underlying software components and legacy
> applications that implement them.
Which is pretty much exactly what is allowed by the RM, except the RM
allows much more. The RM in paticular can be used to described not
just software elements but other IT and even business servicess.
What you are talking about is how the RM could be implemented in an
architecture, and that the goal of your concrete architecture is to be
business process driven and then automate this using a series of new
and existing IT elements. So you'd probably work out what
capabilities the processes required, then understand which of these
were already in the existing IT estate and which had to be built.
You'd then probably look at the best way to manage these capabilities
and to provide standardised access to them for you business process,
this would give you the services.
So the RM allows your view to work, it also allows those of us who
think that concetrating just on BP as a driver is an IT fixation
driven by the current marketing spend of BPM vendors to think of the
business as a series of services that co-operate to deliver business
goals.
>
> similarly abstraction of vocabulary execution context, visibility, real-world
> effect, interaction all seems to be too primitive, lacking in general high
> level abstraction.
How high level do you want it to be? Seriously, there aren't any more
abstract concepts than visibility, interaction and real-world effect.
And taking a look at execution context, most people wouldn't say that
overly detailed and specific was one of its problems.
As a member of the group I'd be really interested if there was
something even more abstract than the RM out there.
>
> At one point document says
> A service is a mechanism to enable access to one or more capabilities?
>
> Is service a mechanism or end?
What is the difference?
>
> In the topic "Dynamics of service" it has used so many closely related and
> confusing terms like visibility, awareness, real-world effect, willingness,
> reachability etc.?
Why are these closely related? If they are confusing it would be
great to understand what would help your comprehension so this could
be added so some of the communication documents that are being
created. From my perspective (mainly due to a background in UI design
and being on the group) the terms you mention are all pretty distinct.
Visibility means I must be able to see it, Awareness means that if I
don't know its there I won't go and look and Reachability means that I
need to be able to get to it from where I am. These all describe
different aspects of service discovery.
>
> What is the general opinion of people here?
Mine is that the SOA RM is currently the best definition we have, if
we need to make some of the language less confusing and have a bunch
more communication papers then lets get to it. But I would disagree
on the idea that the RM isn't abstract enough.
>
>
> ---------------
> regards,
> shashank
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/