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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] 
> Sent: Wednesday, May 18, 2005 12:55 PM
> To: Chiusano Joseph; SOA-RM
> Cc: John Harby
> Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
> 
> 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.

Or is it "in modeling services"?

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 
 
> 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
> >>
> >
> 
>