struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: Struts Web Services Enablement Project
Date Fri, 04 Jun 2004 20:19:26 GMT
While I understand your personal goal of simply making Struts actions 
available through SOAP, I think you touch on a much larger issue of how 
to write applications that have robust HTML and SOAP interfaces with the 
least amount of effort.  Yes, one could write a Struts webapp and an 
Axis interface, both talking to a business facade layer, but why 
couldn't, for most cases anyways, the Java code be the same?

In my mind, in addition to pulling data from the business layer, the 
Struts layer performs four tasks - authorization, gathering input, 
validation, returning information.  If you wrote a separate Axis layer, 
you'd have to address these four issues.    In both cases, both 
programmatic and declarative authorization needs to be determined before 
and during request processing.  In the first case, the input gathering 
mechanism is HTTP POST or GET, the latter an XML document (assuming 
document-style SOAP).  While the input gather function is unique to each 
method, the result should be the same - a model representation usually a 
POJO.  A common intermediate format like a dynabean or XML document 
could be used before the final model creation to perform validation.  
Finally, the data to return has to be retrieved and declared in some 
fashion.

I think there is a great opportunity for Struts to tackle this problem 
in a way no other project that I know of, save perhaps Cocoon, has 
attempted.  To provide the capability to take web applications and 
easily transform them into robust services would be a godsend to 
developers, like me, tasked with integrating web apps into the 
enterprise service-oriented architecture.  As Struts defers the view 
processing to more capable frameworks like JSF, this goal fits right in 
with making Struts a more capable controller.

So yes, for the stated purpose of automatically exposing a web service 
interface for existing Struts apps, my suggestions wouldn't be 
relevant.  To take it a step further and make web services a first-class 
citizen in Struts, the capability needs to be there.

Don

Frank Zammetti wrote:

