Again, how about two "front" services that talk to the same "backend" service?  
Can  even imagine a
ServiceProxyFactory service that would automatically hook the front services to 
the backend service
with no code.

This would be more palatable if/when we add visibility.  The backend service 
would be private to the
module.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com


> -----Original Message-----
> From: Steve Gibson [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 10, 2004 9:23 AM
> To: [email protected]
> Subject: RE: [SPAM] - multiple interfaces for a service-point 
> question - Email has different SMTP TO: and MIME TO: fields 
> in the email addresses
> 
> 
> It is much easier to build a proxy object off a single interface than
> off multiple interfaces.
> 
> Unfortunately, your example is easily solvable in HiveMind - 
> startup and
> shutdown are events that your service can register for.
> 
> I have been thinking about the case where you expose 
> different parts of
> a class as different services though - to use HiveMind as an
> integration/middleware tool.
> 
> This would require a different service model, I believe, as you want 2
> sets of proxies pointing to one instance or pool of instances.
> 
> For example, in a small project, you have one class that does
> authentication and authorization, but you decide these are two
> interfaces, as in the future you may want to factor them out into two
> classes. You could just have one interface and a facade 
> class...but that
> can make configuration and interception messy.
> 
> Steve Gibson
> 
> -----Original Message-----
> From: Nelson, Randy [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 10, 2004 9:16 AM
> To: [email protected]
> Subject: [SPAM] - multiple interfaces for a service-point question -
> Email has different SMTP TO: and MIME TO: fields in the email 
> addresses
> 
> 
> The service-points only allow a service to implement 1 interface.
> However,
> there are times when it seems like it would be useful to specify that
> your
> service implements more than one inteface as in the description below.
> Hivemind hasn't been implemented that way, so I am sure there are keys
> reason why not so I was just wondering what was the thought process
> behind
> it?
> 
> 
> Example:
> 
> interface Add {
>   public void add(int arg0, int arg1);
> }
> 
> interface Startable {
>   public void startup() throws Exception;
> }
> 
> interface Stopable {
>   public void shutdown() throws Exception;
> }
> 
> =====
> 
>   <service-point id="Adder" interface="hivemind.examples.Addable">
>       <create-instance class="hivemind.examples.impl.AdderImpl"/>
>   </service-point>
> 
> ...
> 
>   <contribution configuration-id="Startup">
>     <task title="Adder"  order="100" >
>       <invoke-startup service-id="hivemind.examples.Adder" />
>     </task>
>   </contribution>
> 
>   <contribution configuration-id="Startup">
>     <task title="Adder"  order="1000" >
>       <invoke-shutdown service-id="hivemind.examples.Adder" />
>     </task>
>   </contribution>
> 
> =====
> 
> You have an Adder service that implements Addable.  You'd like to be
> able to
> contribute this to a "Startup" service or a "Shutdown".  However, you
> don't
> want to make all Addable services have to implement either/both of the
> Startable or Stopable interfaces. (In this case I am 
> expanding "Panorama
> Startup" example).  Are there ways to do this without the 
> Adder service
> implementing multiple interfaces and without combining all the methods
> into
> 1 interface?)
> 
> -Randy
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to