On 06/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote:
> > > 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?
Its hard to imagine how you can align IT to the business without
considering management, governance, lifecycle, funding and all the
other elements that go with it. If you are aligning to the business
goal then this means that you are delivering against that goal, which
means you are managing towards that goal. The SOA RM also however
covers how business can be viewed as services independently of IT, so
IT alignment is only one possible outcome.
SOA isn't just about management, but management is implicit in decent SOA.
>
>
> > >
> > > 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 is the difference? I've always argued that the aim here is to
get business and IT better aligned. But as the SOA RM tries to say,
organisation of distributed capabilities isn't just an IT challenge,
its a business challenge too (some of the examples are quite good at
explaining this).
Aligning IT to the business, or better yet having the business driving
IT is definately something that SOA helps with. It can also help
however in modelling abstract business elements, and help with
delivering effective solutions. Like OO which had a broad goal of
modelling real world objects and behaviour, SOA has a broad goal of
modelling real world effects and access. But to do that goal it needs
to be able to organise and utilise distributed capabilities. Without
that basic tenant it isn't much different to any other in the box IT
approach.
>
>
> > 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.
And nothing in the RM says that technology change is required to
deliver SOA. I'd argue that if current technnologies deliver the same
result then its very difficult to say that from a business (or
consumer perspective) that their 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?
The SOA RM RA is looking at the IT sides of this, and business process
is something that several people have looked at. A reference model
doesn't do the detail on either element, it provides the abstraction
that can be applied to both.
External to the RM I've argued that BP is a secondary element to
service (as defined by the RM) as flexibility comes from service, not
from process.
>
> > > 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.
Which is your view, but that is more an architectural view ala Zachman
or TOGAF than a reference model view. TOGAF and Zachman are _less_
abstract than the RM, specifically because they consider the layering
between these areas. The RM is _more_ abstract because it is able to
outline all of these things in a single framework.
>
> 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.
I'm missing the bit of the RM that majors on Web Services being the
core of SOA, could you point me to the sections you are talking about?
>
> > > 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.
I'm confused by this, you've said that visibility, reachability et al
are confusing and the "same" but now you appear to be arguing that
reachibility and visibility are distinct.
The service is the mechanims for provision, it provides the end and
enables the real world effect to be delivered. I'm not sure what you
are saying about the differences.
>
> > > 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.
Again I'm really missing (which is odd given I was on the group) the
majoring on Web Services, and I'm really missing the need in a
reference model (rather than in a TOGAF or Zachman architecture) to
define the mapping between the concept of service at the business
level and the concept of service at the IT level.
Why do you think that a reference model needs to be inconsistent
between the business and IT levels of SOA (if its consistent there is
no reason for there to be a mapping).
>
> > > 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.
That is implementation and architecture, not a reference model.
>
> 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.
You see this is why I should read _all_ of an email before replying.
I now understand your confusion. You are thinking that Architecture
is a reference model, it isn't, it is an approach to delivery. A
reference model provides the T&Cs for architectures, but architectures
say what gets actually done.
>
> If SOA to succeed not another hype, it must first identify and relate
> concepts around business and relate them with IT.
And for us to do that we must first define what SOA is. The SOA RM
provides a strong abstraction which can be applied at both of those
levels, the job of architects is then to provide a translation between
two consistent models, rather than previous where there was a large
disconnect between the business model and the IT model, the shearing
between those two is what has in part led to the disconnect between
business and IT that exists.
What you seem to be arguing is that the SOA RM doesn't do everything,
this is true it doesn't aim to be magic pixie dust, and that
architecture is needed to turn abstract models into project and
enterprise reality, again this is certainly true.
What you need to understand though is what the goal of the SOA RM is,
it isn't to solve the problem but to provide clear boundaries and
methods of communication within which the problem can be solved.
>
> regards,
> shashank
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
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/