>> Yes, as already confirmed.  One area where web services are used is 
>> standardizing how multiple applications can retrieve the same type of 
>> data from different servers.  For example, if you have multiple 
>> servers that produce gridded weather data, all the data producers 
>> could get together and define a common XML schema for requesting data 
>> from their servers that they all implement.  This way, clients can 
>> use different data providers interchangably.  This XML schema 
>> standardization is a very fluid process that can be subject to many 
>> changes.  It is easiest if your application is as isolated as 
>> possible from the actual XML schema.
>
>
> Gotcha.  This is clear in my mind now.  The only concern I might have, 
> and believe me I know how weird this going to sound, is that this 
> might make it TOO flexible!
>
> What I mean is, I think there are products already out there better 
> suited to deal with more complex service requests, and with regard to 
> other discussion points in this thread, if your to a point where you 
> are exposing more complex things, as in your weather example, I'd be 
> willing to bet you probably wouldn't consider doing it with this 
> anyway, regardless of whether I added the transofmration capabilities 
> or not.  You would probably be talking directly to your real business 
> objects and not wanting to go through the Actions, and then there are 
> far better ways to do things than this.
>
> I'm certainly not ruling out what your saying, your've definitely 
> convinced me of the benefit it would bring, but I do see it as 
> something for down the road because I get the feeling it really morphs 
> what I'm doing into a much grander plan.  I certainly dion't mind 
> grand plans, and don't mind working to make those plans a reality, but 
> I'm not as convinced that it fits in with the simple model I started 
> with, and so it might be an addition after the more basic model is 
> solidified.
>
>> The problem with just using a JSP is you need to write a JSP for each 
>> action.  If you use auto-generated XML, you can define a smaller 
>> number of XSL stylesheets to match common XML elements for 
>> transformation.  Furthermore, the pipeline approach allows you to 
>> break up the transformation process to support transformation stages 
>> that may involve more complex processing.
>
>
> Actually, as it stands now you would only have to write a JSP for any 
> responses that can't be described by the default JSP.  It's hard to 
> say how many situations would really require a custom JSP, but my gut 
> tells me that it's probably no better than 50/50 in favor of creating 
> a new JSP.  My bet is that half the time, and maybe even more, the 
> default template will suffice, probably with the member list attribute 
> in use more times than not.  Granted, if your response has to work 
> within the confines of a defined schema as in your weather example, 
> then your talking a new JSP, and then that becomes a burden most 
> likely.  But again, it your doing something like that, I suspect you'd 
> have decided against my little package already!
>
> Again I think this is somethng that I can see where the benefit comes 
> in, but probably baloons the complexity again.  I can concieve of this 
> project expanding as time goes on to more "compete" with the more 
> developed packages out there now, but I feel like that's a much more 
> long-term goal than what I'm trying to accomplish now.
>
>> While struts-chain won't be incorporated into Struts until probably 
>> 1.3 (but could be somewhere in 1.2), it is still available to be used 
>> with Struts 1.1.  Since you are requiring a custom request processor 
>> anyways, just use the struts-chain request processor and refactor 
>> your capabilities into multiple commands instead of extended 
>> RequestProcessor methods.  The burden on your users will be about the 
>> same and the transition to future Struts will simply require you to 
>> discontinue the specific use of the chain's legacy RequestProcessor.  
>> Your function code will already be in commands that are already 
>> compliant.
>
>
> That sounds good, I will definitely look into doing it this weekend.  
> Your comments above alay whatever fears I might have had, it sounds 
> like the right thing to do overall, and not a massive change either.
>
>> Good job with what you've put together so far.  I think this 
>> extension is a great addition to the toolbox available to Struts 
>> developers.
>
>
> Thank you, I'm very glad to hear the positive feedback I've gotten, 
> and just as happy that people are interested enough to at least make 
> suggestions and question what I'm doing.  Any comments, regardless of 
> what side of the fence they are on or if/when I act on things is 
> valuable.  I was concerned that I was the only one that thought this 
> might be something useful, but it sounds like I'm not alone, and that 
> certainly motivates me to develop it further.
>
>> Don
>>
>>>
>>> Thanks!
>>>
>>> Frank
>>>
>>>> From: Don Brown <mrdon@twdata.org>
>>>> 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 12:14:16 -0400
>>>>
>>>> I think there can be considerable benefit from exposing Struts 
>>>> Actions.  For one, how Struts is currently architected, all the 
>>>> validation happens in the Struts layer so putting the web service 
>>>> interface in front of that makes sense.  Two, many times user 
>>>> authorization occurs in the Actions and so if this code hooked into 
>>>> the Servlets API, authorization is automatically taken care of.
>>>>
>>>> I'd recommend two feature additions to make this useable for 
>>>> document style SOAP messaging:
>>>>
>>>> 1) Put a configurable XML transformation pipeline before the SOAP 
>>>> message gets interpreted for parameters, and after the response is 
>>>> created.  The pipeline for the response should start with 
>>>> auto-generated request XML (via something like XStream).
>>>>
>>>> 2) Improve the request parameter schema for the incoming XML 
>>>> document to include XPath paths as parameter names.  This way, 
>>>> using something like JXPath, a complex XML element could be 
>>>> automatically created, to be then transformed by the pipeline.  
>>>> Send the resulting XML to the action via a wrapper action form or 
>>>> even just put it in the request.  Better yet, have the resulting 
>>>> XML be processed by an XML binding framework like XStream to create 
>>>> arbitrary Java objects to be passed to the action.
>>>>
>>>> The key is to enable any XML schema to be used as input and 
>>>> output.  The XML pipeline further isolates you from schema changes.
>>>>
>>>> Finally, I'd also recommend looking at using struts-chain rather 
>>>> than a RequestProcessor.  If the above functionality was decomposed 
>>>> into different Commands, one could easily plug in, say, a different 
>>>> XML binding framework or get rid of the XPath processor altogether.
>>>>
>>>> Don
>>>>
>>>> Duncan Mills wrote:
>>>>
>>>>> Didn't mean to be harsh - I was just presenting the alternative 
>>>>> viewpoint that has to be answered.  Personally I can see the 
>>>>> benefit that this project could offer, but the counter stance is a 
>>>>> one to raise is it not?
>>>>>
>>>>> Regards
>>>>>
>>>>> Duncan Mills
>>>>> Senior Principal Product Manager
>>>>> Oracle Application Development Tools
>>>>>
>>>>>
>>>>> Jung, Eric wrote:
>>>>>
>>>>>> Wow, that's kind of harsh, Duncan.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Duncan Mills [mailto:duncan.mills@oracle.com]
>>>>>> Sent: Friday, June 04, 2004 3:38 AM
>>>>>> To: Struts Developers List
>>>>>> 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?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------

>>>>>>
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>> _________________________________________________________________
>>> Check out the coupons and bargains on MSN Offers! 
>>> http://youroffers.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
>


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


Mime
View raw message