Yes he value object approach would work if you re-delegated again.
If the ejb returns a smaller object class with just accessor and mutator
methods. I can see that now
class MyEJB { ...
String getHello() { return "Hello" }
String getWorld() { return "Word" }
String getName() {... }
void setName( String name ) { this.name = name ; }
String getSSN();
int getAge();
String getStreet();
String getCity();
String getDistrictCounty();
String getCountry();
String getPostcode();
String getHomeTel();
String getWorkTel();
String getHomeFax();
String getWorkFax();
String getURL();
String getEmail();
...
MyEJBInfo get() { return a value object }
}
The value object would be thus this local defined object.
class MyEJBInfo {
String getName() {... }
void setName( String name ) { this.name = name ; }
String getSSN();
int getAge();
String getStreet();
String getCity();
String getDistrictCounty();
String getCountry();
String getPostcode();
String getHomeTel();
String getWorkTel();
String getHomeFax();
String getWorkFax();
String getURL();
String getEmail();
}
It would thus have all the data and you won't be thrashing the server with RMI calls.
This is the old trade of memory and speed. It will take time to create each "value
object"
and send it back to the server. So we sacrifice some memory to gain a better network
performance overall.
And therefore the action form uses the value object instead of the EJB directly
further separating the user interface tier from the middle tier.
class DataForm extends org.apache.struts.action.ActionForm {
~~~~~~~~~~~~~~~~~~~~~~~~~~
private MyEJBInfo delegate;
~~~~~~~~~~~~~~~~~~~~~~~~~~
...
MyEJBInfo getInfo() { return delegate; }
}
My question is this architecture still valid for non-EJB systems. If you
are building a middle tier which may or may not go EJB / j2ee is it
worth building "upgradability" in the middle tier and front end tier (Struts)?
Is it worth "future-proofing" non-J2EE web apps now?
Thoughts
--
Peter Pilgrim | | ++44 (0)207-545-9923
.... \ \ ___ / / ... .
- ---- ( * ) --- --
_____________________________Cafe_Savannah,_San Antonio,Ibiza__
---------------------------------------- Message History
----------------------------------------
From: Peter Pilgrim/DMGIT/DMG UK/DeuBa@DMG UK on 25/09/2001 10:49
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: Help with Struts and EJBS..
With the delegation model approach, if I understand the Value Object approach
correctly I can associate an EJB with a ActionForm using delegation.
class MyEJB { ...
void setName( String name ) { this.name = name ; }
String getHello() { return "Hello" }
String getWorld() { return "Word" }
}
class DataForm extends org.apache.struts.action.ActionForm {
private MyEJB delegate
...
My EJB getVo() { return delegate; }
}
I can get write access to the properties using
<bean:write name="dataFrom" property="vo.hello" />
How do populate the EJB?
<form name="dataActionForm" >
...
Please enter your name:
<form:text name="vo.name" maxlength="24" length="16" >
...
</form>
Yes I can see how the nested properties would make it easier
to get the properties of the EJB. However I can not see how the
value object helps reduce excessive RMI calls. Since everytime
you call "DataForm.getVo().getHello() " you are making
another an RMI call with network overhead. The only way to stop
this is to pass another container object back and forth
between the UI bean and the EJB.
Thoughts?
--
Peter Pilgrim | | ++44 (0)207-545-9923
.... \ \ ___ / / ... .
- ---- ( * ) --- --
_____________________________Cafe_Savannah,_San Antonio,Ibiza__
---------------------------------------- Message History
----------------------------------------
From: Mike Dewhirst <[EMAIL PROTECTED]> on 24/09/2001 18:47 CET
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Help with Struts and EJBS..
> I need some serious help.
> I am a novice Java and Struts developer.
> I am trying to develope a prototype that will work with backend EJBS..
taken those 3 into account, I think you really do need serious help. Not
being funny, but usually people either working with other experienced
developers or simply with a few years of Java and some EJB exposure should
be endevouring with such a task.
> 1) Is this the appropriate way to call EJBS (in an action class)??
yes, it's fine to call EJB's from the action class.
> 2) How do I get what is returned from the EJB back into my actionform
bean?
you (presumably) will get back an object/collection of data back from the
EJB. you can parse it and populatev the form with it/add to the request -
then pull it out in the jsp with the struts cust tags.
> 3) If I want a list of matching customers retruned...what is the best
format
> for these to be returned from the EJB so that I can
> forward to another jsp and show them.. Currently the EJB is returning a
> string.
see above. To reiterate, put it an Collection (ArrayList for example) or in
a custom Object (JavaBean.. not Enterprise Java Bean!!)
> 4) Is there any sample applications out there that I can look at that use
> EJBs?
as far as I know not of Struts/EJB. Weblogic comes with a good load of
examples, so does the Struts install.
Mike
===================================================
Thanks in advance for ANY help.
Beth.
public ActionForward perform
(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
ActionForward fwdAction = null;
CustomerSearchForm searchForm = (CustomerSearchForm) form;
try {
// Get an InitialContext
Properties initProps = new Properties();
initProps.put (Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
initProps.put(Context.PROVIDER_URL,
"t3://yshen:7001");
Context ctx = new InitialContext(initProps);
Object home = (CustomerFacadeHome)
ctx.lookup("sov/CustomerFacade");
CustomerFacadeHome customerFacadeHome = (CustomerFacadeHome)
PortableRemoteObject.narrow
(home, CustomerFacadeHome.class);
CustomerFacade facade = (CustomerFacade)
PortableRemoteObject.narrow
(customerFacadeHome.create(), CustomerFacade.class);
String[] found = facade.findCustomer
(searchForm.getCustomerName (),
searchForm.getSsn (), searchForm.getAlphaKey (),
searchForm.getBank ());
for (int i=0; i<found.length; i++) {
System.out.println ("\t[" + i + "]\t" + found[i]);
}
fwdAction = mapping.findForward ("success");
} catch (Exception e) {
e.printStackTrace ();
fwdAction = mapping.findForward ("failed");
}
return fwdAction;
}
This message contains information which may be confidential and privileged.
Unless you are the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone the message or any information
contained in the message. If you have received the message in error, please
advise the sender by reply e-mail, and delete or destroy the message.
Thank you.
=**********************************************************
If you are not the intended recipient, employee or agent responsible for delivering
the message to the intended recipient, you are hereby notified that any dissemination
or copying of this communication and its attachments is strictly prohibited.
If you have received this communication and its attachments in error, please return
the original message and attachments to the sender using the reply facility on e-mail.
Internet communications are not secure and therefore the UCLES Group does not accept
legal responsibility for the contents of this message. Any views or opinions
presented are solely those of the author and do not necessarily represent those of the
UCLES Group unless otherwise specifically stated.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses although this does not guarantee that
this email is virus free.
**********************************************************=
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
