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 19:13:38 GMT
Frank Zammetti wrote:

> Don, I'd be lieing if I said I understood all of what you said.  If 
> I'm getting it at all though, I think the basic point, correct me if 
> I'm wrong, is that since one of the limitations of my package is that 
> the incoming request has to be "flat" in form, you are suggesting a 
> way to allow for translation of a more complex XML form into a flat 
> one that can then be parsed for parameters, is that correct?

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.

> On the output side, I think your saying allow for much the same thing, 
> all in a plugable fashion... but I think I do already allow for that 
> which the release of .02 by allowing for mapping to a JSP that knows 
> the specifics of a given ActionForm and can therefore render a more 
> complex response if need be.  Are you suggesting a more elegant way to 
> do basically that?

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.

> I'm not familiar with much of the technologies you names, XPath I 
> think is the only one I know something about, so I'd have a lot of 
> learning to do before I could implement your suggestions (which is not 
> at all a bad thing!).
>
> I am going to look at the struts-chain this weekend though since a 
> number of people have made the same suggestion.  It doesn't sound like 
> a huge change on the surface, so it seems like a good next task to 
> tackle to me.  One question: that facility is not avalable in 1.1, 
> correct?  Is it slated for 1.2 (I thought I saw someone else say 
> 1.3?).  I'm a little bid weary of changing this to something that will 
> reduce how many people could possibly use it, but if it's not a major 
> change like I suspect then supporting both probably isn't a problem 
> either.

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.

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.

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


Mime
View raw message