sca-assembly-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-assembly-comment] Some more comments
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: "Mike Edwards" <mike_edwards@uk.ibm.com>
- Date: Wed, 24 Jun 2009 15:26:47 -0700
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]