Hi Bob, you make some great comments in this posting.  The scenario you describe in 
"keeping value objects in sync with ActionForms" will strike a familiar chord with 
many developers.

Check this out, the Appserver that I am most familiar with is unfortunately a very 
small player in the j2ee appserver market but has some key features that I love to 
rely on (the appserver is PowerTier from Persistence Software).  One feature that 
helps out here is the auto-generation of "pass-by-value" objects for each CMPD Entity 
bean that is generated for you.  Although it is a bit "heavy", it is a great time 
saver and allows you to keep entities and value objects in synch transparently.  They 
even generate ClassHome.create(ClassValue) methods for you so you can create (and 
update) your entities directly with your Value (state) object.  No more custom entity 
methods that simply copy one field to another.

How many other ejb containers do this?  I don't have a whole bunch of experience on 
other containers and I am really curious.

In anycase, I think that for seemless EJB/WebApp integration you hit the nail right on 
the head.  We need to automate value bean management and we need standard ways of 
describing our solutions.

We'll save "security context passing" and session management for later. :)

--Steve

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 7:45 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [EJB] java report article says "bye-bye struts"
> 
> 
> 
> Just a few comments. I picked up a book while out at JavaOne 
> called "core
> J2EE patterns" which is hot off the press and written by a 
> few guys that
> work at Sun Java Center. Personally, I did not find any 
> breakthrough ideas
> in here, but it is a well written book that also describes 
> what not to do
> and effectively demonstrated how to turn bad design into good 
> design (and
> provides nice pattern names for these design strategies). It 
> solidifies what
> most of us have been doing for the past year or so on J2EE 
> projects. I think
> that any EJB support included in Struts should be structured 
> around the
> patterns in this book. 
> 
> For example:
> *Value Objects to exchange business data with EJBs
> *Business Delegate to reduce coupling between client and 
> business services
> 
> My greatest concern with Struts-EJB integration is how we can minimize
> development time, yet still come up with an intuitive and 
> flexible design.
> The ActionForms are the part that is still bothering me. 
> Proper design would
> say that ActionForms belong only on the client, to mirror the 
> data presented
> on HTML forms. But you need to build a similar structure 
> (Value Object) to
> get this data from the client tier to the EJB tier. I just completed a
> project where we started off doing this, but soon noticed 
> that ActionForms
> and ValueObjects were almost identical, and trying to keep to 
> two in synch
> was a mess. So, we used the ActionForm for both purposes and 
> passed them
> directly to the EJB tier. Coupling could have been slightly 
> reduced by using
> an interface, but then you are back to keeping 2 objects in 
> synch again.  Of
> course this design only works well when the EJB data model 
> are Client data
> model are similar, but this is not always the case. There 
> were a few cases
> where we did not have a one-to-one mapping and then things 
> were not very
> pretty. The point I am trying to make here is we need a flexible, and
> dynamic, way of mapping ActionForms to ValueObjects then to EJBs.  
> 
> Part of this will be solved if the next version of Struts 
> supports dynamic
> creation of the ActionForms, as listed in the 1.1 to-do (no 
> volunteer yet?).
> (Has it been decided how this will be dynamic? What will be 
> used to specify
> how to build the ActionForms- is the plan to do this directly 
> from the JSP?)
> Then, the developer will need to supply the ValueObjects and 
> utilize some
> sort of mapping mechanism between the DynamicActionForm and 
> ValueObject
> (such as an enhanced version of the PropertyUtils). I think 
> this would fit
> with the idea of a Business Delegate- to decouple the client 
> from EJBs.
> 
> What do you think?
> 
> 
> -Bob
> 
> 
> 
> 
> 
> -----Original Message-----
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 5:36 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [EJB] java report article says "bye-bye struts"
> 
> 
> To Anyone It Concerns,
> 
> Although I'm relatively new to EJB's, I'm listed on the 1.1 TODO list
> to add better EJB support/design patterns.  Ideas that anyone 
> has about
> things that they'd like Struts to do with EJB's will 
> definately help me
> along with this and help Struts quiet this EJB fud. I'm looking to get
> started on this soon, and anyone who wants to is more than welcome to
> help me out.
> 
>  - Mike
> 
> -----Original Message-----
> From: Bill G [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 5:04 PM
> To: [EMAIL PROTECTED]
> Subject: RE: java report article says "bye-bye struts"
> 
> 
> Hi Craig,
> 
> "Although excellent in dealing with Web-based applications, 
> Struts is not
> ready to take on EJB."
> 
> This is a concern of mine as well but as a newbie to this 
> technology, I am
> wondering how to adopt the Struts framework knowing that I 
> will move to
> EJB's. Is it worth starting with Struts with the idea of 
> moving to EJB's or
> what? Any info on this matter is seriously appreciated!
> 
> Thanks
> BG...
> 
> 
> 
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 11:14 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: java report article says "bye-bye struts"
> 
> 
> 
> 
> On Mon, 18 Jun 2001, Ritter, Steve wrote:
> 
> > Hi Hal, yeah I read the same article and couldn't help but laugh.
> > Prashant really made some outlandish comments and hopefully those
> > comments will diminish any negative impact his article might have on
> > Struts (or, the adoption of Struts I should say).
> >
> > Craig, if you read this thread it might not be a bad idea to send a
> > quick email to the editor's of Java Report and let them know about
> > some of the mis-leading statements.  Sounds like their review board
> > needs a little re-org.
> >
> 
> Looks like I'll have to go buy a copy -- I don't pay a lot of 
> attention to
> trade magazines in print, because production cycles make them 
> so far out
> of date.
> 
> Judging from the many thank-you's I've received for the 1.0 final
> release, I wouldn't worry to much about negative impact on Struts
> adoption.  :-)
> 
> > --Steve
> >
> 
> Craig
> 
> > > -----Original Message-----
> > > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 18, 2001 7:52 AM
> > > To: 'Struts List'
> > > Subject: java report article says "bye-bye struts"
> > >
> > >
> > > Clearly there are too many java magazines and they will
> > > publish anything. In
> > > the July issue of Java Report there is an article titled
> > > "Writing a Reusable
> > > Implementation of the MVC Design Pattern" by Prashant Sarode
> > > from Brience.
> > > It's interesting because it has a section title of "Bye-Bye
> > > Struts". The
> > > section starts out as follows:
> > >
> > > "While the Struts framework is a powerful idea, it is not yet
> > > a product.
> > > Although excellent in dealing with Web-based applications,
> > > Struts is not
> > > ready to take on EJB."
> > >
> > > There are other gems in the article but I won't reproduce
> > > them all here.
> > >
> > > The premise of the article is that the author went 
> looking for an MVC
> > > framework. He found the Blueprint document and liked that but
> > > it was too
> > > complicated. He then found Struts but apparently it didn't
> > > meet his need for
> > > "a reusable implementation of the MVC pattern." Prashant must
> > > be a hard man
> > > to please. I think he wants one framework that can be used
> > > for both web
> > > applications and desktop applications. Personally I would
> > > rather share the
> > > model components and let my MVC framworks be a little less
> > > abstract and more
> > > useful to the task at hand.
> > >
> > > I couldn't find the article on-line. I just skimmed the rest
> > > of the article
> > > because it it was hard to concentrate or take it seriously
> > > after the Bye-Bye
> > > Struts section.
> > >
> > > Hal
> > >
> >
> 

Reply via email to