Thanks Kevin, I agree from a 30,000' point of view. See my comments below.
Michael Oliver AppsAsPeers LLC 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 10:02 AM To: Struts Developers List Subject: Re: First Topic for discussion on Axis4Struts Here is a more compact version of the sequence diagram in the message below - hopefully it will be readable on more e-mail clients. Sorry! Client Axis Axis4Struts Struts (in Axis) | | | | | ------------>|| | | | (JMS, HTTP, || | | | SMTP, etc) || | | | || --------->|| | | || || | | | ||----------->|| | | ||(HTTP Req.) || | | | || Kevin http://www.strutskickstart.com [Mike Oliver>>] BTW Bought the book. [EMAIL PROTECTED] To: "Struts Developers List" <[EMAIL PROTECTED]> 01/20/2003 11:54 AM cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Please respond to "Struts Subject: Re: First Topic for discussion on Axis4Struts Developers List" > One of the first topics of discussion is where the Axis4Struts entry > point should be? > I can see several possibilities: > One would be to clone/extend the ActionServlet as it is the component in > standard struts that calls the Module's RequestHandlers. The advantage > here would be the same RequestHandler objects for Struts modules would > be called getting reuse at that level. The problem there is that there > is heavy dependency on the content and context of the HTTPRequest and > HTTPResponse in the ActionServlet which means heavy lifting to translate > the SOAPRequest and SOAPResponse payloads. My only concern with extending ActionServlet is that it is likely that ActionServlet will change significantly over time. If we relied on particular "super." methods to exist in an AxisActionServlet (or whatever it would be called) then it's likely we'd find ourselves refactoring periodically as the main ActionServlet changed. [Mike Oliver>>] concur and dependencies are many so extending ActionServlet does appear to be an overly complex way to do it on the surface. The attraction, especially with HTTP SOAP Requests is that there is so much commonality it seems on the surface to be "do" able....;-)> There may be a better way to 'loosely couple' the entry point so that we essentially assume (or define) an API into the Struts ActionServlet. > There are other possibilities such as AspectJ and even the use of > Servlet Include and Forward of the SOAPRequest and SOAPResponse through > a dispatcher where the SOAP/Axis Servlet just acted to interpret and > translate the payload into a normal urlencoded or multipart form-data > post to the Struts Interface. This seems like the least risk approach, though not as elegant as would be nice. But it might be a good place to start. Here are a couple of thoughts on this: 1. While the interface into Axis can be transport-independent (JMS, smtp, http), the interface to Struts will either require an HTTP request to be generated or some-sort of 'mock' HTTPRequest, etc. objects to be created. [Mike Oliver>>] Since the HTTPRequest and HTTPResponse are passed to all actions, it makes it impossible in the current design of Struts to create a non HTTP entry point without a 'mock' HTTP* object, although if the Axis SOAP Request uses the HTTP transport, potentially we would have access to those HTTP* objects. Given the potential changing nature of the Mock Objects you'd have to created it might simply be cleaner to assume that the Axis interface/entry point will have to be an HTTP request from the Axis interface code. [Mike Oliver>>] Agreed, if the Axis4StrutsImpl.class was an HTTP Request marshaller that would obviate many changes in Struts itself and make the Axis4Struts more portable and let it be "bolted on" to existing Struts Applications. That is, *someone* will have to generate the HTTPRequest, etc objects for Struts to process a request. It might just be the best approach to begin with to have the Axis interface object(s) do this. One other important design decision is whether or not Axis and Struts need to live in the same servlet context. I've put some thought to this and my initial thoughts are that the Axis code and the Struts code should be allowed to live in seperate webapps (or even on seperate servers) if desired for some reason by the users. This is a vote in favor of making the interface between Struts and Axis be an HTTP request. [Mike Oliver>>] completely agree here too. The Web Service then becomes just another client to the Struts Application, sort of an Agent. So, if that's the case then a sequence diagram would look like: Client Axis Axis Interface Code Struts | | | | | ------------------------->|| | | | (JMS, HTTP, SMTP, etc) || | | | || ------------------->|| | | || (Axis Processing) || | | | || --------------------->|| | | || (HTTP Request) || | | | || (Hope that came out ok for various e-mail clients!) The bottom line here is that the Axis Interface Code (i.e. Struts4Axis) has an entry/exit point that is an http request/response. So, then there are two parts to the processing that Struts has to do: 1. Handle a request as it normally would. To be honest, very little (if any) new code would be required here (knocking on wood...). Struts already does all the work needed. The effort on the request side is basically writing Axis code that can take a SOAP request, turning it into an HTTP request and sending it to Struts. 2. Struts would need to send a response back out (as an HTTP response) that Axis4Struts can translate back into a SOAP response. This is a bit trickier. The effort here would be the creation of some Axis4Struts classes that would live in Struts that can be fed response data and turn it into a standard response format so it can be parsed/processed by Axis4Struts. [Mike Oliver>>] Concur here too, the output would need to be some sort of standard wrapper for a payload that can vary. Perhaps even the creation of the SOAPResponse, however that would short circuit the Axis engine to an extent. The encoding/formatting of this data would take some thought, but I'd propose using XML and having the Axis4Struts response code (in Axis) assume the response XML was in some standard format. Providing information in the XML that allows the Axis4Struts code to 'map' the Struts response data back into a SOAP resonse will take some thought. [Mike Oliver>>] Agreed, some examples of this idea will go a long way to understanding the tradeoffs. Given this broad overview, I can see a few major pieces that need to be built: - The WSDL definitions. We would likely have to define some base WSDL elements that would need to be specified in the SOAP requests. Defining this will take work and some thought to make sure it's portable. - Axis request processing. This would include parsing the data in the SOAP request and turning it into an HTTP request to Struts. - Struts Response processing. This would be in the form of Struts 'helper classes' that assist users in converting response data into a standard xml format that could be processed once the data is returned to the Axis4Struts response handler in Axis. - Axis Response processing. This would take the XML response data from Struts and map it back to the SOAP response. Of course there are probably major pieces of work that I've missed and there may be major roadblocks that I've overlooked - but at least this is a start. So - for those that are interested - how does this look as a first pass at the overall architecture for Axis4Struts? [Mike Oliver>>] Excellent, thanks. ------------------------------------------------------------------------ --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. ------------------------------------------------------------------------ --- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] > For additional commands, e-mail: <mailto:[EMAIL PROTECTED] > ------------------------------------------------------------------------ --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. ------------------------------------------------------------------------ --- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
