struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zammetti" <fzamm...@hotmail.com>
Subject RE: Strus Web Service Enablement
Date Fri, 04 Jun 2004 14:51:15 GMT
>   For what I understood you are customizing the RequestProcessor to handle
>SOAP message requests, right? I dont see Axis and any way of retrieving
>the WSDL to make a direct call...

That is correct.  Any by "handling SOAP message requests", it really means 
"look for the SOAPAction header, if it's there, parse the message and create 
a query string from it, then forward the request back to itself in essence, 
with the query string attached".  It's a very rudimentary facility to be 
sure.

>   If so, maybe instead of customizing the request processor, wouldn't it
>be best to have a "SOAPform" to process the envelope and then populate
>the bean? You could define the form-bean as your SOAPForm handler and a
>regular action-mapping.

Hmm... If I understand your suggestion correctly, that would require a new 
class for any Action you want to expose, correct?  That's something I wanted 
to avoid.  It's good in the sense that no code has to change (config files 
don't count in my mind, so that's OK to do), and while adding a whole new 
class isn't as bad in my mind, it's still something I'd prefer to avoid if 
possible.

>   With the help of Tiles one could define a template definition to return
>the response in the appropriate format.
>
>   Template:
>   - soap header
>   - soap body
>   - soap footer

I haven't looked a Tiles at all yet (I'm actually fairly new to Struts 
still), so I can't really make any intelligent comment on this (except, I 
hope, for the comment that I can't make an intelligent comment on it! :) )

>   How could one use your RequestProcessor if I am using Axis and
>publishing web services through WSDD or JWS files?

I can't answer that either because while I know a little about Axis (a very 
little), I don't know anything about WSDD or JWS.

>   I am new to web services but I found very usefull wsdl2java and have my
>clients process their requests in a somewhat transparent way through the
>use of SoapBindingStubs.
>   It seems that with your approach I can't call a web service with these
>stubs but, instead, need to implement some
>SOAPMessageBuilder+Marshalling/Unmarshalling of JavaBeans to send SOAP
>messages, something that with JWS files, for example, is completely
>transparent.

