Nicholas Williams wrote:
Hi all,
Section 1.4.1 of the SCA Java Common Annotations and APIs specification states
the following:
"Using reference injection is the recommended way to access a service, since it
results in code with minimal use of middleware APIs. The ComponentContext API should be
used in cases where reference injection is not possible."
Injection is not appropriate where a client component does not know how many
service components its will need to create until runtime. Conferencing is a
good example of this, how many participant instances should be created?
In order to dynamically create the objects we need, we have devised the
following pattern:
* The factory will be stateless.
* The factory will be injected into the client component.
* The factory will create a specific type of component.
* The factory will use the ComponentContext to create the required component.
* The created component must obey the specified implementation scope,
stateless or conversational.
* The factory will use the RequestContext to connect up any callbacks
between the component and the client.
* The connected callback must also obey the specified implementation scope, stateless or conversational.
Does anyone have any thoughts as to whether this:
* Is perhaps trying to bring an OO style of programming to what is really a
SOA environment?
* Whether the callback aspect is realistic?
* In short, is this a good pattern or an anti-pattern?
Any thoughts would be much appreciated
Thank you
I am trying to understand the use case that you're after and have a few
questions:
Taking your conferencing example, would you want to create a new
component (with a different component name, configuration, wires etc.)
to represent a conference participant? In other words are you looking
for Java APIs to define or augment an assembly dynamically, as an
alternative to a fixed XML document?
Or do you have a fixed set of components already defined and configured
in your assembly, and need to create a new instance of a defined
component to represent a conference participant? I guess this would look
like some kind of scoping mechanism, introducing a different scope than
Composite, Request, or Conversation. Actually, I don't know enough about
your use case yet, but if somebody joins a conference this may nicely
map to a form of Conversation establishment...
Where would a newly created component run? the current composite and
active component? somewhere else in the SCA domain?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
