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 Thu, 03 Jun 2004 14:31:38 GMT
>Exactly! Actually...not sure about the template, but when u go via
>WS (webservices) all the client is interested is in getting back XML...
>The XML generated by you action class as a response...

That's the thing I want to avoid though... I don't want the Actions to be 
altered at all (and the ActionForms either if I can help it).  Therefore, 
the idea is to do all the Web Service stuff externally to those components.

>See, in some way what need to be handled is:
>- action form in the response must be written in XML
>- this XML must be written..either in a JSP or in the response (in both
>cases what the user will receive is a SOAP message
>so, we will end up at same point: unless you return raw XML from the
>action
>class, something will need to wrap the ActionForm for the response and
>produce XML out of it.
>A JSP/JSP tag can do that (and you will need only one page for all
>action classes, since that JSP will be in charge of taking the
>ActionForm from
>Request and make a SOAP response out of it).
>
>This will solve half of the problems :-(, because:
>How can a JSP extract automatically the Form associated with the
>request?
>More brainstorming :-)

That's what the current template JSP does... It just uses reflection to get 
a list of all members of the ActionForm, without knowing the specific class 
of the ActionForm, and then iterates over the members, calilng the 
appropriate getter for each, and constructing a simple XML response.  Since 
the RequestProcessor already set the response type to XML, the JSP is only 
responsible for constructing the proper SOAP-based response, nothing more.

Two things about that though are problematic...

(1) It's just dumping all the members of the class, there's currently no way 
to select which members to incluide, or what order, or any notion of 
structure beyond a flat list

(2) While this simple template might be OK for many situations, it doesn't 
allow for any flexibility in the returned XML.

That's where my idea of an added config file comes in... I picture it being 
loaded into memory via a plug-in, just like Struts-Config.xml is.  It would 
probably, off the top of my head, have a structure something like this:

<web-services-config>

  <service-mapping path="xxxx" target="yyyy" members="zzzz" />

</web-services-config>

... where:

xxxx - matches exactly the path attribute of the <action> from 
Struts-Config.xml being exposed
yyyy - is the path to the JSP to generate the XML output.  This would be 
optional.  If it's NOT present, be default the "webServiceResponse.jsp" 
template is used, which is what is there now, which just dumps all members 
of the ActionForm.  You can also specify a special value of "simple", which 
would use a new "simpleServiceResponse.jsp" template.  This would make used 
of the members element...
zzzz - is a comma-separated list of members to display using the "simple" 
template.  Basically the same thing as the default template except that you 
can specify which elements to return and in what order.

Any other target would be a JSP designed for a specific Action, so you could 
do whatever you wanted there, as long as you generate a valid SOAP-based XML 
response.  This is where a new taglib would probably be useful, to help 
ensure proper structure and whatnot.

Further, if no entry is found for a given Action mapping, or there never was 
this config file, then it would just proceed as it currently does, using the 
existing "dump everything" template.  That leaves all of this optional, 
which I think is a good thing (tm).

>Aspect Oriented Programming ...give it a check... u can add dynamic
>behaviour at run time... it came across my mind because you would want
>to
>Do some processing (when u are calling Action via XML) before the
>execute() method of an Action returns...

Ok, sure, I've heard of it, just didn't recognize the acronym :)  I'm not 
sure how it would fit in here though, my admittedly limited understanding is 
that AOP is more or less a technique for architecting a system (i.e., view 
things as Aspects instead of Objects, along those lines).

_________________________________________________________________
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message