RE: [sca-assembly-comment] Some more comments - relating to EventProcessing

[Mike Edwards <mike_edwards@uk.ibm.com>]

Jacques,

Some comments inline...

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:  mike_edwards@uk.ibm.com

From:	"Jacques R. Durand" <JDurand@us.fujitsu.com>
To:	Mike Edwards/UK/IBM@IBMGB
Cc:	<sca-assembly-comment@lists.oasis-open.org>
Date:	24/06/2009 23:27
Subject:	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.
 
<mje>
I agree with you that there should be a single
specification document as the output of this.  
The OSOA spec format is a compromise which we should not repeat at OASIS.
</mje>

[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. 
<mje>
We tried that in the creation of the OSOA
specification.
It is very hard to get it to work because
the semantics of connecting references to services dont match the
semantics of connecting producers to consumers.
 Event processing is MUCH looser.

The particulars include the fact that a service/reference
pair have interfaces at each end with potentially
multiple operations and the service must
have a superset of the operations on the reference.
For a producer/consumer pair, there is no
notion of an interface at each end that has any significance.
Operation names don't matter at all as far
as the connection is concerned. 
What matters is the event types that are
produced and consumed.  Strictly there is no need for the
consumer to deal with any of the event types
sent by the producer, although such a connection would be
a waste of time.

...but now we're starting to have the debate
that would take place in the TC  ;-)
</mje>
 
Regards,
Jacques

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Wednesday, June 24, 2009 1:01 AM
To: Jacques R. Durand
Cc: sca-assembly-comment@lists.oasis-open.org
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:  mike_edwards@uk.ibm.com

From:	"Jacques R. Durand" <JDurand@us.fujitsu.com>
To:	<sca-assembly-comment@lists.oasis-open.org>
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

---

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