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:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 12:41 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
