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

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>
<item>1</item>
<item>2</item>
</items>

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

Frank

>-----Original Message-----
>From: Frank Zammetti [mailto:fzammett@hotmail.com]
>Sent: Friday, June 04, 2004 3:31 PM
>To: dev@struts.apache.org
>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 
>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
>

_________________________________________________________________
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