And just to clarify...
The difference between doc/literal and wrapped/literal is in the way
you invoke the service -- the contents on the wire (the structure of
the SOAP message) will be identical.
In doc/literal, you input an object (javabean), and you return an
object (javabean). In
The WSDL is valid. xmlspy should be able to load an inline-defined namespace.
On Mon, 07 Feb 2005 14:53:57 +0100, THIBAULT Joseph
[EMAIL PROTECTED] wrote:
And this is the generated wsdl :
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
This is not a bug -- this is a requirement of SOAP. The child element
of the SOAP body indicates to the SOAP processor how to handle the
request. This child element must provide a unique signature so that
the SOAP processor can figure it out. The SOAP specification doesn't
specify how to process
For easiest interoperability with .NET, I suggest you use the wrapped style.
.NET does allow you to send raw XML, but to do so you have to use a
low-level API. In other words, you can't invoke the service using a
WebReference. To do that you should use wrapped style.
-Anne
On Thu, 10 Feb 2005
that I had to go through the whole call.invoke()
mumbo-jumbo on the client side.
Thanks,
Linus
On Feb 10, 2005, at 12:36 PM, Anne Thomas Manes wrote:
This is not a bug -- this is a requirement of SOAP. The child element
of the SOAP body indicates to the SOAP processor how to handle
Simon's correct: .NET supports both RPC/encoded and Document/Literal.
But it does not support RPC/Literal, and that's what this WSDL is
using.
I suggest you convert your service to Document/Literal using the
wrapped convention.
Anne
On Wed, 2 Feb 2005 14:39:42 -0600, Brown, Mike
[EMAIL
There are 4 or 5 WhoIs services listed at www.xmethods.org.
Anne
On Wed, 2 Feb 2005 20:18:12 +0100 (CET), Tomek Minkowski
[EMAIL PROTECTED] wrote:
Hi,
I guess this is off-topic, but I guess you' re the guys that might
know the thing...
Is there an integrated web
Dennis,
Great presentation -- Thanks!
I disagree with you about UDDI, of course. UDDI is an important
component for enterprise SOA management and governance. I don't see
very many people using it for dynamic discovery, but many firms that
have deployed a large number of services rely on UDDI to
For some reason I can't open the attached WSDL file, but there's
nothing wrong with specifying xmlns= in an unqualified element. In
fact, assuming that the in0 is an unqualified element, it's
required.
So I don't think this is a bug in Axis. If JBoss is rejecting the
xmlns= attribute, then it's a
Eugene's point is that he attempted to do deploy a wrapped style
service using only an implementation and a WSDD file (which Axis claim
to do), but the generated WSDL document produced errors.
It did, in fact generate a doc/literal wrapped style service (not
rpc/encoded), but there are still
The namespace is valid, but there's no schema associated with it.
Therefore other SOAP implementations aren't able to resolve elements
or attributes from that namespace.
On Wed, 19 Jan 2005 15:42:08 -0700, Steven Dahlin
[EMAIL PROTECTED] wrote:
In using the Java2WSDL app or by handcoding I am
UDDI.org provides a hosted v3 test registry. IBM, Microsoft, SAP, and
NTT all supply replicated nodes in that registry. See
http://www.uddi.org/register.html for the URLs of these registry
nodes.
Systinet also provides a hosted test registry. See
http://www.systinet.com/uddi/web.
But if your
Not sure what you mean by Axis not supporting intermediaries.
You can certainly route messages to and from Axis through
intermediaries. Typically today, most people use a web services
management (WSM) or enterprise service bus (ESB) product to implement
intermediaries. These intermediary
. Is it unnecessary overhead, or is it
something to make certain client tools happy?
Bill
Anne Thomas Manes wrote:
Clarification:
Bug: In document/literal mode, Axis generate a methodNameReturn tag
when
writing out the return value; it shouldn't. That tag only makes sense
in
wrapped
If you want your return value to be a User object, then that should be
your return structure, not getUserResponse. i.e.,
soapenv:Body
user
nameJohn Smith/name
address10 Main St./address
/user
/soapenv:Body
The output message should be defined so:
wsdl:message name=getUserResponse
wsdl:part
Clarification:
Bug: In document/literal mode, Axis generate a methodNameReturn tag when
writing out the return value; it shouldn't. That tag only makes sense in
wrapped/literal mode. (This is what Ann was saying.)
Axis should generate a methodNameReturn tag only when using RPC
style. It
I believe that the detail element is invalid.
The detail element is defined so:
xs:element name=detail type=tns:detail minOccurs=0 /
xs:complexType name=detail
xs:sequence
xs:any namespace=##any minOccurs=0 maxOccurs=unbounded
processContents=lax /
/xs:sequence
xs:anyAttribute
It shouldn't matter.
What errors are you getting?
On Mon, 10 Jan 2005 11:17:44 +0200, Ilkka Heinonen
[EMAIL PROTECTED] wrote:
Hello All,
Thank You, Anne, from your reply for last question.
http://www.newsarch.com/archive/mailinglist/axis/user/msg08622.html
Using WSDL2Java, seems that
I can't definitively answer your basic question regarding performance,
but based on anecdotal evidence, I expect you to experience a 5x or
better performance improvement when switching from SOAP to Axis.
The article you cited regarding Axis doc/literal and DOM refers only
to the Axis message
Brian,
In XML Schema, in order to reference an element or type from another
schema, you must first import the namespace into the schema.
You need to add the following import statement to the second schema:
import namespace=http://valueobject.util.app.willyloman.com/
And this import statement
See
http://www.burtongroup.com/weblogs/annethomasmanes/archives/2004/04/000187.html
-Anne
On Thu, 6 Jan 2005 16:40:08 -, Suzy Fynes
[EMAIL PROTECTED] wrote:
How does the wrapped style work?
-Original Message-
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Sent: 05 January
You need to add an operation definition to the WSDD that maps the
message element qname to the method name.
See http://www.osmoticweb.com/axis-wsdd/operation.htm
- Anne
It doesn't matter.
If you prefer to use parameters, use the wrapped style.
If you prefer to use an object, use the document style.
Anne
On Wed, 5 Jan 2005 10:04:18 -, Suzy Fynes
[EMAIL PROTECTED] wrote:
Hi,
When creating a web service in Axis that will have a number
Your WSDL isn't valid. You've mixed rpc and document styles, plus you
have attributes in your top level input and output elements. You may
not use attributes in your top-level input or output element when
using either rpc or wrapped styles. You must use document style.
Change your binding
Well...
You're using RPC/encoded, and you're using SOAP encoding arrays. And
although these aren't Java-specific, they will cause interop problems
with .NET. If you want to ensure interoperability with .NET, you
should stick with WS-I compliance and use the wrapped style.
Anne
On Sun, 02 Jan
It's a bug. Please file a bug report.
- Anne
On Sat, 1 Jan 2005 11:41:40 -0500, Donnie Hale
[EMAIL PROTECTED] wrote:
Simon,
I appreciate the response. If you know, how do I get Axis to not insert that
prefix when it auto-generates the WSDL? Is it a bug, and should I submit a
new bug
Can you supply us with the WSDL file?
The SOAP Body element (the message name -- in your case GetAddressFor
AddressID) is required to be a qualified element. In an rpc-style
message, the namespace qualifier must be defined in the namespace
attribute in the soap:body definition in the WSDL
You must use xsd:import to import a schema, not wsdl:import.
something like this:
wsdl:definitions name=foo targetNamespace=urn:foo
xmlns:wsdl=...
xmlns:soap=...
xmlns:foo=urn:foo
xmlns:bar=urn:bar
wsdl:types
xsd:schema targetNamespace=urn:foo
xmlns:xsd=...
You need to import your second schema into your first schema in order
to reference the HelloWorld element. Like so:
schema targetNamespace=http://ce.vtt.fi/HelloWorld/HelloWorld.wsdl;
xmlns=http://www.w3.org/2001/XMLSchema;
import namespace=http://ce.vtt.fi/HelloWorld/HelloWorld.xsd/
Answers inline...
On Tue, 21 Dec 2004 23:50:24 -0500, tony k [EMAIL PROTECTED] wrote:
Hi All,
I'm relatively new to web services and axis, so forgive me if this is old
hat,
but i have a few questions that i was hoping the more learned may be able to
answer.
(1) if i wanted to use
Just to clarify:
On Wed, 22 Dec 2004 09:52:19 +0100, WAJSBERG Julien RD-BIZZ
[EMAIL PROTECTED] wrote:
Ephemeris Lappis a écrit :
snip
Despite my problems with the java2wsdl task, i have finally use a 'wrapped'
axis wsdl to generate my client stubs for a single operation service that
takes a
Ah -- the challenge with using abbreviations...
I typically associate WS-RM with WS-ReliableMessaging. The OASIS spec
is called WS-Reliability. WS-Reliability is not gaining any traction
among the vendors and is likely to wither away.
Meanwhile, Systinet and Cape Clear have released production
Note that Axis doesn't really support RPC/Literal. It kinda supports
it from a client perspective, but there's no Axis WSDD style
attribute value that corresponds to RPC/Literal.
I suggest you use Wrapped Document/Literal instead.
(Note that .NET does not support RPC/Literal, either.)
Anne
On
There's no need to do this.
In an rpc/encoded WSDL, the message part must reference a type, not an
element. It's perfectly legal to reference an xsd type. So the
original WSDL description is fine:
message name=HelloWorld.Execute
part name=nameParam type=xsd:string
Regarding the IBM presentation referenced at
http://www.dsg.cs.tcd.ie/~dowlingj/ teaching/ds/tutorials/AxisVeryAdvanced.pdf
Although I concur with the design best practices recommendations he
makes on page 2, there are a number of errors in the presentation. For
example, his example SOAP
WS-I Basic Profile prohibits use of SOAP encoding, but rpc/literal
style is permitted. Unfortunately, .NET does not support rpc/literal,
therefore I suggest you stick with document/literal or wrapped
document/literal only.
Anne
On Fri, 17 Dec 2004 12:00:31 +0100, HG [EMAIL PROTECTED] wrote:
Hi
Christian,
There is a problem with your WSDL. You have a soapAction attribute
specified on the wsdl:portType/wsdl:operation element, which is not
permitted:
portType name=HelloWorldSoapPort
operation name=Execute
soapAction=http://localhost:8090/action/HelloWorld.Execute;
references.
Anne
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 15, 2004 3:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote reference!
Le 15 déc. 04, à 00:53, Anne Thomas Manes a écrit :
SOAP doesn't support remote references.
That has been
references.
Anne
-Original Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 15, 2004 3:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote reference!
Le 15 déc. 04, à 00:53, Anne Thomas Manes a écrit :
SOAP doesn't support remote references.
That has been
Bad idea. Always avoid collections. Use an array instead.
-Original Message-
From: jay limfueco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 15, 2004 2:52 AM
To: [EMAIL PROTECTED]
Subject: Serialization Compatibility
Hi,
I'm currently working on a web service that should support
Bad idea. Always avoid collections. Use an array instead.
-Original Message-
From: jay limfueco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 15, 2004 2:52 AM
To: [EMAIL PROTECTED]
Subject: Serialization Compatibility
Hi,
I'm currently working on a web service that should support
SOAP doesn't support remote references.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 7:38 AM
To: Axis User mail list
Subject: Remote reference!
Hi all!
How are remote references to a web service implement in axis at client side?
SOAP doesn't support remote references.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 7:38 AM
To: Axis User mail list
Subject: Remote reference!
Hi all!
How are remote references to a web service implement in axis at client side?
our
code in a relatively easy manner without the need of creating a WSDL
first which is perfect.
Anne Thomas Manes wrote:
I'm thinking about reusability.
Picture yourself a couple of years from now when your company has a few
thousand services deployed. Like most companies you have about
our
code in a relatively easy manner without the need of creating a WSDL
first which is perfect.
Anne Thomas Manes wrote:
I'm thinking about reusability.
Picture yourself a couple of years from now when your company has a few
thousand services deployed. Like most companies you have about
When defining a document/literal style service, your input message must
contain at most one body part. You cannot list each of your input elements
as separate parts in the input message definition. You must define a wrapper
element for your two input parameters and reference this one element in
When defining a document/literal style service, your input message must
contain at most one body part. You cannot list each of your input elements
as separate parts in the input message definition. You must define a wrapper
element for your two input parameters and reference this one element in
This is a known soap encoding interoperability problem between .NET and
Axis.
In my opinion, Axis interprets the SOAP specification correctly by using
soapenc:string rather than xsd:string, but .NET doesn't know how to
interpret soapenc:string.
For better interoperability, you should use
This is a known soap encoding interoperability problem between .NET and
Axis.
In my opinion, Axis interprets the SOAP specification correctly by using
soapenc:string rather than xsd:string, but .NET doesn't know how to
interpret soapenc:string.
For better interoperability, you should use
Typically I prefer not to use a bunch of
different schemas with a service (e.g., one schema for each element and type). In
order to reference an element (or type) from one schema (a) in another schema
(b), you must explicitly import the (a) schema (and define a namespace
declaration) into
Typically I prefer not to use a bunch of
different schemas with a service (e.g., one schema for each element and type). In
order to reference an element (or type) from one schema (a) in another schema
(b), you must explicitly import the (a) schema (and define a namespace
declaration) into
I was a little confused by your import
structure I wouldnt expect to use wsdl:import at all. My suggestion is as follows:
Define standalone element schema (what you
call type-schema).
Define standalone input/output message
schema (what you call message-schema).
xsd:import
the
I was a little confused by your import
structure I wouldnt expect to use wsdl:import at all. My suggestion is as follows:
Define standalone element schema (what you
call type-schema).
Define standalone input/output message
schema (what you call message-schema).
xsd:import
the
and wsdl imports in respect to
namespaces.?
/Henrik
- Original Message -
From: Anne Thomas Manes
To: [EMAIL PROTECTED]
Sent: Tuesday, November
16, 2004 2:45 PM
Subject: RE: Best Practice
Typically I prefer not to use a bunch of
different
and wsdl imports in respect to
namespaces.?
/Henrik
- Original Message -
From: Anne Thomas Manes
To: [EMAIL PROTECTED]
Sent: Tuesday, November
16, 2004 2:45 PM
Subject: RE: Best Practice
Typically I prefer not to use a bunch of
different
is heresy. If it is, I'd like to know how my concerns
can be countered. Thanks!
Anand
On Tue, 16 Nov 2004, Anne Thomas Manes wrote:
: Technically, an import is importing a namespace, not the schema or WSDL
: file that creates the namespace.
: The WS-I Basic Profile says that you must not coerce
is heresy. If it is, I'd like to know how my concerns
can be countered. Thanks!
Anand
On Tue, 16 Nov 2004, Anne Thomas Manes wrote:
: Technically, an import is importing a namespace, not the schema or WSDL
: file that creates the namespace.
: The WS-I Basic Profile says that you must not coerce
In Java, string is a simple type; String is not. The question is why did
Axis map your CurrencySymbolT type to String rather than string, and
since it did so, why does the code expect a simple type. Since this is all
generated code, I'd say this is a bug. Please file a bug report.
As a work
In Java, string is a simple type; String is not. The question is why did
Axis map your CurrencySymbolT type to String rather than string, and
since it did so, why does the code expect a simple type. Since this is all
generated code, I'd say this is a bug. Please file a bug report.
As a work
The JAX-RPC specification [1] defines standard mappings of Java types to XML
types. Current products (including Axis) support JAX-RPC 1.1.
[1] http://java.sun.com/xml/downloads/jaxrpc.html
- Anne
-Original Message-
From: Martin Hamel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November
the limitations of the current platform, though (especially since the
platforms are all becoming more capable as time goes by).
- Dennis
Anne Thomas Manes wrote:
Mark,
Designing a WSDL contract refers to the process of designing your SOAP
interface based on the XML messages you intend to exchange (defined
the limitations of the current platform, though (especially since the
platforms are all becoming more capable as time goes by).
- Dennis
Anne Thomas Manes wrote:
Mark,
Designing a WSDL contract refers to the process of designing your SOAP
interface based on the XML messages you intend to exchange (defined
Marcos,
A document/literal message should contain at most one body message part. You
have defined three. You need to define a wrapper element for your three body
elements. For better interoperability, I suggest you use the wrapped
style. Give the wrapper element the same name as your operation,
Marcos,
A document/literal message should contain at most one body message part. You
have defined three. You need to define a wrapper element for your three body
elements. For better interoperability, I suggest you use the wrapped
style. Give the wrapper element the same name as your operation,
Mark,
Designing a WSDL contract refers to the process of designing your SOAP
interface based on the XML messages you intend to exchange (defined using
XML Schema) rather than based on the Java interface of your service agent.
The XML Schema type system doesn't support Hashtables, Maps, Lists,
Mark,
Designing a WSDL contract refers to the process of designing your SOAP
interface based on the XML messages you intend to exchange (defined using
XML Schema) rather than based on the Java interface of your service agent.
The XML Schema type system doesn't support Hashtables, Maps, Lists,
. To get over this just edit the
WSDL before generating the java code to change the QNames to be unique
within
an operation.
All then works fine. If you already have an impl class generated from an
earlier run you will need to either rename it or remove it.
Regards
Steve
Quoting Anne Thomas Manes
Title: DocumentBuilder could not parse it? Why?
Certain parsers barf on the xmlns:xml namespace declaration
(even though its valid).
From: Muthusamy,
Elavarasan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004
4:07 PM
To: [EMAIL PROTECTED]
Subject: DocumentBuilder
advice on this mailing list to see if somebody else has solved
this or a similar issue.
Regards
Steve
Quoting Anne Thomas Manes [EMAIL PROTECTED]:
Steve,
I'm quoting the specs. Per the specs, faults must be defined as
document/literal. That fact that it works when defined as rpc/encoded
Note, though, that fault messages MUST be defined as document/literal rather
than rpc/encoded, per the WSDL 1.1 specification [1]:
wsdlExcerpt
3.6 soap:fault
The soap:fault element specifies the contents of the contents of the SOAP
Fault Details element. It is patterned after the soap:body
A lot of it depends on the semantics of the interface. How relevant is this
removed attribute to the existing client applications? Can you generate a
default value for the attribute for these existing clients and still have it
work?
One of the easiest ways to make this work is to intercept
A lot of it depends on the semantics of the interface. How relevant is this
removed attribute to the existing client applications? Can you generate a
default value for the attribute for these existing clients and still have it
work?
One of the easiest ways to make this work is to intercept
Axis 1.1 returns axis:Server.userException where it should return
soapenv:Client. Because these fault codes are defined in a separate
namespace, technically, this isn't a bug. But a developer should have the
choice to return the standard soapenv fault codes.
This issue has been fixed in Axis 1.2.
Axis 1.1 returns axis:Server.userException where it should return
soapenv:Client. Because these fault codes are defined in a separate
namespace, technically, this isn't a bug. But a developer should have the
choice to return the standard soapenv fault codes.
This issue has been fixed in Axis 1.2.
Axis doesn't work directly with IP, so it's unaware of whether you're using
IPv4 or IPv6. So whether or not it supports IPv6 depends on the environment
that you've deployed Axis in (servlet engine, JVM, etc.)
- Anne
-Original Message-
From: William Fitzgerald [mailto:[EMAIL PROTECTED]
Axis doesn't work directly with IP, so it's unaware of whether you're using
IPv4 or IPv6. So whether or not it supports IPv6 depends on the environment
that you've deployed Axis in (servlet engine, JVM, etc.)
- Anne
-Original Message-
From: William Fitzgerald [mailto:[EMAIL PROTECTED]
Please explain what you mean in more
detail. With Axis/SOAP you send and receive messages --- but you cant call
an array of objects. You can send an array of objects to a service, and you can
receive an array of objects from a service. What would you like to do?
Anne
From:
Please explain what you mean in more
detail. With Axis/SOAP you send and receive messages --- but you cant call
an array of objects. You can send an array of objects to a service, and you can
receive an array of objects from a service. What would you like to do?
Anne
From:
I suspect that the service is expecting a wrapper element called
DocumentGetCollection rather than DocumentGetCollectionRequest, although
that's not what the WSDL indicates.
Can you ask the service developer to supply you with the WSDD of the service
and a sample SOAP request message from C#
I suspect that the service is expecting a wrapper element called
DocumentGetCollection rather than DocumentGetCollectionRequest, although
that's not what the WSDL indicates.
Can you ask the service developer to supply you with the WSDD of the service
and a sample SOAP request message from C#
Please file a bug report.
Thanks!
-Original Message-
From: Dan Ciarniello [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004 2:56 PM
To: [EMAIL PROTECTED]
Subject: Re: WSDL2Java and Basic Profile
Anne Thomas Manes wrote:
Dan,
The child elements (id, thedate, and avalue
Please file a bug report.
Thanks!
-Original Message-
From: Dan Ciarniello [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004 2:56 PM
To: [EMAIL PROTECTED]
Subject: Re: WSDL2Java and Basic Profile
Anne Thomas Manes wrote:
Dan,
The child elements (id, thedate, and avalue
There are two problems with this fault message:
1- The SOAP-ENV:Fault element must be the first and only child element in
the SOAP-ENV:Body element. It cannot be a child of the ns1:SomeFunction
element. If you want to return the ns1:SomeFunction information in the
fault, it must be encoded within
There are two problems with this fault message:
1- The SOAP-ENV:Fault element must be the first and only child element in
the SOAP-ENV:Body element. It cannot be a child of the ns1:SomeFunction
element. If you want to return the ns1:SomeFunction information in the
fault, it must be encoded within
A qname (qualified name) is a name that consists of a namespace prefix (the
characters before the colon) and a local name (the characters after the
colon). For example, in the qname wsdl:portType, wsdl is the namespace
prefix, and portType is the local name. A namespace prefix is an
abbreviation
Each qname maps to only one class, so you must define a different
beanMapping for each bean class.
Anne
-Original Message-
From: Suzy Fynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004 3:07 PM
To: [EMAIL PROTECTED]
Cc: 'Anne Thomas Manes'
Subject: RE: namespaces
That's
You can have more than one
beanMapping tag in a WSDD. You cannot specify more than one bean class
in the same tag.
Anne
From: Suzy Fynes
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004
10:48 AM
To: [EMAIL PROTECTED]
Subject: beanMapping in WSDD
Hi,
Can
-Ursprüngliche Nachricht-
Von: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 13. Oktober 2004 12:39
An: [EMAIL PROTECTED]
Betreff: RE: WSDD configuration problems
One problem with your WSDL is that two of the elements in your Con type
reference a type
Dan,
The child elements (id, thedate, and avalue) are defined as local
elements (defined inside a complex type), and therefore must be unqualified.
Therefore the elements must include the no default namespace definitions
(xmlns=). If you prefer to make these element qualified, you can add the
Interesting. I think you found a bug in the WS-I Basic Profile.
According to the WSDL 1.1 specification [1] and the latest version of the
WSDL 1.1 XML Schema [2], the definitions/binding/operation/input element
does not include the @message attribute. Therefore the sample in the WS-I
Basic Profile
One problem with your WSDL is that two of the elements in your Con type
reference a type (impl:ArrayOf_soapenc_string) that hasn't been defined:
element name=products nillable=true
type=impl:ArrayOf_soapenc_string/
element name=areas nillable=true type=impl:ArrayOf_soapenc_string/
As a result,
-Original Message-
From: Christopher B Ferris [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 13, 2004 1:57 PM
To: Anne Thomas Manes
Subject: Re: FW: Error in the Basic Profile
Thanks Anne! I've forwarded to the bpwg list and we'll add it to the
errata.
Cheers,
Christopher Ferris
Because your schema specifies elementFormDefault=qualified, then all local
elements (including piClieNr2/piClieNr and
pcMedewerkermanager/pcMedewerker must be qualified with the
urn:tempura-org:RISC namespace. Child elements do not inherit the
parent's namespace unless the parent defines a default
Johannes,
In the wrapped style, the name of your input message element must be the
same as your operation name.
If the operation name is CONVERTDATA_IPC_PVA, then your input message
element should also be called CONVERTDATA_IPC_PVA. Alternatively, if your
input message element is called
Can you please provide the WSDL?
Looking at your message, it looks to me that the ns1:CONVRequest element
should be your wrapper element.
Axis will generate a message that corresponds to the input message
definition in the WSDL. The wrapper element is referenced in the message
part definition.
and lastname.
But, how would it represent the type=1 in the java objects? (Assuming
I'm right about how it would represent the nested objects.)
Thank you for your help! Axis is very exciting... I wish I had converted
over sooner.
-Raiden Johnson
On Fri, 1 Oct 2004, Anne Thomas Manes wrote
As a rule of thumb, you should use the Axis wrapped style. (Sometimes you
can't, but the example you cite below is fine.) The wrapped generates
document/literal messages, and it manages the message building process for
you. Axis automatically maps the XML message to Java objects based on the
and a test class and that would show how
to throw interoperable exceptions from Axis as well as
other popular topics like arrays, etc.
I might, of course, have misunderstood what I need to
change in my WSDL.
On 28 Sep 2004 at 23:57, Anne Thomas Manes wrote:
No -- this fault isn't interoperable
I disagree. The Sun JAX-RPC reference
implementation in JWSDP contains a web services framework thats
comparable to (albeit different from) the framework in Apache Axis. The point
is that someone that implements the JAX-RPC API cant simply implement
the API they also must supply a
Are you saying that the payload must be a separate XML document with its own
?xml header? Or is your requirement only that the payload contains an XML
structure that conforms to the standard XML schema (an XML fragment)?
If you must send a separate document rather than a document fragment, then
1 - 100 of 750 matches
Mail list logo
