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
[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.
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.
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.
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.
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.
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.
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?
---------------------------------------------------------------------------
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]>
