OK so here is another issue I have with this "Business Interface" design
pattern that I can't think of a good solution for.
Say I have 2 business interfaces : BusinessInterfaceA & BusinessInterfaceB
I define my 2 "local" or BO interfaces (and sure all the methods have to
throw RemoteException)
But what if I want to model an association between BusinessInterfaceA &
BusinessInterfaceB
I can't write a method on BusinessInterfaceA like:
public BusinessObjectB getAReferenceToYouWellKnownFriendMrB() throws
RemoteException;
Because when I move to my "remote" version of BusinessInterfaceA, the return
type of the method would need to change to
public RemoteBusinessObjectB getAReferenceToYouWellKnownFriendMrB() throws
RemoteException;
Now I can introduce some sort of Handle or Proxy mechanism, but then I get
into remote type casting (XXHelper.narrow() or
PortableRemoteObject.narrow()) which makes my code very messy.
Am I being particularly dumb here ? Is there a better way to do this ?
Cheers,
Matthew
> -----Original Message-----
> From: J. Matthew Pryor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 13, 2000 9:38 AM
> To: A mailing list for Enterprise JavaBeans development
> Subject: RE: MI2: Strategies to reduce EJB development time?
>
>
> All these approaches I have seen gloss over the fact that all
> methods in the "local" variant of the interface still have to
> declare themselves as throwing java.rmi.RemoteException which
> logically cuts across the implication that these are explicitly
> local objects, but I can understand all the other reasons for
> having to put the throws clauses there.
>
> Just a bit of a pain I guess.
>
> I suppose this becomes a requirement for all methods in an
> interface then, if you ever want your interfaces to form the
> basis of this kind of interface design, you should always throw
> java.rmi.RemoteException
>
> Kind of ugly, but .....
>
> Matthew
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Thursday, July 13, 2000 8:00 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: MI2: Strategies to reduce EJB development time?
> >
> >
> > Try this: http://www.javasuccess.com/cat1_may.html
> >
> > This was one of the "Challenge Winners".
> >
> > -Chris.
> >
> > CC: List because I posted the wrong URL before. Duh!
> >
> > > -----Original Message-----
> > > From: Humphrey Sheil [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, July 13, 2000 10:01 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: MI2: Strategies to reduce EJB development time?
> > >
> > > Chris,
> > >
> > > thanks for the reply. I think your idea below would help a
> > lot, if it was
> > > the subject of a JSR or the spec. was expanded / supplemented to talk
> > > about
> > > required development features. Then it could become a
> > selection criterion
> > > for IDEs.
> > >
> > > RE: design patterns, I guess you meant
> > http://www.javasuccess.com and not
> > > http://www.java.success.com
> > >
> > > I couldn't find the (incomplete) design pattern you mentioned
> > or even one
> > > that looked potentially like it. I looked here:
> > > http://www.javasuccess.com/cookbook.html
> > >
> > > and here: http://www.javasuccess.com/design_patterns.html but no joy.
> > >
> > > Is it posted on the website yet?
> > >
> > > Regards,
> > >
> > > Humphrey
> > >
> > > -----Original Message-----
> > > From: Chris Raber [mailto:[EMAIL PROTECTED]]
> > > Sent: 11 July 2000 21:18
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: MI2: Strategies to reduce EJB development time?
> > >
> > >
> > > What would be ideal is a light weight, non-distributed EJB
> > > server/container
> > > that runs In The Client JVM!
> > >
> > > Since we don't have this today, and since the integrated
> > environments are
> > > immature ( I have heard this from our customers too...), you might
> > > consider
> > > some design patterns that eliminate EJB'ness during
> development. In the
> > > GemStone/J Developer's Guide, the domain objects are not-EJB's.
> > EJB's wrap
> > > them for deployment. So one could develop, test and debug prior to
> > > wrapping
> > > as beans and deploying to EJB.
> > >
> > > There is also a design pattern for this approach on
> java.success.com. It
> > > is
> > > admittedly incomplete, but it's not a bad start.
> > >
> > > -Chris.
> >
> > ==================================================================
> > =========
> > 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".
