Here are several design options for this situation
that occurred to me.
1. Since you are allowing this flexibility via XML
you could constrain the methods that they could call
to a generic set that is parameterized. So instead of
getPartNum/setPartNum it would get
get("PartNum")/set("PartNum", part) -- with strings
being used for everything since XML. Same with
getShoppingCart -- it would be get("ShoppingCart").
You would also have a create with possibly an array of
Stings, and an update, etc. That small set of
parameterized methods would be in an interface and all
of your EJB objects exposed to XML invocation would
implement that interface. Then when you get back the
EJB object from the home lookup, you would only cast
it as the (GenericInterface) and proceed with your
parsing and sending messages there. No need to know
that it is a Customer object if you're only sending
methods that are implemented in GenericInterface.
2. When you parse the XML, look up the home name in a
Hashtable and then the entry would be a "Handler"
class that you would instantiate and start. You would
write a Handler class for each EJB object exposed to
XML. The handler would be passed the XML when started
and would parse it as appropriate for that bean and
invoke the appropriate bean methods doing all of the
casting back and forth that are needed. So you would
have an object specific to each bean that acts like a
adapter converting the XML into EJB and back. I just
called it a Handler but you might call it an
"Adapter".
You've got to write a Home, Remote and Bean class for
each anyway. An adapter for each bean wouldn't be so
bad. The adapter classes would have a super class
that would contain common parsing routines.
3. You can carry the reflection further and look
through the method names for the object and invoke the
one that matches with the parameters. Put a lot of
Sytem.out.println's in there because you will probably
need them.
If most of your methods coming in will be the same
simple format then option 1 seems good. If you can't
get away with option 1, my preference would be option
2 because it gives you a lot of design latitude to
deal with specific types of situations uniquely -- for
example what if you need to send several methods or
talk to several beans under the covers as a result of
an XML request? Or you need to handle an exception
differently when you invoke the method? Or the
method's parameters that you want to invoke with
reflection are sitting in various parts of the XML?
Good luck,
- Mark
--- Thong Le <[EMAIL PROTECTED]> wrote:
> Hi Javier -
>
> Thank you for sending me the example of polymorphism
> in EJB. I have a comment, however. It has to do with
> casting after you get the bean object back. Let's
> say I have a Customer bean that I want to do a
> lookup for. Customer bean has a method
> getShoppingCart() that I want to invoke. The example
> you sent would do this:
>
> EJBeanManager bm = null;
> InitialContext ctx = null;
> EJBHome home = null;
> Object obj = null;
> bm = EJBeanManager(JNDI_FACTORY,JNDI_URL);
> ctx = bm.createNamingContext();
> home = bm.getHome("CustomerHome", ctx);
> (Customer)customer =
> (Customer)bm.create("CustomerHome", new Object[]
> {custid});
> result = customer.getShoppingCart();
>
> I would need to cast the bean to Customer, which I
> don't have the information. Can I do the following?
>
> ...
> home = bm.getHome("CustomerHome", ctx);
> Object obj = bm.create("CustomerHome", new
> Object[]{custid});
> String result =
> obj.getClass().getMethod("getShoppingCart",
> arglist);
>
> Looking forward to your comment.
>
> Regards,
>
> Thong Le
>
> P.S. In the previous mail I stated that we are using
> XML. The reason we opt
> to do this we are implementing a 3-tier arch. The
> presentation layer is using ADO, ActiveX component
> that talks to a COM-CORBA bridge that talks to the
> Server EJB. The EJB has a CORBA wrapper to the
> bridge and any CORBA client. The client sends XML so
> that we don't have to keep on changing the IDL for
> every time a client change. Going with XML will
> allow us to be independent of the client interface.
> This is what we're trying to achieve:
>
> I have a singleton session bean (call it ServerBean)
> that handles all the different clients. The only
> thing my client passes to the ServerBean is an XML
> string that contains the application home name,
> method name and its invoke parameters. The
> ServerBean will do a look up to obtain the correct
> bean instance. However, it can't cast to the bean's
> class name because it doesn't have the information.
> What I like to do is the following and please tell
> me if it can be done (using your example) this way:
>
> Client XML:
>
> <QUERY>
> <HOME>CustomerHome</HOME>
> <METHOD>getShoppingCart</METHOD>
> <USERINPUT>
> <userid> 1002 </userid>
> </USERINPUT>
> </QUERY>
>
> Inside the ServerBean class it does the following
> (assuming Customer has a method called
> getShoppingCart and it returns a string):
>
> public interface ServerBean implement SessionBean {
> public void execute(String XMLString) {
> EJBeanManager bm = null;
> InitialContext ctx = null;
> Object obj = null;
> try {
> // parse xml string
> jndihome = parser("HOME");
> methodname = parser("METHOD");
> arglist = parser("USERINPUT")
>
> bm = new EJBeanManager(jndiclass, jndiurl);
> ctx = bm.createNamingContext();
> home = bm.getHome(jndihome,ctx);
> obj = bm.create(jndihome);
> String result =
> obj.getClass().getMethod(methodname, arglist);
> }
> }
>
> So you can see why casting would not work well in
> the above example.
>
>
===========================================================================
> 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".
>
>
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
===========================================================================
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".
