On 11/12/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> On 10/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote:
> > On 11/10/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> > > 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...
> >
> > This is what I complained about. Its not clear. While it claims its
> > purpose is to align IT to business, it has left business concepts and
> > linkage between them undefined.
>
> No it didn't, it said that the _same_ terms and concepts apply at both
> levels. Therefore a service at a business level can use the same
> language and definition as that at a Software level.
So you basically want business to align with IT? And OASIS RM is about that?
> >
> > > > 2. Is it IT service? Then its purpose?
> > >
> > > Which is more detailed (less abstract) than the RM
> >
> > Plz elaborate.
>
> You've split the world into two camps and required translation and
> mapping. This is by definition less abstract as you've added in more
> concrete elements.
>
> >
> > > > 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.
> >
> > I think you need to first clear the scope of SOA to discuss this. you
> > are not clear about scope of SOA.
>
> The Scope of the SOA RM is to define the terms and conditions of SOA,
> at what ever level (business/Software/Hardware/etc/etc/etc)
>
> Which bit of the scope isn't clear?
IT has to support business? or Business has to support IT? Or they
have to be aligned?
Refer to my earlier question, IT has to be aligned to business or
business should be aligned with IT?
If Business Process Management concepts and standards develop
independent of SOA concepts and standards then who/what is supposed to
align them? Or you first intend to develop IT standards and then
envisage business to move around IT concepts? Or BPM to take advantage
of SOA?
> >
> > > >
> > > > 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.
> >
> >
> > SOA looks like? means what? around what concepts? Earlier you
> > mentioned its about concepts, vocab that should be used in context of
> > SOA. you mean to suggest vocab should not include words around
> > business, business process, business service but around reachability
> > and visibility?
>
> Including a tiered approach of biz->IT would remove one of the key
> powers of the RM which is that it can be applied to both the business
> and IT. Concepts of reachability and visibility are essential to pure
> business services and other capabilities as they are essential at the
> IT level. Why differentiate between two identical concepts when
> visibility for business process is the same as visibility for a
> hardware appliance?
Key concepts abstracted in SOA are Service, visibility, interaction,
effect etc..
> >
> > Let us know the scope of SOA first.
>
> I really am struggling to understand what you are after here, the
> scope is defined on the cover and at the start of the RM, which bit of
> that don't you think defines the scope?
2.3 The Benefits of Service Oriented Architecture
1. The main drivers for SOA-based architectures are to facilitate the
manageable growth of large scale enterprise systems, to facilitate
Internet-scale provisioning and use of services and to reduce costs in
organization to organization cooperation.
2. The value of SOA is that it provides a simple scalable paradigm for
organizing large networks of systems that require interoperability to
realize the value inherent in the individual components.
It seems very clearly intent of SOA as OASIS views it is for
management of IT systems.
> >
> > > >
> > > > 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.
> >
> > Service is not there always to be used directly by end user. Some
> > services may keep running without any user ever knowing about it. So a
> > service should be defined and described independent of end user.
>
> Which isn't what you said earlier, but putting that to one side for a
> moment this is exactly what the RM does, it provides a consistent way
> of describing service and consumer interactions no matter what the
> class of consumer or service (all services must have consumers).
Not sure. As no doesn't addresses concepts around/required to identify
a service, partition a service, service data, relation between service
models, service interaction points, service metrics, default service
policy, service organization and categorization, service requirement,
customization and extensibility,
> >
> > > >
> > > > > >
> > > > > > > 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.
> >
> > I meant the thing that a service should be definable, describable and
> > exist independent of its end user.
>
> Is it possible for a service to exist independently of a consumer of
> some form? This would means it doesn't interact with anything, isn't
> observable and doesn't achieve anything. The only perspective that
> should matter when describing a service to the outside world should be
> the view that the outside world sees. The internal functionality is
> separate and internal, but that is only reflected in the contract that
> the service offers.
"execution context" is a service? Its category? Why it is being
defined as different from "service" as in SOA?
> Now the RM does say that a contract is part of the overall service
> (producer) side and that it is independent of any individual consumer,
> is that what you meant?
>
> >
> > > >
> > > > 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.
> >
> > This I mentioned because you were only suggesting that service has to
> > be described from users perspective. Otherwise service doesn't have
> > any meaning.
>
> Given that the purpose of a service contract is to define how others
> interact with it I would say that it is best practice to describe it
> from their perspective rather than the internal view, this isn't
> mandated by the RM but is something I'd strongly advise.
>
> >
> > So abstraction of service is different form its users.
>
> a service contract is different from service execution if that is what you
> mean.
A service contract is not defined for execution as well? u are
suggesting that? But then is "deployment" is a service contract"?
Where are the concepts around service fulfillment? A service can not
always be defined as 100% successful or 100% failure!!
> > > > 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.
> >
> > If SOA is about alignment of IT along business, this must be reflected
> > in the RM.
>
> Why? Its goal isn't to define the implementation of SOA but the terms
> and conditions of SOA, the alignment is part of the _practice_ and
> therefore not in the reference model.
I have mentioned the concepts required to set the same, earlier in the
same mail.
And so you agree "Alignment of IT to business is not core of SOA"?
> >
> > Unless we define the terminologies around business as well, what
> > alignment are we talking about? forget about how? It doesn't helps to
> > elaborate one part and assume the other one.
>
> It elaborates both side, as I've said (several times) you can use the
> RM to define both the business side and the IT side. Business
> Process, like COBOL code, is an implementation detail that will apply
> in some, but not all cases, and hence isn't part of the broad concepts
> that the RM addresses.
CORBA reference model didn't get away just by defining object model!!!
It defined ORB, Application Interface, Domain Interfaces, Common
Facilities and Object Services and showed their relations.
Where are entities in SOA?
> >
> > > "How" isn't in scope for the RM it defines "What".
> >
> > That is what my point of contention is. RM fails to define what properly.
>
> So far you've not convinced me, at all, of you views of what the RM
> doesn't define. You appear to want the RM to be not a reference model
> but a guidebook for implementation.
I have mentioned earlier in this mail concepts around services missing.
> >
> > > >
> > > >
> > > > > > 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.
> >
> > I didn't mean to compare. I brought this point because soemwhere it
> > was mentioned that RM is more abstract and complete than Zachman
> > framework.
>
> The RM is more complete around the concept of SOA than Zachman, it is
> more abstract than Zachman in its totality. Hence the reason that you
> can use the RM in association with Zachman.
RM doesn't defines the terminologies around services completely.
Including service configuration, decomposition etc.
> >
> > > >
> > > > > >
> > > > > > > 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.
> >
> > Its not supposed to provide terminologies, as its not addressing those
> > concerns. And also terminologies varies from time to time, technology
> > to technology, enterprise to enterprise, vendor to vendor. Otherwise
> > its very consistent in its approach to EA.
>
> Which is one of the differences between it and the RM. The RM took on
> the challenge of defining the terminologies of SOA, Zachman looks at
> the practice.
What terminologies? All the difficult concepts around services are
left un-answered. Zachman defined terminologies around business
process etc, and information model etc. at higher level of abstraction
then SOA does.
> >
> > > >
> > > > > 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.
> >
> > If SOA is about aligning IT to business, it has left the more
> > important half's concepts, vocab, terminologies etc.
>
> No it hasn't, as before. You can use the RM to define business
> services and business capabilities. What it doesn't cover is
> implementation details on _either_ side of the Biz/IT divide.
> >
> >
> > > >
> > > > > 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?
> >
> > Yeah. It is without any ambiguity or understanding the concerns. The
> > picture tells the scope of SOA and mentions IT concepts/technologies
> > to achieve the same.
Its intended purpose itself as pointed out by me several times, is not
alignment as mentioned in the RM itself. If its intention is just to
define service and its description, then it was not required. As all
the services modeled and implemented till now had service description,
contract execution context etc, albeit using different technology,
documenting, code, IDL etc.
And it leaves the same hole, as it clearly mentions that SOA is
software architecture. About managing IT systems. And so RM for BPM is
bound to be different (as it is out of scope of SOA) and so
inconsistency continues.
> > > >
> > > > > >
> > > > > > > >
> > > > > > > > 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).
> >
> > Marketing is more important? Or service itself, its purpose,
> > description, availability, its scope, etc.
>
> The RM covers all elements of a service contract and description, but
> your argument was that visibility shouldn't be in there. If a service
> isn't visible then its pointless no matter how "good" it is, this
> applies at the IT level and at the business level.
I always maintained that more important higher level concepts were
left. I have outlined few of them.
> >
> > Remember we are still defining SOA itself, its scope, terminologies..
> > forget about its marketing. We market a product. But a product has to
> > be defined first, its scope, its concerns, its requirement,
> > terminologies. Marketing is secondary to product specification.
>
> No it isn't, marketing is an essential part of product specification,
> and indeed sometimes marketing is much more important than the
> specification itself.
>
> There are implementation details that are specific to a domain, these
> are not in the RM, however the critical success elements and what must
> be achieved is in the RM.
RM is incomplete. for reasons mentioned in this mail.
> >
> > >
> > > >
> > > > > >
> > > > > > 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?
> >
> > It can be. Way could be for sure same. Provided enterprises are run in
> > the same manner for same purpose in the same way as software systems
> > are. And variables affecting enterprises can be captured as precisely
> > as IT systems's. If we can abstract the scope, strategy, mission,
> > laws of land, etc. could be captured as precise or closer to as we can
> > capture an IT systems scope, patterns, usage etc.
>
> I was thinking of the other way around. Why can't IT be governed like
> a business. But either way you seem to be saying that the business
> level can be viewed in the same way, which is the point of the RM.
RM is about managing IT resources, as per OASIS RM.
> >
> > >
> > > > 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.
> >
> > No. RM should have defined scope, terminologies used within scope etc,
> > so that its not mis-understood and not ambigous.
>
> Your point appears to be that the RM should have created a clear
> separation between IT and business and then provided a way of mapping
> between them using SOA. The problem is that neither IT nor Business
> implementation are covered by the RM, we didn't cover how to build a
> service in IT, how to deploy it, how to management or any of those
> elements. This is the point, it doesn't do that on either side.
>
> Your argument appears to be that you think the RM should have had a
> different scope, but you haven't really said what that scope should
> be. Could you put in a paragraph exactly what you think the scope of
> the RM should have been?
In this case, as per OASIS RM its IT infrastructure, IT systems, IT
vocabulary etc.
> >
> > > >
> > > > > >
> > > > > > 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.
> >
> > Yeah I did read. But the figure one says "SOA and its relation with
> > other". This means everything else in the diagram is external to SOA
> > right? SO RM is guided by those concepts identified. Not that they
> > fall within scope of SOA.
>
> Errr no its external to the REFERENCE MODEL not SOA, so the SOA RM is
> used to drive reference and implementation architectures (it isn't
> directly implementatable itself).
This is why it is incomplete, very raw, scope is limited, as any
reference architecture derived from this RM is a description of a
subset of the reference model.
So I find your understanding of SOA RM and SOA little confusing.
--
---------------
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/
