Richard Monson-Haefel

Not totally sure what the question is (sorry), but the webserivces.xml file is used in conjuntion with J2EE Web Service components, the JAX-RPC Service Endpoints and the EJB Endpoints. The service-ref element is simply configuring a JAX-RPC client side gererated stub or dynamic proxy so that the J2EE component, be it a Servlet, JSP, or EJB, can access that stub/proxy to communicate with some other Web service.

If an input and output message have a part with the same name, but a different type, than they would be interpreted as different paramters (IN and OUT). That said, the WS-I BP clearly prohibits this so if an input and output have a part with the same name, they must be the same type and therefor it represents an INOUT parameter.

Java is always pass by copy. In the case of object refernces, the thing copied is the reference to the object, rather than the object itself.

Originally posted by Dhiren Joshi:
I have some clarification confusion on interpretting some basic profile statements .

4. A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

Ok, if you are using attachments with a SOAP message than its possible that the attachment will be one of the part elmeents of a message defintion, in which case you don't want to include it in the body when doing the bindings. So, you can specify which <part> defintions of the <message> element are part of the body. In the case of document/literal binding only one <part> of a message may be the body, because a doc/lit message may contain only one paramter, the XML document fragment. This is explained in detail in Appendix G of the RMH book.

Originally posted by Dhiren Joshi:
I have some clarification confusion on interpretting some basic profile statements .

1.
The media type of a MESSAGE's envelope MUST indicate the correct character encoding, using the charset parameter.
Where is the media type defined in a MESSAGE envelope. ?

I think they are refering to the XML encoding which may be UTF-8 or UTF-16. You can find this in the XML declaration - if there is one. If there isn't, than its assumed to be UTF-8

e.g <?xml version="1.0" encoding="UTF-8"?>

2.A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile.

What are WSDL extensions ?

An extension is a set of elements that are used in combination with the WSDL binding element. For example, the soap peration element is part of the SOAP extension. Basically an extension provide protocol or encoding specific information to a WSDL document.

3.The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same

Can some one show me an example for number "3".

In the following example the targetNamespace attribute of the WSDL document and XML Schema document fragment (in side the WSDL:types element) are the same. This is allowed. They can also be different.

<?xml version="1.0" encoding="UTF-8"?> <definitions name="BookQuoteWS" [B]targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"[/B] xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote" xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xsd:schema [B]targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"[/B]> <!-- The ISBN simple type --> <xsd:simpleType name="ISBN"> <xsd:restriction base="xsd:string"> <xsd :-P attern value="[0-9]{9}[0-9Xx]" /> </xsd:restriction> </xsd:simpleType>

4. A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

What is the parts attribute .. Is it referring to part in the message element ?
I didnt see any parts attribute in RMH .. .

Hmm... that looks like a new requirment. You can see examples of this in the RMH book on pages 813 and 814. I'll check into a post more later.

5.A wsdl:binding in a DESCRIPTION MUST use the attribute named part with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements.
6. A wsdl:binding in a DESCRIPTION MUST NOT use the attribute named parts on contained soapbind:header and soapbind:headerfault elements.

The query I have is parts attr not to be used yet it is defined in soapbind:body element containing soapbind:header
CORRECT:

<binding name="StockQuoteSoap" type="tns:StockQuotePortType">
<soapbind:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="SubscribeToQuotes">
<input message="tns:SubscribeToQuotes">
<soapbind:body parts="body" use="literal"/>
<soapbind:header message="tns:SubscribeToQuotes"
part="subscribeheader" use="literal"/>
</input>
</operation>
</binding>


7 .A DESCRIPTION MAY use any construct from XML Schema 1.0.


When it states a description may use any construct .. does it mean any elements from the XML Scheme can be used to represent any element in the definition.

It means that any valid W3C XML Schema type, be it a simple type or a complex type, can be used in a WSDL document. That means all the built-in simple types and any custom types that you or someone else defines.

Thanks
Dhiren

These two configuration files are not on the exam because they are specific to the RI.

All Java application servers use Thread Specific Storage to ensure that each thread has access to the appropriate context. That's a really wordy way of saying, they use ThreadLocal (or something a lot like it).

Believe it or not there is not much I can do to help. I'm just the author, its the job a Addison-Wesley to distribute the book. I have, however, made them aware that people in your area are having trouble getting the book.

