On 11/7/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> > So you mean to suggest SOA has global scope? and It is more of a
> >
> > > > 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.
Hmm.. My opinion was regarding in general that concepts and elements
have to be evolved at higher level than getting into nitty-gritty of
the same. My opinion is that RM has not properly found out higher
elements properly.
> 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.
I want to say is that service is different that the mechanism that can
be used to access a service.
> >
> > > > 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.
Because they are not aligned. And thats why need solution around
Zachman framework, or EA or now buzzzzz SOA.
> 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).
I always meant that they have to be consistent. So we need to take or
consider holistic view of an enterprise like Zachman framework does.
This ensures consistency. but its too abstract and ideal and vast to
be filled up completely.
> > > > 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.
Mission/Strategy/Tactic business process? architecture/ patterns,
interaction, message flow. event flow?, components, IT model,
activities are implementation of what?
> >
> > 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.
I am saying that an architecture should have a reference model. And
reference model should show its major components and their relations.
The RM by OASIS for SOA is not proper. There is not even a single
diagram to show RM. One diagram that shows relation of RM with others.
This is where Business motivation etc are covered. This means BP, BS,
motivation are not intrinsic to SOA. So has limited scope.
> >
> > 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.
Exactly. and definition of SOA by RM of OASIS is not even including
word business in its definition. So disconnection still exists.
What is strong in abstraction provided by it? Abstraction of business
process? Abstraction of IT service? Abstraction of linkage between
two? Translation mechanism between two?
When major abstractions are missing, what we are supposed to do with
refined ones?
> 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.
Zachman framework does everything. But unfortunately no one has done
it completely.
> 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.
You have to be consistent. Earlier you were telling that RM is more
abstract because it doesn't provides boundary and now you are saying
otherwise?
Also some where in the mail, you mentioned that
>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.
BP is not secondary element. It should drive IT service. SO focus is
business process/ business service .
--
---------------
regards,
shashank d. jha
e-mail [EMAIL PROTECTED]
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/
