Re: [soa-rm] FYI: BEA SOA Reference Diagram

[John Harby <jharby@gmail.com>]

"However, we are *not* doing an SOA!!! At least, that is my
understanding.

Instead, we are examining (!) the concepts and relationships that are
important in modeling SOAs."

Examining the concepts and relationships that are important in
modeling SOAs is not an "SOA reference model". A reference model
should serve as a point of reference for someone wishing to do an SOA.
The statement you are making is neither specific or measurable.

On 5/18/05, Frank McCabe <frank.mccabe@us.fujitsu.com> wrote:
> The diagram does not help me very much ...:)
> 
> I agree, however, that combining services seems to me to be an
> integral part of service oriented architectures.
> 
> However, we are *not* doing an SOA!!! At least, that is my
> understanding.
> 
> Instead, we are examining (!) the concepts and relationships that are
> important in modeling SOAs.
> 
> So, for example, if service combination is an important concept of an
> SOA that needs to be modeled, then we should see how to. (See below).
> However, Duane, and others, have quite rightly pointed out that an
> service that is *implemented* by combining several services is not in
> scope for our work: precisely because an important aspect of SOA is
> that how a service is implemented is strictly on a need to know
> basis, and typically users of a service (and occasionally even
> implementers of a service) do not need to know.
> 
> The other kind of service combination is what might be considered as
> a *transparent* service combination. A good example of this kind of
> service combination is how you might give someone advice about how to
> achieve a goal: to get yourself a bank account (if you are a new
> immigrant to the US), you first of all have to get a social security
> number, and then get a letter from your employer and then go the
> right bank, etc. etc. None of these services are ever likely to be
> integrated into a single service whose implementation is hidden: you
> have to know yourself how to achieve your goal.
> 
> Such transparent service combinations are the stuff of things like
> BPEL <duck/> and W3C's CDL <also/> And, maybe, ourselves.
> 
> Incidentally, if you *do* need to include service combination in the
> modeling of SOAs, I think that the simplest approach is simply to
> identify -- again at the modeling not messaging level of abstraction
> -- a service as a resource. Because, aggregating service is
> fundamentally the same as aggregating resources.
> 
> Frank
> 
> 
> On May 18, 2005, at 9:34 AM, Chiusano Joseph wrote:
> 
> > John,
> >
> > Thanks for this diagram. IMHO, it is the general direction that I was
> > hoping our TC would go from the very beginning (one may/may not
> > agree of
> > course with each and every component). SOA is so much more than a
> > single
> > Service (the bottom layer of our Figure 2-1.
> >
> > There's still time...;)
> >
> > Joe
> >
> > Joseph Chiusano
> > Booz Allen Hamilton
> > Visit us online@ http://www.boozallen.com
> >
> >
> >
> >> -----Original Message-----
> >> From: John Harby [mailto:jharby@gmail.com]
> >> Sent: Wednesday, May 18, 2005 12:23 PM
> >> To: SOA-RM
> >> Subject: [soa-rm] FYI: BEA SOA Reference Diagram
> >>
> >> http://www.bea.com/framework.jsp?CNT=soa_ref_arch.htm&FP=/cont
> >> ent/solutions/soa
> >>
> >
> 
>