Sorry that's a type in the book that is being fixed in the next printing.

The correct name is: elementFormDefault

For attribute its: attributeFormDefault

Are you sure that the service-ref element is supported by Axis? Its really a J2EE 1.4 thing, so i don't think that Axis would support it - it would only be used by J2EE 1.4 compliant appllication servers. I think that is the problem - you would probably have better luch with the J2EE 1.4 SDK (if you can get it working ... I have a terrible time with myself)

JWSDP 1.3 uses SAAJ 1.1 while J2EE 1.4 uses SAAJ 1.2. SAAJ 1.2 added the methods in question. In other words, they are defined in SAAJ 1.2 but not SAAJ 1.1. Since you are supposed to know SAAJ 1.2, you should not continue to study the SAAJ 1.1 API in JWSDP 1.3 - why aren't you working with the J2EE 1.4 SDK? (Actually I find that SDK very difficult to work with so there is really no mystery there. ;-)

An XML namespace gives the types defined in and XML schema a unique name - kind of like a sir name. In the US there are probably 10 million people named "John" so we use Sir names like "Smith" and middle names like "William" to distinguish one "John" from the next. You can think of element names as first names and XML namespaces as Sir names. (Its not a prefect analogy but it's illustrative).

Sometimes it's helpful to think of XML Namespaces as being similar to Java package names. When you create an XML Schema you are defining a type, just as a Java source file defines a type. The targetNamespace is the unique namespace of that type, just like the package name of a class defintion is the unique namespace of that type. In other words, declaring a targetNamespace in an XML Schema is the same as declaring a package name in a Java class file. It assigns the type(s) to a particular namespace.

The concept of a default namespace and a targetNamespace are orthogonal; they are separate concepts.

The default namespace has scope. If you create an XML document (be it an instance document, WSDL file, SOAP message or XML Schema) all of the elements are assumed to have unique namespaces. Usually, you will assign a prefix (a nick name) to each namespace and than tag elements that belong to that namespace with the prefix (e.g. <soap:Envelope> . However, it is possible to create a default namespace, which is the same as saying any elements without a prefix belong to a certain namespace. A default namespace is simply a namespace that is declared without a preface (e.g. xmlns="http://www.blue.com"). Default namespaces apply to the element in which they are declared and all of its children that do not use an explicit prefix.

You can override a default namespace by assigning a child element a different default namespace (e.g. xmlns="http:\\www.red.com") - that element and its children that do not have an explicit prefix will become part of the new default namespace.

I hope that helps. Tried to give you a couple different ways of thinking of things.


Richard

I just wanted to say, "Thank you!" to everyone who is posting questions, and in many cases answers questions, on this forum.

I'm probably not the best moderator - I find time to look the forum over about every three days - I should do it more frequently - but you all seem to be doing great. The questions are excellent both novice and more advanced a like.

This forum is improving my understanding of what people have trouble with when learning Web services. In addition, you have managed to catch a few errors in the book that we are correcting in subsequent printings.

Anyway, thanks again and keep up the great work!

Richard

I'm not sure if you have access to the J2EE Web Services book but it has a chapter on RPC/Encoded SOAP which explains the differences. In some case, as you mentioned, you may not be able to detect the difference between RPC/Encoded and an RPC/Literal - this is true for very simple calls because both use a structure to represent parameters to a remote call.

However, once you get into deeper waters the difference are more apparent. On thing that RPC/Encoded provides that RPC/Literal does not is referencing - like the ability to handle an object graph with circular references and such things. Turns out, however, that this is not compelling enough to offset the lack of clarity that section 5 of the SOAP 1.1 provides on mapping RPC calls to SOAP messages - this is why RPC/Literal is endorsed by the BP and RPC/Encoded is not - RPC/Encoded is not very clear and leaves too much open to interpretation so interoperability doesn't work very well.

Don't feel bad if this leaves you still scratching your head. The issues are, at best, difficult to explain � most self-proclaimed Web services experts don't understand the differences either � it took me a long time to figure it all out.

The important thing is to know that when the rubber hits the road, RPC/Encoded don't work. It will be come a foot note in the history of Web services and nothing more, so don't worry about it � its not important.

To be prefectly honest I've never read the tutorial or the book (I'm assuming you are refering to the O'Reilly book by Chappell and Tyler) so I have no idea if they will cover the stuff you need.