struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zammetti" <>
Subject RE: Struts Web Services Enablement Project
Date Fri, 04 Jun 2004 19:45:35 GMT

>In most cases, you would only be transforming against incoming documents 
>you expected
>from different clients, as opposed to an open ended set of formats. It's 
>just the flexibility
>to be *able* to transform that I think is key.  You might have rules that 
>sniff the incoming
>document for it's type, and the invoke a registered transformation against 
>it to an internal
>format you understood, or perhaps just let it pass if you recognize the 

Well, I think the short answer is that if it's relatively easy to do (and it 
sounds like it might be), I have no objection.

However, since any incoming message will be decomposed into a query string, 
the transformation always in essence has to result in a flat structure.  
Even if I add the capability of adding multiple element, i.e., a 
multi-select drop-down form element which in our XML message would look 
something like:

</items> this really feasible do you think?  I mean, if the incoming request is 
complex enough that you need to transform it, will it be simple enough that 
a transformation to the required format will be possible without information 
loss?  I have to add the ability to handle the above XML form first, which 
is already on my to-do list, but even with that in place, would you still 
say the transformation capability will be of value?

I guess the bottom line is that, if I understand it, once I switch to the 
ChainRequestProcessor, I can always drop the transformation step in later 
with no problem, so in that regard it's certainly not something I have to 
worry about now, just trying to prioritize is all.


>-----Original Message-----
>From: Frank Zammetti []
>Sent: Friday, June 04, 2004 3:31 PM
>Subject: Re: Struts Web Services Enablement Project
> >Yes, as already confirmed.  One area where web services are used is
> >standardizing how multiple applications can retrieve the same type of 
> >from different servers.  For example, if you have multiple servers that
> >produce gridded weather data, all the data producers could get together 
> >define a common XML schema for requesting data from their servers that 
> >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 
> >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 
>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 
>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 
> >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 
>   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 
>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 
> >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 
> >great addition to the toolbox available to Struts developers.
>Thank you, I'm very glad to hear the positive feedback I've gotten, and 
>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 
>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 <>
> >>>Reply-To: "Struts Developers List" <>
> >>>To: Struts Developers List <>
> >>>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 
> >>>in the Struts layer so putting the web service interface in front of 
> >>>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 
> >>>gets interpreted for parameters, and after the response is created.  
> >>>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 
> >>>include XPath paths as parameter names.  This way, using something like
> >>>JXPath, a complex XML element could be automatically created, to be 
> >>>transformed by the pipeline.  Send the resulting XML to the action via 
> >>>wrapper action form or even just put it in the request.  Better yet, 
> >>>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.  
> >>>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 
> >>>>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 []
> >>>>>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
> >>>>>EJB, or TopLink beans as Web Services but that's up in the model

> >>>>>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

> >>>>>>at contributing to an Apache project.  I hope I'm going about
> >>>>>>properly! :)
> >>>>>>
> >>>>>>In short, I have a little project going with the stated goal
> >>>>>>allowing a Struts developer to expose any existing business logic,

> >>>>>>implemented in Struts Actions and their subordinate helper classes,

> >>>>>>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
> >>>>>>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
> >>>>>>even now it's in a useful form.
> >>>>>>
> >>>>>>My hope is that eventually it will be good enough to be included
> >>>>>>the base Struts distro, but that's obviously a long way off,
> >>>>>>
> >>>>>>With all that in mind, please at your convenience visit
> >>>>>>
> >>>>>>
> >>>>>>There you will find some more detailed technical information
and a
> >>>>>>download which contains everything you need, including a simple

> >>>>>>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
> >>>>>>MSN House & Home.
> >>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail:
> >>>>>>For additional commands, e-mail:
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail:
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail:
> >>>>>For additional commands, e-mail:
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail:
> >>>>For additional commands, e-mail:
> >>>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail:
> >>>For additional commands, e-mail:
> >>>
> >>
> >>_________________________________________________________________
> >>Check out the coupons and bargains on MSN Offers!
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> >>For additional commands, e-mail:
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >
>Watch the online reality show Mixed Messages with a friend and enter to win
>a trip to NY
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Watch the online reality show Mixed Messages with a friend and enter to win 
a trip to NY

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message