You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Nicholas Williams <nw...@ubiquitysoftware.com> on 2007/05/09 10:46:18 UTC

Use of a factory pattern with SCA

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




Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org


Re: Use of a factory pattern with SCA

Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org