thanks Anne for your comments.
re. 2 - : is that a standard? I see, that axis generates a wsdl with a
wrapper tag for each operation in the service (in case of a message
style implementation). But is that a documented must do? I understand
the advantages, but still think this is a little overhead, if I just
want to switch from the usual binding to a raw xml implementation.
Obviously the wsdl should be pure semantics and not depending upon the
style of implementation.
-----------------------
oliver charlet
software development
11-041 Olsztyn, Poland
[EMAIL PROTECTED]
-----------------------
Anne Thomas Manes schrieb:
Some more guidance on this:
There are a couple of reasons why you might have to use a wrapper element:
1- If you want to send more than one root element in a single SOAP message
2- If you want your service to expose more than one operation
Hope this helps,
Anne
On 9/7/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Oliver,
Your WSDL message definition is not valid.
It should be:
<message name="operationA">
<part name="content" element="xsd:any"/>
</message>
Alternatively, you might want to define a wrapper element for your
message content, in which case you would define the message thus:
<message name="operationA">
<part name="content" element="tns:operationA" />
</message>
and you would also have to define the operationA element in your
<types> section:
<types>
<xsd:schema targetNamespace="[tns]">
<xsd:element name="operationA type="xsd:anyType"/>
</xsd:schema>
</types>
Anne
On 9/7/07, Oliver Charlet <[EMAIL PROTECTED]> wrote:
Hi y'all,
I am having trouble to get to work a setup that seems to be rare, but
which for me is rather practical:
1) I have a wsdl, that defines a schema for the input of a message, i.e.
I want the content of the soap body to of that schema. This wsdl is used
to communicate with the users of the service - of course.
2) I don't want a Java Binding, because I simply want to take the raw
XML from the body and do something with it (like serializing to filesystem).
3) So I create a "bottom up" service implementation, that uses the
message style Element[] operationA(Element[] elms) signature.
4) I use the wsdlFile tag to serve the original wsdl to the user, when
he asks for it using ...?wsdl on the Service URL
now the problem:
When I do 3), Axis would theoretically create a generated wsdl, that
would define my operation message part as:
<message name="operationA">
<part element="operationA" type="xsd:anyType"/>
</message>
that means, that in my case the actual payload of the incoming message
would need to be inserted into the operationA-Tag that was defined by
axis at the time of deployment as shown above.
After I do 4), axis still expects that Tag "operationA" to be inside the
soap body. But now I have a service that does not reflect the published
wsdl, which after 4) is the original one defining the payload to be an
instance of the schema inside it - without the operationA-Tag.
That means, that any user trying to access my service, reading the
public wsdl will get an error, because axis expects a different soap
message.
This is a little complicated to explain - but still I hope, that someone
can give me a hint on how to do this the right way.
Again here is what I want to achieve:
- have an initial wsdl
- create a "generic" service implementation handling pure XML, avoiding
generation of XML-JAVA bindings
- publish the initial wsdl instead of the generated one
- make this scenario work...
Thanks for any help
:oliver
--
-----------------------
oliver charlet
software development
11-041 Olsztyn, Poland
[EMAIL PROTECTED]
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
