I think the one underlying point that is coming through is that there seems to be a desire, maybe even a need, for a "real" Web Service capability built in to Struts. There's been a lot of different ideas about what form it should take, what capabilities are important, and how it should ultimately be implemented. If for no other reason, I think bringing that point to light (if it wasn't already!) was a good result of my little project.
But, when I examine where I am now, how I've personally chosen to do things, and I ask the question of whether I think it could really be the basis for a grander vision, I think I lean towards the answer being no. I think I've put forth a couple of decent ideas, maybe shown people a way to do things that is if not original than maybe not a common method, but I don't for a second think it's the be-all and end-all of Web Services in Struts, and I suspect it probably never could be.
So, in the short-term, my little package can probably be useful to some folks, and that's cool. Over a relatively short period of time I can probably expand it and polish it so it's useful to even more people, and maybe even be useful enough and polished enough to be included in the Struts distro at some point. But to turn into a whole generally useful to everyone Web Service component of Struts? My gut says no, so I'm a bit hesitant to start down that road, especially considering how much I frankly have to learn myself to go down that road.
What I do wonder though is if we're coming to a point where maybe we can get some people together and start a Struts sub-project (or whatever the proper terminology would be) to really do something more capable? I don't think I can pull off something like that alone, not short-term anyway, but I'd certainly be interested in being a part of such an effort. So, does anyone else see that as a viable thing to do, and if so, how do we go about actually doing it?
Frank
From: robert burrell donkin <[EMAIL PROTECTED]> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Subject: Re: Struts Web Services Enablement Project Date: Sun, 6 Jun 2004 08:54:26 +0100
On 4 Jun 2004, at 22:56, Frank Zammetti wrote:
<snip>
After that, I'm thinking that a .04 release maybe a week later seems reasonable, and with that my main goal is implementing the pre- and post-transformations suggested here. I haven't thought this through yet entirely, but what I think this amounts to is not much more than adding an xslt-in and xslt-out attributes to the mappings in webservices-config.xml that, if present will trigger processing of the incoming and outgoing XML via these transformations. The incoming side of things seems relatively straight-forward to me, but the outbound side I can't see as clearly right now because as it currently stands, a JSP renders the XML, so how can I run the resultant XML through an XSL transformation and return the result to the client? One possibility is a new class that would create the XML and THEN run it through the transformation. In addition to that, I would probably add an attribute to the <service> mappings that would specify whether a JSP is going to render the output, or it will be the result of a transformation. This is just rough thinking at the moment, at least as far as the outbound side goes.
1 if you want inspiration about pipelining, then take a look at cocoon: they've been successfully doing this kind of thing for years!
2 the problem with transformations is that (if you want to make them perform), the framework needs to be build with them in mind. typically, this means using something like a SAX pipeline.
3 using a SAX pipeline restricts the choice of object-xml binders that can be used. having a choice is object-xml binders is important.
4 IMHO the most elegant solution would be to replace the entire rendering layer (jsp's etc) with a configurable component-based object-xml lightweight binding framework. the actions take and produce objects which are then rendered to and from xml by the framework. any transformations should be done within this layer rather than without allowing different components to support them in different ways (or not at all).
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
