On 10/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote:
> On 11/9/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Higher Level means first
> 1. What is Service Oriented Architecture?
Which is what the RM does...
> 2. Is it IT service? Then its purpose?
Which is more detailed (less abstract) than the RM
> 3. If it is to support BP/BS directly? (Means there is direct link
> between the IT service and BP/BS and technically it should be
> viable/feasible to traverse along them) or indirectly like everyother
> technology tries to do. Ultimately an enterprise uses IT for it BP/BS
> only.
Again this is more detailed (less abstract) than the RM.
>
> 4. Where are the terminologies around Business motivation, business
> process, business service, IT architecture, pattern, components,
> service?
Not in there because they have nothing to do with the T&Cs for the RM.
These are elements around HOW you do SOA, whereas the RM just says
what "good" SOA looks like.
>
> OASIS RM directly starts talking about visibility or reachability!!!
> of what? business motivation service? Business process, business
> service, infrastructure component service? architecture service,
> service publication service? or what?
All of the above. If your motivation (considered as an abstract
business service) is neither visible or reachable then it can be said
to not exist from the perspective of the enterprise... etc etc.
>
> > >
> > > > 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.
>
> Any IT is not supposed to be defined and described from its users
> perspective. Lets first construct it. And then try to define it from
> users perspective. It may be good idea to start first from consumers
> perspective but then its just view not service itself?
I don't get what you are saying here, the words on their own make
sense, its just the sentences that I'm struggling with.
>
> Not always, not all services are supposed to be accessed by end
> consumer. Some would be delivered by deployment platform to service
> executing on it.
The concept of "end" means nothing to a service, it has only
consumers, why should it care if there are things beyond it? This is
the point of the RM, making an arbitary distinction between "end"
things being consumers and "internal" things doesn't actually make a
difference from the perspective of defining an abstraction of
consumers and producers.
>
> Like mentioned in other mail, first get clear whether service
> description/definition includes characteristics of deployment env. or
> is independent of it. How to deploy a service? There is no concept
> terminology identified around that as well. Forget about constructing
> it. Define first service properly. IT is not access mechanism. May be
> there could be something like accessing service!
This wouldn't be _more_ abstract it would be much less abstract than
the RM. Why would defining how to deploy a service make the RM more
abstract?
>
> > >
> > > > >
> > > > > > > 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.
>
> Else how do you align IT to business need?
The RM isn't pixie dust, it doesn't do the alignment, it defines the
terms and conditions. It doesn't do implementation, which is exactly
what a "how" is about.
"How" isn't in scope for the RM it defines "What".
>
>
> > > 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.
>
> Zachman's scope if wider than scope of SOA. And I meant that RM is not
> addressing enterprises IT concern. As a reference I pointed out so
> many concerns needs to be considered as mentioned in Zachman's
> framework to be able to come out with RM and than an architecture to
> align IT to business.
Eh? The RM isn't a competitor to Zachman, people who use Zachman (and
frameworks like it) can use the RM to provide a more formal definition
of SOA than the one that Zachman has and then use Zachman as the
approach to their implementation.
You are comparing apples with oranges to compare the RM and Zachman.
>
> > >
> > > > 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.
>
> I think it does provide a consistent view of same service across
> organizational and granularity level.
It provides a mapping, not a consistent set of terms and a model that
works at all those levels.
>
> > 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.
>
> And what is goal of RM? to provide terminologies around SOA? and it is
> excluding the words of concern.
Could you reword the second sentence, the RM is addressing the areas
of concern as laid out in the original terms of reference for the
group. The RM is _not_ trying to create some "uber" standard to rival
TOGAF, thus elements of implementation of SOA (like motivation,
mapping, governance, security et al) are excluded.
>
> > 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.
>
>
> I suggest you to look into SOA diagram published by OMG in its
> initiative to get standards for SOA to know what I meant.
I've looked at it.... and that helps you at the abstract level?
>
> > >
> > > > >
> > > > > 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.
>
> I can use CORBA, Jini, UML etc. around business concepts but that is
> not their intended usage. Similarly SOA RM has not cared to explore
> vocab or ideas that needs to be addressed by SOA.
I can 100% use the SOA RM language in a business environment, I have
done in fact and it worked (concepts of visibility matter in any
consumer/producer interaction for instance, that is why people have
marketing departments).
>
> > >
> > > 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.
>
> Enterprise is not a service. Because the laws that govern an
> enterprise is not directly applicable to laws that govern IT services?
Why can't IT be governed in the same way as the enterprise?
> conceptually/logically its different. But we can always abstract like
> that and then call it "abstract service" and then Business BP or
> service is one realization of service and IT services are another
> realization.
>
> Neither enterprises related terms are included, nor business related
> terms nor motivation, nor governance related terms nor service is
> defined properly. Neither linkage among various concepts are shown
> properly. what else.
Nor are they meant to be. You really seem to be expecting the RM to
be a Zachman/TOGAF/IAF competitor, but that isn't its motivation, its
to get agreement on a VERY simple thing...
What is a service
What is SOA
And then enable the likes of Zachman/TOGAF/IAF/CBM etc to use that
definition to make it simpler for themselves.
>
> > >
> > > 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 is a reference model?
"A reference model is not directly tied to any standards, technologies
or other concrete implementation details. It does seek to provide a
common semantics that can be used unambiguously across and between
different implementations. The relationship between the Reference
Model and particular architectures, technologies and other aspects of
SOA is illustrated in Figure 1."
You did READ the RM didn't you? This is on the opening page.
>
>
> > >
> > > > 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 is missing from Zachman's framework?
>
>
> > > > 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.
>
> Unless it clearly identifies service? It says service is about
> organizing distributed capabilities ..bla bla... I thought all the
> management services/tools were about that. Not SOA. It was about
> aligning IT to business.
>
>
> > > 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.
>
> (-> drives)
>
> Business process-> Business service -> IT service
>
> ->components ->real resources
>
> Correct. Because IT service dont drive business, business should drive
> IT, and that is SOA. So its scope is from enterprise motivation to
> delivery model.
>
>
> --
> ---------------
> 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/
