Indeed. -----Original Message----- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 10:50 AM To: [email protected] Subject: [SPAM] - Re: multiple interfaces for a service-point question - Email has different SMTP TO: and MIME TO: fields in the email addresses
What would be nice is multiple facets to a service i.e. contributing service points to other service points. -Harish Howard M. Lewis Ship wrote: >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] > > > > --------------------------------------------------------------------- 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]
