On 08/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote:
> 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.
What is higher level than visibility or reachability? I struggle to
think of more abstract concepts that mean that.
>
> > 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.
How is it? From the perspective of a consumer (the only one that
matters) they don't care about how elements are delivered, and there
must be some mechanism which makes the delivery, otherwise a service
is something that cannot be delivered.... which would be odd.
>
> > >
> > > > > 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.
Zachman is _not_ a reference model, it is an architectural framework.
It is a set of guidelines and approaches for the implementation of
architecture, Zachman could _use_ the SOA RM if it so wished but
Zachman (and TOGAF) are very different beasts for a reference model.
What you appear to be asking for is a specialisation of Zachman for
SOA, which was never the goal of the RM, but you should probably go
and have a look at the Reference Architecture currently being
developed.
>
> > 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.
As above, they are different things. Zachman does not define in a
consistent manner a single view of service that operates at all the
different levels, its goal is to help in the practice of architecture.
If you want a guideline on "how" to do SOA then.... read my book :)
>
> > > > > 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?
They are implementations in themselves, they are concrete outputs
defined for a specific task. A Mission statement is a CREATED element
specifically for a given architecture, a business process is created
for a specific business process... there is a big difference between
the goals of these elements and the goals of a reference model.
Implementation doesn't have to mean sofware or hardware is created.
>
> > >
> > > 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.
Eh? There are lots of diagrams in the RM, if you mean there isn't a
cut out and keep A0 diagram that will print out poster size then you
are right, and feel free to create one. You are confusing
implementation elements (i.e. how does this BP effect my service
architecture) with a reference model which looks to define the
abstract concepts of what a service represents.
The RM is like a dictionary, it tells you the terms, it is then up to
you the writer (architect) to create things out of those words. The
dictionary will tell you if you spelt them correctly, if the sentence
means anything, but it will not help you in the actual construction of
a sentence. This is the difference between the RM and Zachman.
>
> > >
> > > 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.
The SOA RM _can_ be used at a business level (I have done this) so no
disconnect exists. There was a long debate around whether it should
cover just software or broaden, in the end the decision was to focus
on software but ensure that the RM is applicable elsewhere, which IMO
it is. A service can be a pure business element with zero technology
and be 100% compliant with the RM.
>
> 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?
Why translate processes into services or vice versa? Why not consider
the enterprise as services that are implemented using business
processes. The RM is not about the "HOW" of doing the work, it is
about the terms.
>
> When major abstractions are missing, what we are supposed to do with
> refined ones?
It isn't missing, it was never intended to be in there, you are
confusing practice with a reference model.
>
> > 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.
Zachman 100% doesn't cover everything, neither does TOGAF, nor does
Capgemini's IAF, I'd really hate to see a single framework that tried
to include all the detail from business strategy and management
through to hardware deployment and unit testing.
Zachman is nice, its okay, have a look at TOGAF if you want a
standards based equivalent, but they certainly don't do everything.
>
> > 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?
Nope, boundaries can be abstract elements. The RM says that "this" is
a service and "this" is a capability and gives definitions, this means
that it provides a language with which to have discussions between the
different areas.
English is an abstract thing, but we can discuss many and varied things in it.
>
> 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 .
And here I'll get on my high horse and say "wrong", Service should be
driven by Service (the clue is in "S"OA) if Process drives it then it
would be POA. The goal is to deliver business services, some of which
are implemented by processes, IT or business and others are delivered
without using processes, for instance goal orientation.
>
> --
> ---------------
> regards,
> shashank d. jha
> e-mail [EMAIL PROTECTED]
>
>
>
>
> 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/
