struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zammetti" <fzamm...@hotmail.com>
Subject RE: Struts Web Services Enablement Project
Date Fri, 04 Jun 2004 18:07:00 GMT
>What it sounds like you've done is put business logic in your actions, when
>actions should simple call interactions between business delegates or
>business facades. (See Sun's J2EE Patterns).

In fact my applications follow this pattern quite well, except in a few 
limited circumstances where breaking the rules made more sense at the time.  
You certainly won't get any argument from me that this is the correct 
approach in any case, regardless of what I may have done wrong in the past 
:)

>By mingling business logic in your actions, you've forever committed your
>development within the Struts framework-- hence your probable need to now
>expose your work via web services.

Well, I guess I agree and disagree here a little bit.. I agree with your 
point in theory, but I can tell you tha in practice from a recent experience 
that it doesn't really tie you to any given framework.  A recent task I just 
completed was conversion of an existing application that was based on a 
homegrown framework to Struts.  It wasn't as big a nightmare as I, and I 
think you based on your comments here, would have thought.  The application 
wasn't terribly architected, but there was a good amount of business logic 
in controller components.  Even still, it took less than a week of not 
terribly intense work to convert it.

Don't get me wrong... I'm NOT saying people shouldn't follow the pattern you 
referenced, they absolutely SHOULD.  But to say not doing so ties you to 
Struts, or any framework, forever, that statement I think is a little bit 
overstated.

>The action code should be only a few lines if done correctly, simply acting
>as an adapter to some business provider.  That would leave the code in your
>action to simply pull data from ActionForms, or validate flows.

I agree whole-heartedly, and my applications are in fact 99% adherent to 
that design goal.  Not everyone's are though, whether they should be or not 
is less of a point in my mind because frankly there are external forces 
pushing you to get things done, and sometimes properly architecting a 
solution is less important than simply getting it done.  I certainly do my 
best to avoid it, but I'd bet a lot of people could chime in here with 
anecdotal evidence that when a business pressure says get an application 
done by such and such a date, and it will take less time to throw business 
logic in an Action than not, people will do so without hesitation.

Worse things are done in application development than this in the name of 
getting projects done on time :)  I don't think ignoring this fact by saying 
"well, you shouldn't have done that in the first place" is a realistic 
answer (although one I'd love to say myself many times!).

But this is really a philosophical debate about architecture, and we more or 
less entirely agree anyway! :)  In terms of my little project, I don't think 
it even matters.  Read on...

>If you want to do Web Services, have the services talk to your business
>providers, the same ones your actions would talk to.

This is where we diverge a bit.  While I agree in principal that a Web 
Service should be getting at the business providers as you say, my premise 
is that whether you have a completely well-designed application or a poorly 
designed one with busines logic in Actions, if you have to quickly expose 
business logic as a service, and do so without changing a lot of code, and 
it's a relatively simple request, then going through the Actions has some 
benefits in my mind.  Namely, Struts can still handle validation for you, 
you can make use of whatever security you might have built-in, and you 
already have most of what you need present on the server, no need to add a 
bunch of packages, config files and the like.  I've kept what you have to do 
to a minimum (in fact, as little as two entries in struts-config.xml and one 
JSP added can be enough), no code has to be touched.

I know I've said this before, but I think it's an important point to drive 
home: I personally do not, and never have, seen this as an all-encompassing 
Web Service layer in Struts (although humorously the name I choose probably 
does give that impression!).  I view this as a simple way to get business 
logic exposed as services quickly, without a great deal of additional work, 
and it might even be MORE useful in situations where an application is 
poorly-designed ironically!  I think if you plan on exposing large parts of 
your business logic as services, or certainly if your not deailng with 
existing code in the first place, then there are already far better choices 
out there.  But if you are in a situation where you have to expose a small 
piece of logic for someone in quick order, and it exists already in a 
Struts-based application, then I believe this can be just the ticket.

Frank

>Jacob Hookom
>
>-----Original Message-----
>From: Michael Rasmussen [mailto:rasmusmc1@hotmail.com]
>Sent: Friday, June 04, 2004 12:41 PM
>To: dev@struts.apache.org
>Subject: Re: Struts Web Services Enablement Project
>
> >Frank forgive me here, but playing Devils Advocate, if you have clean MVC
> >separation then surely the last thing you want to do is to expose Actions
> >as Web Services.
> >It is reasonable to want to expose Business Service Providers such as 
>EJB,
> >or TopLink beans as Web Services but that's up in the model layer, what's
> >the point in pushing the access point down into the Controller code?
> >
>
>I guess I see this another way.  Business logic should be just that,
>business logic.  Shouldn't a web service just provide another view of your
>business logic.  And as another view shouldn't it be relying on your
>controller to provide the manipulation of the logic to get to its view?
>
>isn't this exactly the right place to put this kind of thing?
>
> >Or do you see here a solution for all those folks who've not followed 
>best
> >practice and have intermingled Controller functionality with Business
> >logic..?
> >
>
>
>Aren't you just intermingling the view with the model if you expose your
>logic?
>
>
>Just playing devils advocate of course. ;-)
>
> >Regards
> >
> >Duncan Mills
> >Senior Principal Product Manager
> >Oracle Application Development Tools
> >
> >
> >
> >Frank Zammetti wrote:
> >
> >>Hello devs!  This is my first time posting here, and my first attempt at
> >>contributing to an Apache project.  I hope I'm going about it properly! 
>:)
> >>
> >>In short, I have a little project going with the stated goal of allowing 
>a
>
> >>Struts developer to expose any existing business logic, as implemented 
>in
> >>Struts Actions and their subordinate helper classes, as Web Services, 
>and
> >>do this with NO changes required to any existing application code, and 
>as
> >>little change to Struts itself as possible.  Simplicity is the key to
> >>this!
> >>
> >>Today I released a second version of this project to the user's mailing
> >>list, and after some feedback I think it's at a point where I'd like to
> >>make you all aware of it, and get some higher-level feedback.  It's
> >>certainly far from complete at this point, but I think even now it's in 
>a
> >>useful form.
> >>
> >>My hope is that eventually it will be good enough to be included in the
> >>base Struts distro, but that's obviously a long way off, if ever.
> >>
> >>With all that in mind, please at your convenience visit
> >>http://www.omnytex.com/strutsws
> >>
> >>There you will find some more detailed technical information and a
> >>download which contains everything you need, including a simple sample
> >>webapp demonstrating the whole mess.
> >>
> >>I thank you in advance for any time you spend on this!
> >>
> >>Frank W. Zammetti
> >>
> >>_________________________________________________________________
> >>Looking to buy a house? Get informed with the Home Buying Guide from MSN
> >>House & Home. http://coldwellbanker.msn.com/
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now!
>http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar  get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message