The JAX-RPC spec states that:
1. unlisted parameters appear in the order they were defined in the
message (Section 4.3.4).
2. soap:header elements are mapped to either explicit or implicit
service context (Section 11.1)
So for explicit service context, the Java method would presumably be:
void subscribeToQuotes(SubscribeToQuotes body,
SubscriptionHeaderHolder subscribeheader) throws RemoteException;
For implicit service context, I assume the programmer would write a
message handler to deal with the header element - or that the runtime
would add it automatically (e.g. if it's a security context).
Alternatively, your stubs/skels could support a List/Map property, which
allows you to manipulate parameters that go into the header.
Regards,
Bjarne.
>>> james.pasley_at_CAPECLEAR.COM 09/13/02 09:55AM >>>
Section 4.3.4 of the spec defines how to interpret the parameterOrder
attribute in order to recreate the RPC signature for the operation.
My question is this, when following these rules, what is the RPC
signature
for the SubscribeToQuotes operation contained in Example 3 (Section
3.1) of
the WSDL recommendation?
As I see it, the issue here is that the element that goes into the
header is
defined in the same wsdl:message as the part which goes into the body.
Following the JAX-RPC rules would mean that both "body" and
"subscribeheader" get added as parameters to the message, but this is
clearly not the intent of the WSDL.
I know the binding is doc/literal so it could be argued that I
shouldn't be
concerned with the RPC signature. However, people will always what to
generate code from the WSDL regardless of the binding type.
James.
Cape Clear Software Limited.
61 Fitzwilliam Lane
Dublin 2
Ireland
Email : james.pasley_at_capeclear.com
Switchboard : + 353 (1) 2419900
Direct line : + 353 (1) 2419957
Fax : + 353 (1) 2419901
www : www.capeclear.com
NEW CapeStudio 3, out now
Design, develop, integrate & deploy Web Services
http://www.capeclear.com/download