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 13:55:23 GMT
I think your completely right, if you've written an application "correctly" 
then absolutely it's the classes that your Actions call upon that should 
really be exposed.  No argument there at all.

However, as you say, many people don't follow that model completely (for 
whatever reason, probably just because it's easier and quicker to break that 
separation during a project's development), so in that regard, yes, I think 
it could possibly get people in that boat up and running with Web Services 
faster.

But whether you did a good job architecturally or not, I think this still 
may give you an easy path to exposing things as services without changing 
any code.  I know there are tools out there for exposing EJBs and such as 
services, and non-EJB classes to, Axis comes to mind, but I think for all 
such solutions there is either (a) code changes that have to be done to make 
it work, or (b) a higher learning curve to deal with.

For instance, I know a guy here that wrote an EJB and then wanted to expose 
it as a service.  He went with Axis to do it.  If I recall correctly, he 
didn't really have to change any code, but it still took him something like 
two weeks to get ti working.  Maybe it was just him being dense, but my read 
on it at the time was that it was just more difficult than it could have 
been.

I think if you have a Struts-based application, you already have a large 
portion of the infrastructure available to expose it as a service (assuming 
SOAP over HTTP, which I think it's fair to say is how the vast majority of 
Web Services are served).  You have the server obviously, you have something 
that understands the underlying protocol, you have the code set up to handle 
incoming requests, etc.  In my mind, this is just strapping a very small 
piece onto the side of that infrastructure and your all set.

So, with a solution like this I think you can get at least rudimentary 
services up and running, based on existing Struts-based applications, with 
little difficulty.  There are certainly limitations, and certailnly it 
wouldn't be suited for every purpose, but for the simpler situations I think 
it may be a good option.  I never thought I was working on an 
all-encompassing solution anyway, I didn't expect everyone to jump on this 
like it was the greatest thing.  I only expect it to be of limited use 
(although hopefully less limited as time goes on and it develops a bit).

But your point is valid certainly, and for a properly architected 
application, this may in fact ironically be less useful than for an 
application that maybe isn't architected as well :)

Frank


>From: Duncan Mills <duncan.mills@oracle.com>
>Reply-To: "Struts Developers List" <dev@struts.apache.org>
>To: Struts Developers List <dev@struts.apache.org>
>Subject: Re: Struts Web Services Enablement Project
>Date: Fri, 04 Jun 2004 08:38:09 +0100
>
>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?
>
>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..?
>
>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
>

_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win 
a trip to NY 
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/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