Mike -
> If we start with the idea [Kevin's suggestion] that on the Axis side we
> develop a Web Service that accepts SOAP Requests with an XML payload and
> 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 get
something started. It may be better in the long run to try to 'embed' Axis
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 may
be good to implement.
I think that the HTTP Post interface may be the best place to start because
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?
Primarily:
- Allowing developers already familiar with Struts to build Web Services
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 handle
non-browser clients (.NET, Swing, JMS, etc.)
> What should we do over and above the minimum accepting of SOAP Requests
> and spinning into an HTTP Browser emulated POST to Struts to add value?
To begin with I'm thinking not much. After we get something built and get
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 with
> 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 making
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 to
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 with.
This means the Axis app will be "very thin" to begin with. All items are of
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 should
be able to specify them in the SOAP request to over ride the defaults and
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 create
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 be
extended.
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 types
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
required.
> 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 able
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 Scaffold
> 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 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]>