I *believe* these stubs will work, indeed they SHOULD.  One thing I'm going 
to try and do today is write a WSDL file for my sample service and see if 
the client that JDeveloper can generate from it works.  In theory it should, 
if it doesn't then obviously I've done something very wrong.  One of the 
limitations of my code is that only Strings can currently be passed as 
parameters to a service, and only Strings can be returned, so certainly much 
of the full power of Web Services cannot be utilizied (and I'm not sure I 
see any way to change that based on what I've done), so it's possibly always 
going to be of limited utility.  I don't expect that this is going to be 
useful for every Web Service situation, indeed it may only be useful in some 
limited subset.

In any case, you've given me some things to go Google now :)

Frank

>Pedro Salgado
>
>
> > Ah, I see.  I'm not familiar enough with filters, but I had always
> > thought  they were on the input side only.  If that belief is wrong,
> > then it  certainly becomes an option.
> >
> > I think at some point to make this really worth anything I'll have to
> > break  my "transparency rule" to some extent.  I do like the idea of
> > generating the  output with a JSP because it's just so easy!  A little
> > bit of background...  I actually implemented this same thing in a custom
> > framework we were  previously using in-house.  In that application I
> > actually do write out the  output in servlets, there is never a forward
> > to a JSP or anything else  typically in the "view" layer.
> >  This works
> > just fine, but when I started  doing it in Struts it ocurred to me that
> > I could really simplify things by  not taking that approach and instead
> > let the actual XML generation be done  in a JSP.  That also removed the
> > one change that was required under the old  framework: you did have to
> > add two function calls to the controller servlets  that were exposed as
> > services.  Not a big change, but I wanted to avoid code  changes
> > entirely here.
> >
> > At this point my belief is that probably the best way to handle this is
> > to  have an element added to the Action mappings in Struts-Config.xml
> > that  specifies the target JSP for a Web Service request.  The default
> > woudl be  the "generic" template I put together, although a bit more
> > flexible as time  goes on.  But, the point is that you could then define
> > an XML template in  essence for every Action you wanted to expose as a
> > service.  That would  allow for things I probably can't do
> > automatically.  I'd also write a taglib  to make life easier (although I
> > might not have to... the current Struts  taglibs might be more than
> > sufficient on their own).
> >
> > That would of course require a change to the DTD for Struts-Config.xml,
> > so  in the mean time what I think I'm going to do is add an optional
> > config file  thatwould be parsed via a plug-in at app startup that would
> > contain these  extra mappings.  Fairly trivial exercise, and it leaves
> > it completely  optional, no changes to Struts required.
> >
> > Also, I realized on the drive in that there's no need to put the
> > parameters  as a query string as I'm doing... I can just put the parsed
> > parameters  directly into the request object as an attribute.  Since
> > only the second  pass of a Web Service request would know or care about
> > that object, it will  basically just remove some code and simplify
> > things a bit.
> >
> > I'm hoping to get these thnigs done today and release a .02 package
> > before I  leave work today (it's nice when your development server is
> > down and you  can't do any real work until the techs rebuild it!)... I
> > also hope to remove  the required actionMappingPath element in the XML
> > request... I haven't found  a way to get at the requested pat
> > information in RequestProcessor yet, but  it seems like something that
> > should be available at that point, so I  probably just have to do some
> > digging.
> >
> > What is AOP by the way?  Millions of acronyms out there, I know
> > thousands of  them, but not that one :)
> >
> > Thanks very much for the feedback!
> >
> > Frank
> >
> >>From: "Marco Mistroni" <mmistroni@waersystems.com>
> >>Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
> >>To: "'Struts Users Mailing List'" <user@struts.apache.org>
> >>Subject: RE: Strus Web Service Enablement
> >>Date: Thu, 3 Jun 2004 14:25:47 +0100
> >>
> >>Hi,
> >>	Well, main issue here is that if you want everything to be
> >>transparent
> >>To the user (including the forward) then whole stuff has to be done so
> >> that
> >>Something 'intercepts' the response when XML is contained in it (if I
> >> can explain myself correctly)
> >>
> >>In other way, to do same steps that you have already done with
> >>RequestProcessor
> >>Not being familiar with struts internal (other than action &actionform)
> >> I can't really say where to modify things...
> >>
> >>Another way would be, for each CustomAction written, write an
> >>CustomActionXml that extends CustomAction. This CustomActionXml will Be
> >> invoked whenever the path is for CustomAction AND the request is in
> >> XML. The logic will be done in the original CustomAction, difference
> >> being in the fact that CustomActionXml instead of redirecting to the
> >> 'original' forward of CustomAction, writes the response to outputWriter
> >> But this gets cumbersome..
> >>
> >>I would go for doing with response exactly what u r doing with
> >> request.. Though right now I have no clue on how to do it...maybe u or
> >> some struts expert which knows inner logic of struts knows?
> >>
> >>Will AOP help in any way here?
> >>
> >>
> >>Regards
> >>	marco
> >>
> >>
> >>
> >>
> >>Extends
> >>
> >>-----Original Message-----
> >>From: Frank Zammetti [mailto:fzammett@hotmail.com]
> >>Sent: 03 June 2004 13:33
> >>To: user@struts.apache.org
> >>Subject: RE: Strus Web Service Enablement
> >>
> >>I have to be honest and say I've never used a filter except for one
> >> situation to do security on the input side, a very basic application.
> >> How
> >>would you envision it being used for the output?
> >>
> >>
> >> >From: "Marco Mistroni" <mmistroni@waersystems.com>
> >> >Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
> >> >To: "'Struts Users Mailing List'" <user@struts.apache.org>
> >> >Subject: RE: Strus Web Service Enablement
> >> >Date: Thu, 3 Jun 2004 10:15:43 +0100
> >> >
> >> >Hi,
> >> >	My 2 cents.... I think that is a great idea!!!!
> >> >
> >> >Do u think that using a filter for the response will help?
> >> >
> >> >Last year I did something similar (wrote a Struts-based webapp
> >> >That I was talking to using J2ME and KSOAP..but all I was able
> >> >To do was to extend existing action and dump the generated XML
> >> >Into the response.getWriter().write()... I was using axis btw for XML
> >> stuff on the serverside)
> >> >
> >> >Regards
> >> >	marco
> >> >
> >> >
> >> >
> >> >-----Original Message-----
> >> >From: Frank Zammetti [mailto:fzammett@hotmail.com]
> >> >Sent: 02 June 2004 21:29
> >> >To: user@struts.apache.org
> >> >Subject: RFC: Strus Web Service Enablement
> >> >
> >> >Hello all... I wanted to post this here and get any comments that
> >>people
> >> >had
> >> >so I could decide where to go with it...
> >> >
> >> >For the past two days I've been working on a mechanism that would
> >> allow you
> >> >to expose existing Struts-based business logic as Web Services
> >> without changing any existing code.  What I offer here is a first
> >> approximation of
> >> >that idea.
> >> >
> >> >If you might be interested in this, you can download the first
> >>iteration
> >> >of
> >> >the project at http://www.omnytex.com/wst.zip
> >> >
> >> >This archive is a sample webapp in exploded format.  Just unzip it to
> >> your
> >> >webapps directory of your chosen app server and you should be good to
> >> go.
> >> >I've only tried it on Tomcat however, so anything else is unknown.
> >> >
> >> >In a nutshell, what I've done is written a custom subclass of
> >> >RequestProcessor.  This version will recognize a SOAP-based Web
> >> Service request, "unroll" the request, and hand it off to a specified
> >> Action. As
> >> >far as the Action is concerned, it looks just like a regular HTTP
> >> form submission, so it processes same as before.  Note that the
> >> request is forwarded back through ActionServlet, so anything you do
> >> should still work.
> >> >The RequestProcessor then overrides the destination ActionForward
> >> that the
> >> >Action returns, and instead sends it to a special JSP, which renders
> >>the
> >> >
> >> >response XML.  The response type is set properly, and the generated
> >> XML is
> >> >returned.  The XML it generates simply dumps all members of the
> >> ActionForm,
> >> >so it's not very smart right now, but as I said, this is a first
> >> approximation of the idea.
> >> >
> >> >So, in the end, you should be able to expose any existing Actions as
> >>Web
> >> >
> >> >Services without changing them.  Everything you need is included,
> >>except
> >> >for
> >> >a JDK, but I assume you have that already (!), including a
> >> dirt-simple test
> >> >client.  It's not a true SOAP client, but it gets the job done.
> >> >
> >> >Once you unzip the archive, I suggest reading the readme.txt file in
> >>the
> >> >
> >> >/source directory.  This goes into a bit more detail on everything,
> >> as well
> >> >as explaining how to use this in your own application.  I should also
> >> note
> >> >that this RequestProcessor is transparent to non-Web Service
> >> requests, i.e.,
> >> >you can use it in your existing apps without changing anything
> >> whether you
> >> >expose anything as a service or not.
> >> >
> >> >I thank anyone in advance that checks this out.  Please send me any
> >> comments
> >> >or suggestions you may have either to fzammetti@omnytex.com or just
> >>post
> >> >
> >> >them here.
> >> >
> >> >My hope is that given some time to refine this it will be tight
> >> enough and
> >> >useful enough that maybe I can present it to the developer list for
> >> possible
> >> >inclusion in the base Struts distro.  That's of course a ways off, if
> >>it
> >> >
> >> >ever reaches that point, but it's a start I think.
> >> >
> >> >Good day to all!
> >> >
> >> >Frank
> >> >
> >> >_________________________________________________________________
> >> Looking to buy a house? Get informed with the Home Buying Guide from
> >>MSN
> >> >
> >> >House & Home. http://coldwellbanker.msn.com/
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> >For additional commands, e-mail: user-help@struts.apache.org
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> >For additional commands, e-mail: user-help@struts.apache.org
> >> >
> >>
> >>_________________________________________________________________ Check
> >> out the coupons and bargains on MSN Offers!
> >>http://youroffers.msn.com
> >>
> >>
> >>---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >
> > _________________________________________________________________
> > Looking to buy a house? Get informed with the Home Buying Guide from MSN
> >  House & Home. http://coldwellbanker.msn.com/
> >
> >
> > --------------------------------------------------------------------- To
> > unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>

_________________________________________________________________
Looking to buy a house? Get informed with the Home Buying Guide from MSN 
House & Home. http://coldwellbanker.msn.com/


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


Mime
View raw message