I agree with Mark ideas. Let me elaborate on number 3:
a) You should provide parameter type information in the XML.
Otherwise the Java reflection code will have problems
finding the right method to invoke. It will have to use
getMethods instead of getMethod and then loop looking
for the right method, and if it is overloaded then ...
b) Perhaps XML can specify a return type? This way you could
return a Vector, int, etc
<QUERY>
<HOME>CustomerHome</HOME>
<METHOD>getShoppingCart</METHOD>
<USERINPUT>
<userid type="int"> 1002 </userid>
</USERINPUT>
<RESULT type="String" />
</QUERY>
public void execute(String XMLString) {
EJBeanManager bm = null;
InitialContext ctx = null;
Object obj = null;
try {
// parse xml string
jndihome = parser("HOME");
String methodname = parser("METHOD");
// Ask XML for the parameter values
Object[] argvals = parserParamValues("USERINPUT")
// Ask XML for the parameter types
Class[] argtypes = parserParamTypes("USERINPUT")
bm = new EJBeanManager(jndiclass, jndiurl);
ctx = bm.createNamingContext();
home = bm.getHome(jndihome,ctx);
obj = bm.create(jndihome);
// Get the class
Class cls = obj.getClass();
// Get the method using parameters type information in XML
Method md = cls.getMethod( methodname, argtypes );
// Invoke the method and get the result ... always a String?
String result = md.invoke( obj, argvals );
// Perhaps XML can specify a return type? Vector, Integer...
Object resobj = md.invoke( obj, argvals );
} catch( ... ) {...}
You may find interesting ORACLE XML tools at
http://technet.oracle.com/tech/xml/
The XSQL Servlet is worth a look.
Let me know any more ideas about this.
Javier Borrajo
www.tid.es
-----Original Message-----
From: Mark Cassidy <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: viernes 10 de septiembre de 1999 5:26
Subject: Re: Dynamic lookup
>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".
