Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1

[Duane Nickull <dnickull@adobe.com>]

Hello Behera:

One of the challenges in architecture is determining the best way to 
document what you mean.  We opted to use a rather abstract stack diagram 
then elaborate with text.  This approach is used very commonly to convey 
meaning.

Since this is a reference model, not an architecture, cardinality of 
instances is not shown.  We stick to the abstract.  Cardinality of 
instances would be better suited for a reference or concrete 
architecture.  The drawing of one "service" in an abstract model leaves 
it open to "* service(s)" in a concrete architecture.  The same applies 
for other aspects such as security and semantics.  The concept only is 
represented, not the number of specific instances.  This in no way means 
you cannot have more than one service.

As for choreography, the jury is still out however most of the group 
seems to think that the concept of process, choreography or 
orchestration of multiple services is a layer that lives over top of 
SOA.  SOA is the ground layer.  A service does not need to determine or 
know if it is being called as a single service invocation or whether it 
is being invoked as a set of services coordinated by something higher 
up.  That something higher up is where the coordination lives. 

To me, it seems highly likely that a POA reference model is also needed 
to clarify the other side of this equation.

Best wishes..

Duane

 


Behera, Prasanta wrote:

>I also agree that we have to show the relationships otherwise it is hard to understand.
>
>Does the  SOA model consist of a single service? The diagram shows a single service.  The second line of Section 2 says " A service is an element ... " Is that the only type of element or there are others? The "loosely-coupled" notion of services is an important paradigm for SOA (IMHO) which we are not discussing.  Maybe a statement saying that "SOA consists of a set of services ... ". The power of SOA is that you have a set of services and a mechanism to leverage the services (via choreography).   (Sorry if I have taken this off track ...)
>
>On a lighter note (for the weekend).
>I came across SOF (It's a framework not an architecture), SOIF (Integration Framework), ... in a SOA conference. 
>The terminology seems to explode like the WS-* specifications
>
>Thanks,
>/Prasanta
>
>
> -----Original Message-----
>From: 	Duane Nickull [mailto:dnickull@adobe.com] 
>Sent:	Friday, May 13, 2005 10:00 AM
>Cc:	SOA-RM
>Subject:	Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure 2-1
>
>Frank:
>
>Comments inline.  I am not 100% happy with it either.
>
>Francis McCabe wrote:
>
>  
>
>>While I like the direction in which this is going, I have a couple of  
>>issues:
>>
>>1. I do not see semantics as being inside service description.  
>>Semantics is an abstract concept that may be referred to but is not  
>>contained in any description.
>>    
>>
>
>DN - full agree.  Semantics are present everywhere and abstract.  As 
>soon as something happens, human beings put a meaning to it.  One aspect 
>to consider is that someone could require a token (UDEF??) to be 
>included in a description that referenced a semantic entity.
>
>  
>
>>2. I am not sure why data model is broken out in the way suggested.  
>>To me, tehe data model is an asepct of the semantics of the service.
>>    
>>
>
>N - also agree. I like the stack better.
>
>  
>
>>3. I do not see a hard and fast distinction between syntax and  
>>semantics. Again, any syntactic constraints are simply part of the  
>>overall semantics.
>>    
>>
>
>
>I would suggest that we stay with the stack until Gregory submits an 
>alternative that we can discuss.
>
>Duane
>
>  
>
>>>      
>>>
>
>  
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Chair - OASIS Service Oriented Architecture Reference Model Technical Committee - 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  - http://www.adobe.com/enterprise/developer/main.html
***********