RE: [sca-assembly-comment] Some more comments

Mike:

 

I think that answers my question, but raises two more 
comments:

 

[12a] this spec should really be part of the main Assembly 
model ! (definitely in a next version)   I notice that quite a few repeats 
from the main model were needed anyway to handle the extension, that would not 
be needed in a merger.

 

[12b] Is it really necessary to introduce new "Consumer" 
and "Producer" constructs ? couldn't these be just a particular 
 profiling of "Service" ? (and 
maybe also of "Reference" in case the producer function pushes the events). I 
believe that the main SCA assembly model should still say "something"  
about the pub-sub / event connection models. Even if new constructs (producer / 
consumer / channel) are needed to treat the full extent of these connection 
modes, end-users may still want to use the "basics" for  simple cases of 
event-based communication. Some best practice in appendix on how they can use 
(or profile) Service / Reference, would do the job. 

 

Regards,

Jacques

From: Mike Edwards 
[mailto:] 
Sent: Wednesday, June 24, 2009 1:01 
AM
To: Jacques R. Durand
Cc: 

Subject: Re: 
[sca-assembly-comment] Some more comments

Jacques, 

Regarding Comment 12: 

You may like to take a look at the OSOA SCA Event 
Processing specification which has been submitted to the OASIS Assembly 
TC 
and which forms part of the input to 
the resolution of Assembly Issue-80: 

http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/32379/SCA_Assembly_Extensions_for_Event_Processing_and_PubSub_V1_0.pdf 

While not in any way official as far as 
OASIS is concerned, it does show an SCA model for a more decoupled model for 
interaction between components using 
event sending and pub/sub techniques. 

Yours,  Mike.

Strategist - Emerging 
Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley 
Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: 
+44-1962-818014    Mobile: +44-7802-467431  
Email: 
  

  
  

    From: 
    "Jacques R. Durand" 
      <> 
  

    To: 
    <> 
  

    Date: 
    23/06/2009 22:48 
  

    Subject: 
    [sca-assembly-comment] Some more 
      comments

[Comment 11b] :  The chicken or the 
egg... (or the COmposite vs. the Component) 
(rewording of my previous comment #11) 
  
It is unclear why the Composite 
is always the outermost construct, as the markup 
indicates. It seems that the mark-up does not allow to expose the 
Component 
directly to users, yet the 
component has the same interfacing constructs 
(Services / Properties / References) as the Composite. 
Yet apparently SCA implementations will often directly expose 
Components (which may 
or may not be 
implemented as composites), e.g. in the C++ model. 
Couldn't the mark-up reflect this abstraction and make Component 
top-level (beside or even instead of Composite?) 
NOTE: this comment could be modified along my previous comment #9: if 
some form of "container" 
is needed for all 
kinds of SCA constructs (Services, Rferences, Components, Composites...) 

that should probably be something new, different 
from "Composite". 
  
  
[Comment 12]: Best practices 
for most typical architecture patterns? 
  

The control model suggested by Composites, is of 
Components invoking each others via 
references and wires. It is unclear how that plays with more decoupled 
architecture patterns 
between components: 

- publish-subscribe async communication 
between Components 
(should a queue manager be 
itself modeled as a component?) 
- event 
listeners. 
  
  

[Comment 13]: I don't think there is a clear 
definition of what an "SCA runtime" is. 
  

  
Regards, 

Jacques 

Unless stated otherwise above:
IBM United 
Kingdom Limited - Registered in England and Wales with number 741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU