I think your stateless session bean is really beside the point in this issue. In my opinion your best design approach would be to use adaptor and helper classes. ie You'd encapsulate the business logic in a helper class which would probably create data-wrapper classes (domain objects) containing your translated information. But you wouln't allow your client code (probably servlet methods) to directly access your business logic. You'd implement an adaptor class or facade layer between servlet and business logic.
Then if your application needed to scale-up and/or needed to be re-used by other client classes running in different contexts, you could implement a session bean between the helper class and the adaptor class. The session beans remote interface would implement the adaptor classes business methods. The session beans home interface would implement the adaptor class' creation/finder methods. The adaptor class might need to be re-written to handle the session bean (or you could possibly implement a state pattern and use a different concrete adaptor depending on whether the request was local or remote - dont know of the top of my head how you would implement that tho) but its interface would remain unchanged.
The point is that the controller layer would be blissfully unaware of whether you had a distributed model or not as the adaptor class' interface would remain unchanged. Just the implementation would need to change.
If you have one set of use-cases (ie "system") accessing another - then loosely couple them by using facade layers - if any one side of the contract changes - the other side needn't be aware of it.
Hope that's helpful
Gareth
>From: Ionel Condor <[EMAIL PROTECTED]>
>Reply-To: Ionel Condor <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: not every thing is an ejb?
>Date: Tue, 27 Nov 2001 11:32:29 +0200
>
>Hi,
>My opinion is that in this case a helper class is the right solution. I see the
>use of the session ejb-s only for business logic that needs/requires the
>advantages of the ejb container.
>I usually put such things in a helper class added to the jar file that contains
>the ejb-s.
>Anyway, in case that you have to call it also from a servlet (so the war file),
>here an ejb approach fits
>better, otherwise please help, a common helper for both jar and war files seems
>a little bit complex; it's possible to mix in an .ear file this helper (via
>config files, ...)?
>
>Regards,
>Ionel.
>
>"Katz, Guy" wrote:
>
> > hi;
> > here is another point i have been strugling with.
> > for an application in the J2EE environment. i need to provide a component
> > that provides multi-lingual support. as usual i am stuck deciding whether to
> > implement this service as a staeless session bean with a traslate(...)
> > method or to write a regular class doing this. if i write it as a regular
> > class then how should i package it? it serves several ejbs and servlets so
> > is it good to package it as a helper class in all ejb.jar and war files?
> > what else can i do?
> > is writing a singelton regular class that gives this functionality a
> > solution? in such a case how should this be packaged?
> > thanks
> >
> > __________________
> > Guy Katz
> > Comverse
> > [EMAIL PROTECTED]
> > +972 3 7663686
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
