Re: DB Access from Struts
Jim, Nice docs. Matt - You can also have a look at the code example from the book (Core J2EE Patterns), available at: http://www.phptr.com/corej2eepatterns/codeChap8.html As for the overkill issue...yes, in some cases it is, but since it also helps address centralized access to the biz tier, exception translation (ie: network exceptions to application exceptions), synching or retries on invocations to biz tier if needed, managing caching, hiding impl details of biz service (ie: remote objects), encapsulating/hiding lookup of biz service (ie: ejbhome), it is a very valuable pattern to consider. Thanks, -dm "Cakalic, James" wrote: > Here are some example sequence diagrams I found that might be useful: > http://www.cayambe.org/docs/design/AddToCart.html > http://www.cayambe.org/docs/design/BrowseCatalog.html > http://www.cayambe.org/docs/design/ManageCart.html > http://www.cayambe.org/docs/design/ViewReceipt.html > > The use cases that these sequence diagrams design are here: > http://www.cayambe.org/docs/requirements/Use_Case.html > > I'll see what else I can dig up later. > > Jim > > > -Original Message- > > From: Matt Raible [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 26, 2002 1:58 PM > > To: Struts Users Mailing List > > Subject: RE: DB Access from Struts > > > > > > Any examples of a Business Delegate class out there - I'm > > thinking of using a > > similar pattern to the one below, rather than calling my > > DAO's directly from my > > action class. > > > > Is this just a regular class that calls the DAOs? I'm > > assuming so? Any ideas > > on naming? > > > > Also, has anyone implemented this pattern with the > > DispatchAction class in > > Struts? > > > > Thanks, > > > > Matt > > > > --- "Cakalic, James" <[EMAIL PROTECTED]> wrote: > > > It may seem like a long way around for some, but the > > pattern I have been > > > applying is to keep the ActionForm classes as presentation > > objects, have > > > "data model" classes that represent the fields in the database for > > > persistence, and between these, have value objects that > > represent the true > > > "object model" with which you want to operate. Mixing these > > three concepts > > > together is, IMO, what generally gets one into problems related to > > > incomplete separation between layers. > > > > > > As for responsibilities, I introduce a business delegate > > between the Action > > > and the persistence in which the actual "work" -- the use > > cases/user stories > > > implemented by your system -- is performed. The > > responsibility of the Action > > > is to translate between the presentation objects > > (ActionForms) and the value > > > objects used by the delegate. The value objects are > > representative of the > > > object model of your application. The persistence layer, > > implemented by EJBs > > > and/or DAOs, converts between the application object model > > represented by > > > the value objects and the persistence model represented by > > classes that are > > > closely related in structure to your database tables. > > > > > > As I said before, this may seem like overkill to some. And > > it might really > > > be overkill depending on your application and its > > requirements. But I think > > > that this pattern serves to keep the layers of your model decoupled > > > according to a logical separation of concerns. It > > represents, I think, a > > > focus on the business layer being the true heart of the > > system with the > > > presentation and persistence layers there to support it. > > And since the > > > persistence layer is encapsulated from the business and > > presentation layers, > > > you can choose to change out your persistence layer or > > mingle technologies > > > as you see fit. > > > > > > If you'd like to see more, you might visit the J2EE > > patterns catalog here: > > > > > http://developer.java.sun.com/developer/technicalArticles/J2EE > > /patterns/ > > > > > > This material has subsequently been refined and published > > in the Core J2EE > > > Patterns book: http://www.bookpool.com/.x/t4tyn2dfrn/sm/0130648841 > > > > > > Best regards, > > > Jim Cakalic > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, February 26, 2002 10:51 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: DB Access from Struts > > > > > > > > > > > > Hello, > > > > > > > > A general practices question about db access using standard > > > > java or EJB with struts. What is the best approach for > > > > pluging db access into the struts framework in each case? For > > > > example, if I'm using torque to generate all the DB access > > > > classes, should I still use the Form Bean classes or its > > > > better to simply have the torque classes extend the > > > > ActionForm interface? Or is it better to access the torque > > > > classes in the Action class? And what about EJB? > > > > > > > > Thanks, any help is much appreciated. > > > > > > >
Re: ejb design
Hi Ali,
You may be interested in the "Composite Entity" pattern in our book "Core J2EE
Patterns". It describes creating course-grained Entities that manage finer
grained dependent objects, which are not implemented as Entity beans, but rather
pojos (Plain Old Java Objects).
The book includes numerous other patterns that may be of interest to you if you
are using Struts in comibination with a distributed business tier, such as
EJB-based services.
Good luck,
Dan
Ali Ozoren wrote:
> hi all-
> i am pretty new at ejb and that might be a little off topic but here i go.
> instead of creating entity beans the conventional way, according to spec,
> would it be desirable to have one type of entity bean with a hashtable
> member to manipulate all the values and fields dynamically, accessing fields
> by their string names.
>
> class ValueObject
> {
> String name;
> Object value;
> }
>
> class BaseEntityBean
> {
> String id;
> Hashtable fields; //collection of ValueObjects, one row of data becomes
> "columncount" times ValueObjects.
>
> setField(String name, Object value);
> Object getField(String name);
> String getAsXML();
> BaseEntityBean findByPrimaryKey; //finds record, fills the "fields"
> variable using ResultSetMetaData
> }
>
> so for each different type of entity beans, we can inherit from
> BaseEntityBean, to create for instance AccountEntityBean that knows from
> which table it's going to get values.
>
> one obvious advantage is simplicity. one doesn't have to code setters and
> getters for all fields. another one would be addition of "custom" fields by
> the user later on. when he does that custom fields would be equal to what's
> already defined in the bean. hence no different way to handle custom fields.
>
> then again, obvious disadvantage is speed. instantiating the ValueObjects
> and filling the hashtable takes more time. also, we are no longer using the
> simple types for the sake of genericity which doesn't help the speed issue
> either.
>
> question is whether the benefits outweigh the speed disadvantage or not.
>
> also, is there anything against exposing a ResultSet type from an entity
> bean?
>
> i appreciate any input, thanks.
>
> --a
--
Dan MalksSun Java Center
Enterprise Java Architect703.208.5794
Re: is there example code for...
Tom, No offense taken. I just wasn't sure if you'd seen the refactoring section in the book, in addition to the earlier discussion in the design considerations section, since the example in that section specifically referenced the Struts code you asked for. Glad you found what you need :-) -dm Tom Tibbetts wrote: > Hi Dan. I appreciate your response and hope I didn't offend you. > > I read the sections in the 'Core J2EE Patterns' book that you mentioned and > looked at the code pulled from Struts. I understood the theory of what was > needed to be accomplished but really did not see a concrete example of how > to implement. I took my best shot and used, for my jsp page, something > resembling what is on page 80 only using . That was when I > started to get exceptions that I didn't have the proper getter method. It > wasn't until I combed the archives that I found the references back to > struts-example (which I'm embarrassed to say I've been all over but never > saw the token methods) and a review of the tag to realize that > the form tag looks at the request for usage of transaction token then > creates its own hidden field. Thanks again for your response and patience > with my confusion. Tom > > At 12:35 PM 8/7/01 -0400, you wrote: > >Hi Tom, > > > >Tom Tibbetts wrote: > > > > > Hi all. Is there example code about how to implement saveToken and > > > isValidToken methods. Core J2ee patterns gives a good talk on theory but > > > they drop the ball with examples. > > > >We cover the general theory of duplicate form submission issues and the > >synchronizer token in the "Presentation Tier Design Considerations" chapter > >of 'Core J2EE Patterns'. > > > >We also include an example with source code in the "Presentation Tier > >Refactorings" chapter. In fact the source code used with permission is from > >Struts itself, including the 'saveToken()' and 'isTokenValid()' methods. > > > >Hope this helps, > >Dan > > > > > Thanks in advance. Tom > > > >-- > >Dan MalksSun Java Center > >Enterprise Java Architect703.208.5794 -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: is there example code for...
Hi Tom, Tom Tibbetts wrote: > Hi all. Is there example code about how to implement saveToken and > isValidToken methods. Core J2ee patterns gives a good talk on theory but > they drop the ball with examples. We cover the general theory of duplicate form submission issues and the synchronizer token in the "Presentation Tier Design Considerations" chapter of 'Core J2EE Patterns'. We also include an example with source code in the "Presentation Tier Refactorings" chapter. In fact the source code used with permission is from Struts itself, including the 'saveToken()' and 'isTokenValid()' methods. Hope this helps, Dan > Thanks in advance. Tom -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Struts and Sun's J2EE Patterns
Ted, Sounds good. Let me know once you've started to incorporate the patterns and I'll have a look. Thanks, -dm Ted Husted wrote: > I've started a new piece about building a Strut's application from > scratch. I'm now thinking about how to work the J2EE patterns into what > I started. The work in progress is at > > < http://husted.com/about/struts > > > under Coming Soon. > > Any notes or ideas people might have about this would be appreciated. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel 716 737-3463. > -- http://www.husted.com/about/struts/ -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Struts and Sun's J2EE Patterns
Hi Craig, "Craig R. McClanahan" wrote: > On Fri, 16 Mar 2001, Dan Malks wrote: > [snip] > > In fact, I've gotten some emails recently asking me to write a paper about the > > relationship of an existing framework and the Patterns. Describing the synergy > > between Struts and the J2EE Patterns might be an interesting example of the > > decomposition of a specific framework into some of the component patterns from >which > > it is composed. Craig, any interest in working together on something like this? >(I'm > > too busy at the moment too, but maybe sometime in the not so distant future ;-) > > Anyway, not sure if this would be of interest to the community at large, but I >think > > it might be... > > > > Thanks, > > Dan > > > > I would be interested in working on something like this. The next three > weeks are totally impossible (I'm speaking at both O'Reilly Enterprise > Java Conference and ApacheCon, and have some "real work" to get done along > the way :-), but would have a little time to talk about this in April. > > > > > > > > > > > Thanks, > > > > Dan > > > > > > > > > > Craig April's come and gone and I've been too busy to even think about writing something, as I imagine you have been. At the same time, would you like to discuss an outline at some point, so we can consider doing this? Let me know what you think. Thanks, Dan > > > > > -- > > Dan MalksSun Java Center > > Enterprise Java Architect703.208.5794 > > > > > > > > Craig -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Bryan,
Bryan Field-Elliot wrote:
> Thank you Dan --
>
> As I emailed at around midnight last night, I have everything taken
> care of, using Jason Pringle's pattern. It's probably very similar to
> the Business Delegate pattern you describe (which I will read today).
This is why they call it a pattern, isn't it ;-)
Glad your problem is solved.
> Basically I implemented a handler class for the Stateful Session Bean,
> which contains a duplicate of all of the bean's remote interface
> methods. In it's constructor, I create a private instance of the
> "real" bean. And in all of the methods, I'm just passing through the
> parameters to the "real bean" and returning it's return values, to the
> client. In this case, the "client' is always a Struts Action or a
> custom JSP tag.
>
> All of these methods are wrapped in a simple "syncronized" statement
> to the bean instance:
>
> String businessMethod1(int param1, int param2) throws RemoteException
> {
>syncronized(theBean) { return theBean.businessMethod1(param1,
> param2); }
BTW, are you throwing this remote exception back into the presentation
tier framework code? If one goal of your handler class (ie: business
delegate) is to reduce coupling by proxying and hiding the
implementation details of EJB, then you should consider converting
system-level exceptions, such as RemoteException into
application-friendly exceptions b4 sending them back to the pres tier
framework code.
>
> }
>
> That wasn't so bad, really, and it solved my concurrency problem
> completely. For good measure I also implemented the "common business
> interface" pattern (or whatever it's properly called), in which I have
> a single interface defining my business methods, which is extended (or
> implemented) by the RemoteInterface, the Handler, and the actual Bean.
> This makes for tidier code but wasn't really germaine to my
> syncronization problem.
>
> Lastly, you say "if I have any suggestions, you'd love to hear them".
> Well here's a big suggestion -- an EJB container should, at the
> deployer's option, syncronize concurrent calls to Stateful Session
> Beans rather than simply reject outright the second one. As a
> developer (or deployer), I should be able to choose whether I want an
> exception, or blocking, in the case of Stateful bean concurrency.
> Either way, I believe EJB's design goals are met, which is to prevent
> concurrency. With that as an amendment to the spec (EJB 2.0), I
> wouldn't have to write these silly wrappers.
I'll pass this along to the appropriate folks.
Thanks,
Dan
>
>
> Thanks,
>
> Bryan
>
>
>
> Dan Malks wrote:
>
>> All,
>> Sorry to jump in late on this.
>> Am not monitoring this list real consistently at the moment, but it
>> was brought
>> to my attention that there were some business tier coupling and EJB
>> issues being
>> discussed, so I thought I'd make a few quick comments.
>>
>> Looking back over the thread, there is a mention of using a handler
>> class as
>> basically a client-side business abstraction, which I think makes
>> great sense.
>> It reduces the coupling between tiers and provides a nice place for
>> things like
>> remote lookups, caching, synchronization, exception type
>> translation, etc...
>>
>> About a month ago, we did a beta release of a set of J2EE patterns
>> (available
>> at:
>> http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
>> ),
>> which includes just such a pattern.!
>> ..it's called the Business Delegate pattern,
>> and describes these issues among others, so I thought some folks
>> might be
>> interested to check it out. There is a related Service Locator
>> pattern that
>> deals with hiding the impl details of remote lookups.
>>
>> The pattern descriptions have changed quite a bit even from the beta
>> release,
>> based on lots of quality feedback we've received from the community.
>> Updated
>> versions will be available soon, including lots of source code. If
>> you have
>> suggestions, we'd love to hear them. Also, there is a discussion
>> list for
>> related conversation
>> (http://archives.java.sun.com/archives/j2eepatterns-interest.html).
>> Hope this
>> proves useful to you.
>>
>> Thanks,
>> Dan
>>
>> "Hines, Bill" wrote:
>>
>>
>> > Brian,
>> >
>> > Disclaimer: I'm new to EJB and still trying to understand when to
>> > use
>&g
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
All, Sorry to jump in late on this. Am not monitoring this list real consistently at the moment, but it was brought to my attention that there were some business tier coupling and EJB issues being discussed, so I thought I'd make a few quick comments. Looking back over the thread, there is a mention of using a handler class as basically a client-side business abstraction, which I think makes great sense. It reduces the coupling between tiers and provides a nice place for things like remote lookups, caching, synchronization, exception type translation, etc... About a month ago, we did a beta release of a set of J2EE patterns (available at: http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/), which includes just such a pattern...it's called the Business Delegate pattern, and describes these issues among others, so I thought some folks might be interested to check it out. There is a related Service Locator pattern that deals with hiding the impl details of remote lookups. The pattern descriptions have changed quite a bit even from the beta release, based on lots of quality feedback we've received from the community. Updated versions will be available soon, including lots of source code. If you have suggestions, we'd love to hear them. Also, there is a discussion list for related conversation (http://archives.java.sun.com/archives/j2eepatterns-interest.html). Hope this proves useful to you. Thanks, Dan "Hines, Bill" wrote: > Brian, > > Disclaimer: I'm new to EJB and still trying to understand when to use > stateful/stateless session beans. > > Given that, I found your situation interesting. First I'll try to help you > if I can. There is an article in the February 2001 WebSphere Advisor by Tony > Higham, on page 10, titled "The Reality of EJB". It should be available on > their web site. He talks about problems like yours and recommends an > approach where you use stateless beans but an alternative state-handling > mechanism such as HttpSession to hold the user's data. Will that sort of > thing work for you? It sounds more light-weight than stashing the whole > session bean and/or accessor JavaBean with synchronized methods into the > session. There are also some good patterns for using session beans in the > IBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere > Application Server", which is available for download on the IBM Redbooks > site. You might find some ideas there. > > Now that I've tried to help, if you could, explain your aversion to > stateless and why they won't work for you in this situation, so that I can > learn more. > > Thanks, your questions and contributions here are very useful to me. > > Bill Hines > Sun Certified Java Programmer > Hershey Foods Corp > > -Original Message- > From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 05, 2001 11:09 AM > To: [EMAIL PROTECTED] > Subject: Frames, concurrency, and EJB Stateful Session beans - a > problem. > > I'm having a design problem with my system, which is not really Struts > specific, but since there are a lot of EJB users here, I thought I'd > throw it on this list for comments -- > > My business logic is all implemented in a Stateful EJB Session bean. All > Struts users get one instance of the session bean, whose reference is > stored in the Servlet's Session scope. > > All of my Struts actions are simple; they take data from the user > (usually in ActionForms), pass them to some method in the EJB Session > bean, and store the results in beans for the JSP page to render. > > However, my design calls for a few places where there is a frameset, and > in another place, where two browser windows open up showing two > different views. The problem here, is that EJB requires that a Stateful > Session bean have only one thread of execution within it (e.g. no > concurrency). So, when two different Struts actions (or custom tags) try > to invoke a method on the same EJB Session bean reference at the same > time, one of them will fail with an exception thrown by the EJB > container (in my case, jBoss). > > Can anyone recommend an easy, general-purpose solution to this problem? > (Please don't say, "switch to stateless session beans"). I suppose I > need to syncronize access to the EJB bean from the client (and, in this > case, the client is Struts), but I'm not sure how to do this quickly and > elegantly. > > Comments would be appreciated, > > Bryan -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
RE: Struts and Sun's J2EE Patterns
Phil, I'm an inconsistent reader of this list, so I'm not sure. >Are my postings not reaching the list? I'm sure I posted an informational on >this subject over a week ago! But thanks for doing so and we welcome your feedback. Pls feel free to email me directly or use the aliases provided with the patterns catalog to do so. I'd very much like to hear your impressions. Take care, Dan > >Philip Hart > >> -Original Message- >> From: Jorge Ribeiro Jordão [mailto:[EMAIL PROTECTED]] >> Sent: 14 March 2001 18:51 >> To: '[EMAIL PROTECTED]' >> Subject: Struts and Sun's J2EE Patterns >> >> >> Has anybody read Sun Java Center J2EE Patterns >> (http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/) >> yet ? >> >> For those that did, it seemed that Struts is pretty much an implementation >> of the "Front Controller" pattern (no surprises so far), using the >> "ServletFront", "Command and Controller", "Multiplexed Resource >> Mapping" and >> "Dispatcher in Controller" stategies. >> >> What do you think ? >> >> >> -- >> This message may contain confidential information or privileged material, >> and is intended only for the individual(s) named. If you are not in the >> named addressee you should not disseminate, distribute or copy >> this e-mail. >> Please notify the sender immediately by e-mail if you have received this >> e-mail by mistake and delete this e-mail from your system. >> E-mail transmission cannot be guaranteed to be secure or error-free as >> information could be intercepted, corrupted, lost, destroyed, >> arrive late or >> incomplete, or contain viruses. The sender therefore does not accept >> liability for any errors or omissions in the contents of this >> message which >> arise as a result of e-mail transmission. If verification is >> required please >> request a hard-copy version. >> > Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Struts and Sun's J2EE Patterns
Craig, "Craig R. McClanahan" wrote: > On Fri, 16 Mar 2001, Dan Malks wrote: > > > > > I understand and welcome your feedback once you've had a chance to have a look. > > > > Jorge's initial comment is interesting, given the fact that as Ralph Johnson, Doug > > Schmidt, and Mohamed Fayad state in 'Building Application Frameworks', Wiley 1999 > > "Patterns are the architectural elements of frameworks.". I agree with this > > sentiment, and it is good to see this relationship between the Struts Framework and > > the J2EE Patterns catalog. > > > > In fact, I've gotten some emails recently asking me to write a paper about the > > relationship of an existing framework and the Patterns. Describing the synergy > > between Struts and the J2EE Patterns might be an interesting example of the > > decomposition of a specific framework into some of the component patterns from >which > > it is composed. Craig, any interest in working together on something like this? >(I'm > > too busy at the moment too, but maybe sometime in the not so distant future ;-) > > Anyway, not sure if this would be of interest to the community at large, but I >think > > it might be... > > > > Thanks, > > Dan > > > > I would be interested in working on something like this. The next three > weeks are totally impossible (I'm speaking at both O'Reilly Enterprise > Java Conference and ApacheCon, and have some "real work" to get done along > the way :-), but would have a little time to talk about this in April. Understood. April is possible, but let's just see how the workload goes for each of us. Good luck with your presentations! Dan > > > > > > > > > > > > Thanks, > > > > Dan > > > > > > > > > > Craig > > > > -- > > Dan MalksSun Java Center > > Enterprise Java Architect703.208.5794 > > > > > > > > Craig -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Struts and Sun's J2EE Patterns
Craig,
"Craig R. McClanahan" wrote:
> Hi Dan, see intermixed ...
>
> On Fri, 16 Mar 2001, Dan Malks wrote:
>
> > Jorge,
> > Just catching up some email.
> >
> > Jorge Ribeiro Jordão wrote:
> >
> > > Has anybody read Sun Java Center J2EE Patterns
> > > (http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/)
> > > yet ?
> > >
> > > For those that did, it seemed that Struts is pretty much an implementation
> > > of the "Front Controller" pattern (no surprises so far), using the
> > > "ServletFront", "Command and Controller", "Multiplexed Resource Mapping" and
> > > "Dispatcher in Controller" stategies.
> >
> > You've done an excellent job of understanding this pattern and describing the
> > aspects of Struts it describes!
> >
> > The one minor clarification is about the 'Dispatcher in Controller' strategy.
> > While I'm not a Struts expert, I believe that Struts uses a separate mapping
> > mechanism that sits outside of the controller servlet, does it not?
> >
>
> Well, I hope that I qualify as a Struts expert :-)
>
> Struts relies on the servlet container's mapping rules to ensure that all
> interesting requests are mapped to the controller -- either by path
> mapping ("/execute/*") or by extension mapping ("*.do"). Then, it strips
> out the "*" part of the path to look up an internal that tells
> the controller what code to execute.
>
> > If the controller is delegating to an external component in order to do view
> > mgmt (ie:choosing the view) and navigation (ie:actually dispatching to that
> > view) then I probably wouldn't describe it as using the 'Dispatcher in
> > Controller' strategy. This strategy is meant to describe more simplistic cases
> > where the controller inlines the work itself, for example if it just grabs a
> > string and a requestDispatcher instance and forwards things on their way.
> >
>
> Interesting timing ... I just added exactly that feature over the last few
> days.
>
> When defining an , you know have three choices for how to specify
> what functional code gets executed:
> * "type" - The Java class name of an Action class (the original pattern)
> * "forward" - The context-relative path of a webapp resource to which
> control is directed via RequestDispatcher.forward().
> * "include" - The context-relative path of a webapp resource to which
> control is directed via RequestDispatcher.include().
Right. That indeed sounds like the 'Dispatcher in Controller' strategy.
>
>
> The latter two resulted from cases where I wanted to integrate some
> functionality that was already built on servlets, but take advantage of
> the controller's support for form beans. Now you can do this quite
> easily, without having to write a two-line Action that does it for you.
Makes sense.
>
>
> > See the 'solution' section of the 'Service to Worker' pattern for a bit more
> > discussion on this issue. 'Service to Worker' is a pattern that combines a
> > couple other "smaller" patterns in the catalog into a larger one.
> >
> > Let me know if I got anything wrong wrt to the discussion of Struts in this
> > email :-)
> > I'm interested in any other comments on this issue (or others related to any of
> > the Pattern material in the above URL - pls feel free to email the provided
> > aliases, if you'd like to discuss outside of this list).
> >
>
> I must confess I haven't had time to study the patterns docs in detail,
> but I will (I've got three sessions at ApacheCon in a couple of weeks, and
> am just finishing up the last one :-).
I understand and welcome your feedback once you've had a chance to have a look.
Jorge's initial comment is interesting, given the fact that as Ralph Johnson, Doug
Schmidt, and Mohamed Fayad state in 'Building Application Frameworks', Wiley 1999
"Patterns are the architectural elements of frameworks.". I agree with this
sentiment, and it is good to see this relationship between the Struts Framework and
the J2EE Patterns catalog.
In fact, I've gotten some emails recently asking me to write a paper about the
relationship of an existing framework and the Patterns. Describing the synergy
between Struts and the J2EE Patterns might be an interesting example of the
decomposition of a specific framework into some of the component patterns from which
it is composed. Craig, any interest in working together on something like this? (I'm
too busy at the moment too, but maybe sometime in the not so distant future ;-)
Anyway, not sure if this would be of interest to the community at large, but I think
it might be...
Thanks,
Dan
>
>
> > Thanks,
> > Dan
> >
>
> Craig
--
Dan MalksSun Java Center
Enterprise Java Architect703.208.5794
Re: Struts and Sun's J2EE Patterns
Jorge, Just catching up some email. Jorge Ribeiro Jordão wrote: > Has anybody read Sun Java Center J2EE Patterns > (http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/) > yet ? > > For those that did, it seemed that Struts is pretty much an implementation > of the "Front Controller" pattern (no surprises so far), using the > "ServletFront", "Command and Controller", "Multiplexed Resource Mapping" and > "Dispatcher in Controller" stategies. You've done an excellent job of understanding this pattern and describing the aspects of Struts it describes! The one minor clarification is about the 'Dispatcher in Controller' strategy. While I'm not a Struts expert, I believe that Struts uses a separate mapping mechanism that sits outside of the controller servlet, does it not? If the controller is delegating to an external component in order to do view mgmt (ie:choosing the view) and navigation (ie:actually dispatching to that view) then I probably wouldn't describe it as using the 'Dispatcher in Controller' strategy. This strategy is meant to describe more simplistic cases where the controller inlines the work itself, for example if it just grabs a string and a requestDispatcher instance and forwards things on their way. See the 'solution' section of the 'Service to Worker' pattern for a bit more discussion on this issue. 'Service to Worker' is a pattern that combines a couple other "smaller" patterns in the catalog into a larger one. Let me know if I got anything wrong wrt to the discussion of Struts in this email :-) I'm interested in any other comments on this issue (or others related to any of the Pattern material in the above URL - pls feel free to email the provided aliases, if you'd like to discuss outside of this list). Thanks, Dan > > > What do you think ? > > -- > This message may contain confidential information or privileged material, > and is intended only for the individual(s) named. If you are not in the > named addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive late or > incomplete, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message which > arise as a result of e-mail transmission. If verification is required please > request a hard-copy version. -- Dan MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Business Object Bean Persistence Strategies
Hi Mike, We just released a catalog of commonly used patterns and strategies to the developer community. We touch on this issue among others. ( For specific discussion of this issue have a look at the View Helper pattern. There is a sidebar titled Helpers about halfway down the page in the 'Solution' section that includes the following: So how does the Account object access the Business Services. Let us examine two cases, one simple and the other more sophisticated. In the more simple case, imagine that a project is taking a phased approach, phasing in EJB into the Business Tier over time. Assume at the moment that the database is being accessed via JDBC calls from the presentation tier. In this case, the Account object uses a Data Access Object (see Data Access Object pattern), hiding the underlying implementation details of accessing the database. The Data Access Object knows what SQL queries are necessary to retrieve the information. These details are hidden from the rest of the application, reducing coupling and making each component more modular and reusable. This case is described in the previous sequence diagram. When the architecture becomes more sophisticated, and EJB is introduced in the Business Tier, then the Data Access Object is replaced with a Business Delegate (see Business Delegate pattern), typically written by the developers of the Business Service. The Delegate hides the implementation details of EJB lookup, invocation, and exception handling from its client. It might also improve performance by providing caching services. Again, the object reduces coupling between tiers, improving the reusability and modularity of the various components. Regardless of the specific implementation of this object, its interface may remain unchanged during this transition. The following sequence diagram describes this scenario after the transition to the Business Delegate) The url is: http://developer.java.sun.com/developer/restricted/patterns/ViewHelper.html and requires JDC login. Any feedback or general comments, positive or negative, on the pattern catalog are much appreciated. Hope this helps. -dm Michael McCallister wrote: > What strategies or patterns do people use to manage persistence of business > object data in a Struts application when there is no EJB layer and there is > a desire to keep the business objects as independent of the web portion of > the application as possible? Do you use the Struts DataSource and pass > either it or a Connection as a parameter to bean methods that take > responsibility for managing persistence? Do you follow the J2EE blueprint > and create separate Data Access Objects to support persistence? Are you > using an open-source framework to manage persistence? This seems like a > common problem, but I haven't seen much talk about common solutions. > > Mike -- Dan Malks Sun Java Center Enterprise Java Architect703.208.5794
Re: [Q] TRANSACTION_TOKEN_KEY
"Craig R. McClanahan" wrote:
> Dan Malks wrote:
>
> > Craig,
> >
> > "Craig R. McClanahan" wrote:
> >
> > > Neal Kaiser wrote:
> > >
> > > > How does this work when they are registering for the first time, not
> > > > editing. I can
> > > > see that in EditRegistrationAction the token is set... but if they are
> > > > registering
> > > > for the first time where is the token set? It seems that it would fail when
> > > > it hits
> > > > the token check in SaveRegistrationAction, but I know it doesn't, so it must
> > > > be set
> > > > somewhere, right?
> > > >
> > >
> > > You will note that the "Register with the MailReader Demonstration Application"
> > > link (on index.jsp) goes through "EditRegistration.do" as well, so that the
> > > token gets saved even in this case. The "?action=Create" request parameter is
> > > used to distinguish this from the editing case ("?action=Edit").
> >
> > Would 'ModifyRegistration.do' or 'ProcessRegistration.do' be more clear, then?
> >
>
> Or even something more generic like "StartRegistration.do"? Can you tell that I
>wrote
> the "edit" use case first? :-)
>
> I had a Comp Sci prof that said the most critical design decision you will ever make
> is naming things.
And often, surprisingly, one of the harder ones.
> And, even when you get the initial name correct, it is important to
> review your names after the program has evolved a bit.
Amen ;-)
Thanks,
-dm
> Sounds like it is time to do
> that exercise on the example app.
>
> >
> > -dm
> >
>
> Craig
--
Dan Malks Sun Java Center
Enterprise Java Architect703.208.5794
Re: [Q] TRANSACTION_TOKEN_KEY
Craig,
"Craig R. McClanahan" wrote:
> Neal Kaiser wrote:
>
> > How does this work when they are registering for the first time, not
> > editing. I can
> > see that in EditRegistrationAction the token is set... but if they are
> > registering
> > for the first time where is the token set? It seems that it would fail when
> > it hits
> > the token check in SaveRegistrationAction, but I know it doesn't, so it must
> > be set
> > somewhere, right?
> >
>
> You will note that the "Register with the MailReader Demonstration Application"
> link (on index.jsp) goes through "EditRegistration.do" as well, so that the
> token gets saved even in this case. The "?action=Create" request parameter is
> used to distinguish this from the editing case ("?action=Edit").
Would 'ModifyRegistration.do' or 'ProcessRegistration.do' be more clear, then?
-dm
>
>
> This is a design pattern that I like a lot -- use the same Action to initialize
> the input form when you are creating a new record or when editing an existing
> one, and use a request parameter to define which type of transaction is
> occurring. You will also find that the "action" request parameter gets included
> as a property of the form bean, and is passed in (as a hidden variable) on the
> input form so that SaveRegistrationAction knows what to do as well.
>
> Craig
--
Dan Malks Sun Java Center
Enterprise Java Architect703.208.5794
