> > 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)
So you mean to suggest SOA has global scope? and It is more of a
management protocol than of aligning IT to its business goal?
> >
> > 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.
My issue is not what can be achieved by SOA. What can be achived
through it can be achieved by CORBA, or Jini or other techs. But issue
is what is intended out of whole effort? What is core thought behind
SOA? is it aligning IT with business goal? or is it "organizing and
utilizing distributed capabilities?
> 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.
These we can do with existing technologies as well. Though their
intended purpose is not the same.
> 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.
>
I agree. But same is not reflected through abstractions presented in
the paper. Where are the concepts around BP and IT that soa addresses?
> > 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.
I think abstraction should be layered around Business processes.
Business services, IT infrastructure/model and execution
infrastructure.
While the reference model seems to be revolving around the idea of Web
Services at its core, and refining the concepts bit more before
getting higher abstractions done properly.
> > 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?
Difference is mechanism doesn't guarantees service. Whether some one
is enabled to access the service is orthogonal to service's existence.
> > 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.
First get the high level abstractions is required to be done more
appropriately. Business concepts around BP is not identified, then
there is no concepts developed around Business services, No concept of
how the link or link between BP and BS to IT infrastructure/concepts
is not identified. But instead lot of work is done to refine the ideas
around web services.
> > 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.
I think we need to identify, conceptualize and then refine components
of SOA around
(Vision, Goal, Objective) and the term Means to refer generally to any
of the 'action plan' concepts (Mission, Strategy, Tactic).
Organizational structures and Resources • Functional breakdowns • Data
and information models • Strategy • Business Rules
Business processes - Abstract, public or global
Events, Activities, Message flow, group, task,
IT model, software architecture, pattern, components/objects,
deployment infrastructure etc.
I happen to attend Mr Zachman's worksop recently. And I believe EA or
buzzz word SOA needs to address enterprise and IT as a whole to
address agility of software systems for being business agile.
If SOA to succeed not another hype, it must first identify and relate
concepts around business and relate them with IT.
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/
