struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Oliver" <>
Subject RE: [AXIS4STRUTS] The old In and Out
Date Fri, 24 Jan 2003 19:13:59 GMT
Thanks Kevin, good start! I didn't want to sour the pool with my
thoughts on these questions up front but I will, rest assured...;-)

Michael Oliver
AppsAsPeers LLC
7391 S. Bullrider Ave.
Tucson, AZ 85747

-----Original Message-----
From: [] 
Sent: Friday, January 24, 2003 11:54 AM
To: Struts Developers List
Subject: Re: [AXIS4STRUTS] The old In and Out

Mike -

> If we start with the idea [Kevin's suggestion] that on the Axis side
> develop a Web Service that accepts SOAP Requests with an XML payload
> spins that payload into an HTTP POST/GET to a Struts Application as if
> that POST or GET was coming from a Web Browser.  Then we need not make
> any changes to Struts to accept the request as Struts may not know or
> need to know it was from Axis/SOAP (leave that to the application
> developers).

btw - I was thinking that this might just really be the easiest way to
something started. It may be better in the long run to try to 'embed'
in Struts directly and have Axis invoke the Struts MVC framwork
programatically. But even so, I think there's value in allowing the Axis
app and the Struts app to be on different servers - so both approaches
be good to implement.

I think that the HTTP Post interface may be the best place to start
it looks easier and faster to get going on.

> That presumption then begs some other questions:

> What advantages should this Axis4Struts bring to the table?


 - Allowing developers already familiar with Struts to build Web
apps without learning a great deal about Axis.
 - Allow developers to build a basic Axis/Struts app and extend the web
service offerings easily by just adding more 'Action's. I think this may
make it easier to maintain/extend Web Service apps than currently.
 - Allowing developers with existing Struts apps to extend them to
non-browser clients (.NET, Swing, JMS, etc.)

> What should we do over and above the minimum accepting of SOAP
> and spinning into an HTTP Browser emulated POST to Struts to add

To begin with I'm thinking not much. After we get something built and
users on it, I believe this will be easier to answer.

> Do we even bother with GET?

Can't see any value for initial release.

> Since any programmer can use commons-httpclient to form his own java
> emulation of a browser POST to struts, what advantage can we bring
> Axis4Struts?

Any programmer with a .NET client (or other non-java client) can't.

Other tools (such as Cold Fusion) now provide built-in support for
calls to Axis services. This could be leveraged.

Also, this may not be the only web service that the client app calls. If
you have an app that is accessing a variety of web services and you want
extend it to leverage some existing functionality in a Struts app, why
force the developer to write http-client posts?

I think there is value in this project.

> What would the WSDL for an Axis4Struts Web Service look like?  What
> messages, what types, etc.

I've put a some thought to this. Here's what I've been thinking:

The HTTP Post to the Struts app requires a few things:

      - A server/host and port
      - A servlet context/module
      - The Action ( ".do") URI
      - Name/Value pairs for data (essentially an array of pairs)

The WSDL should allow for these (and only these) I believe to begin
This means the Axis app will be "very thin" to begin with. All items are
type String.

I believe that it would be appropriate to let the first two (server
host/port and servlet context/module) to be specified at deploy time (in
the Axis wsdd file) to allow for default values. But the client code
be able to specify them in the SOAP request to over ride the defaults
allow the Web Service to expose resources from more than one Struts app
through the same Web Service.

> What should we do within the Struts framework to make it easier for
> developers to have a Forward that returned an XML Payload suitable for
> the Axis4Struts Response?

This I've not got a clear vision of. I'm thinking that initially we
some sort of utility we can pass a form bean to and have it inspect the
bean to find the properties it exposes. Then it could extract the values
and generate an XML response with them. This is a basic start that can

Handling Dynabeans and other beans/objects can be added.

Maybe a new form class that extends ActionForm would be useful.

> Should we use primitive types (Strings, Integers, etc.) only in the
> Axis4Struts.WSDL or should we include alternatives with Java complex
> types? (DynaBeans, NVPair[], etc.)

Initially, I'm thinking we simply allow Axis to accept only the data
that exist in the HTTP POST (i.e., ALL STRING).

.NET support is important so we should ensure we don't use types that it
won't work with. More complex types may be optional, but shouldn't be

> What and how should be do the discovery?  If a single interface with a
> multi-purpose payload for the Form Data is used, how will developers
> accessing the web service determine what the content of the payload
> should be?

Interesting question. Not really sure. I think there is value in being
to inspect to find 1) which services may exist, and/or 2) what
versions/parameters/etc (essentially metadata) apply for that service.

> What role should other common Struts compatible components like
> and JSTL  and other Axis compatible components like WSIF play in
> Axis4Struts?

Haven't thought that far yet!

This e-mail message (including attachments, if any) is intended for the
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt
disclosure.  If you are not the intended recipient, you are notified
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:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message