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

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

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
>>
>