# Sun Certified Web Services Developer Certification

This information can be used as a preparation material for Sun certified Web Services Developer (SCDJWS) Certification. This book also provides sample test questions for the webservices test.
This article is prepared by Elango , IBM India.

## XML Web Service Standards
### Given XML documents, schemas, and fragments determine whether their syntax and form are correct (according to W3C schema) and whether they conform to the WS-I Basic Profile 1.0a

Basic Profile Final Specification

#### XML

A simple XML document
BP states that the encoding of XML document should be either utf-8 or utf-16
BP R1010 A RECEIVER MUST accept messages that contain an XML Declaration.
CDATA Section
CDATA section is used to escape the interpretation of the text by XML parsers. XML Parsers treat certain characters as special characters, like <, >, & ....
If you want parsers to treat this text as simple text, then we can use CDATA Sections.
Example: < DTD
DTD is a document which defines the structure of an XML document class.
BP R1008 A MESSAGE MUST NOT contain a Document Type Declaration.
Processing Instruction
BP R1009 A MESSAGE MUST NOT contain Processing Instructions

#### Schema

It describes the format of the XML document.

### Describe the use of XML schema in J2EE Web services.

XML schema is used to validate an XML document. Unlike DTDs it is a XML file so it is not required to learn a new language to define a rule. The schema defines a set of rules for a XML file. While we use JAXB we give the schema as input to the binding compiler. Then the binding compiler will generate the required interface to parse the XML document.

### Describe the use of namespaces in an XML document.
## SOAP 1.1 Web Service Standards

SOAP is a lightweight XML based protocol for exchanging information in a decentralized, distributed environment. It consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.
SOAP 1.1 is supported by BP (Basic Profile) 1.0 and SOAP 1.2 will be supported in BP1.1
SOAP supports two types of communication styles.
* Document
* RPC

### List and describe the encoding types used in a SOAP message

SOAP messages can be encoded in four different types. Encoding is the process in which the attributes convey information about how contents of a particular element are encoded. The encodings supported by SOAP are
* SOAP encoding: The sender and the receiver may not share the same schema. Indeed there are chances where the sender and the receiver may be applications that do not deal with XML at all, in case of which the SOAP architecture will be laid waste. To over come this drawback, the SOAP specifications has its own schema and rules for converting application-level data into a form suitable for embedding into SOAP messages.This is known as SOAP encoding. http://www.w3.org/2002/06/soap-encoding
* SOAP Literal:Instead of encoding header or body content according to the SOAP Data Model, we simply encode according to the rules and constraints of our data model and schema. In essence, we can just slide our own XML documents into a SOAP message, providing we remember to specify the encodingStyle attribute (and of course ensuring that the intended recipients of the message can understand it). This style of SOAP encoding is known as literal style.Some applications already deal with xml natively, that are currently xml based vocabularies. SOAP can take advantage of the pre-existing schema, to craft message exchange. This encourages coarser-grained model(You can send all the data in the xml file get the processing done at a single stretch and get the process done at the recipients end and expect the recipient to take some time and send back the complete answer) compared with RPC's fine-grained model(we send a bit of data and get a little bit back, and you make further calls until your business is completed).
SOAP implementations like Apache SOAP 2.3/Axis support other encodings like Literal/XML and XMI.
There are two styles of communicating a SOAP message. 1) Document 2) RPC
* Document: Document-style SOAP refers a way in which an application payload is hosted by the SOAP body element. When we use a document style it mean we place the document directly as a child to the soap:body element
<soap:body>
</soap:body>
* RPC: RPC-style wraps the application content inside an element which can be used to indicate the name of a method to dispatch the content to.
<soap:body>
</soap:body>
Combining the communication styles and encodings we have majorly the following messaging modes.
* Document/Literal
* RPC/Literal
* Document/Encoded
* RPC/Encoded.
Only Document/Literal and RPC/Literal are supported in Basic Profile 1.0. According to WS-I standard Document/Literal is the only one standard which is approved.

### Describe how SOAP message header blocks are used and processed

The SOAP header space is where much of the value in Web services resides, since it is here that aspects like security, transactions, routing, and so on are expressed. Every Web services standard has staked its claim on some part of the SOAP header territory, but in a mutually compatible way. The fact that SOAP headers are extensible enough to support such diverse standards is a major win, since it supports flexible protocol composition tailored to suit specific application domains.
A SOAP header has the local name Header associated with the http://www.w3.org/2002/06/soap-envelope namespace. It may also contain any number of namespace qualified attributes and any number of child elements, known as header blocks. In the absence of any such header blocks, the Header element itself may be omitted from the Envelope.
Header Attributes
* Encoding Style: If present, each header block must be namespace qualified (according to the rules set out in the SOAP schema), may specify how it has been encoded (i.e., which schema constrains it) through the encodingStyle attribute.The encodingStyle attribute is used to declare how the contents of a header block were created. Knowing this information allows a recipient of the header to decode the information it contains. SOAP allows many encoding schemes and provides one of its own as an optional part of the spec.
* Role: It may specify its consumer through the role attribute. The role attribute contains a URI that identifies the role being played by the intended recipient of its header block. The SOAP node receiving the message containing the header block must check through the headers to see if any of the declared roles are applicable. If there are any matches, the header blocks must be processed or appropriate faults generated.
* MustUnderstand: It may demand that it is understood by SOAP infrastructure that encounters its message through the mustUnderstand attribute.If the mustUnderstand attribute is set to true, it implies that any SOAP infrastructure that receives the message containing that header block must be able to process it correctly or issue an appropriate fault message. Those header blocks that contain the mustUnderstand="true" attribute are known as mandatory header blocks since they must be processed by any nodes playing the matching roles. Header blocks missing their mustUnderstand attribute should still be examined by nodes that play the appropriate role. If a failure to act on a role occurs, it is not deemed to be critical and further processing may occur since by missing the mustUnderstand attribute they are not considered mandatory
The SOAP specification stipulates that it is illegal for the role and mustUnderstand attributes to appear anywhere other than in header block declarations.

### Describe the function of each element contained in a SOAP message, the SOAP binding to HTTP, and how to represent faults that occur when processing a SOAP message.
#### Fault

The SOAP Fault is a reserved element predefined by the SOAP specification whose purpose is to provide an extensible mechanism for transporting structured and unstructured information about problems that have arisen during the processing of SOAP messages or subsequent application execution. Since the fault mechanism is predefined by the SOAP specification, SOAP toolkits are able to use this mechanism as a standard mechanism for distributed exception handling.
The SOAP Fault element belongs to the same namespace as the SOAP Envelope and contains two mandatory child elements: Code and Reason, and three optional elements: Node, Role, and Detail.
Code: The first child element of the Fault is the Code element, which contains two subelements: a mandatory element called Value and an optional element called Subcode. The Value element can contain any of a small number of fault codes as qualified names (sometimes abbreviated to QName) from the http://www.w3.org/2002/06/soap-envelope namespace.
FaultCode and Description
* VersionMismatch: Occurs when SOAP infrastructure has detected mutually incompatible implementations based on different versions of the SOAP specification.
* MustUnderstand: Issued in the case where a SOAP node has received a header block has with its mustUnderstand attribute set to true, but does not have the capability to correctly process that header block - that is, does not understand the protocol with which that header block is associated.
* DataEncodingUnknown: Arises when the content of either a header or body block is encoded according to a schema that the SOAP node reporting the fault does not understand.
* Sender: Occurs when the sender propagated a malformed message, including messages with insufficient data to enable the recipient to process it. It is an indication that the message is not to be resent without change.
* Receiver: Generated when the recipient of the SOAP message could not process the message content because of some application failure. Assuming the failure is transient, resending the message later may successfully invoke processing.
Subcode: Though it isn't used in this fault, the Subcode element also makes the SOAP fault mechanism extensible. Like the Code element, the Subcode element also contains a mandatory Value child element and an optional Subcode element, which may contain further nested Subcode elements. The Value element of any Subcode contains a qualified name that consists of a prefix and a local name
Reason: The Reason element associated with a Code is used to provide a human readable explanation of the fault, which in example below tells us that "The specified account does not exist at this branch". SOAP toolkits often use the contents of the Reason element when throwing exceptions or logging failures to make debugging easier. However, the Reason element is strictly meant for human consumption and it is considered bad practice to use its content for further processing.
Ex: <env:Reason lang="en-UK">The specified account does exist at this branch</env:Reason>
Node: The optional Node element provides information on which node in the SOAP message's path caused the fault. The content of the Node element is simply the URI of the node where the problem arose.
Role: The Node element is complemented by the also optional Role element that provides information pertaining to what the failing node was doing at the point at which it failed. The Role element carries a URI that identifies the operation (usually some Web services standard) and that the party resolving the fault can use to determine what part of the application went wrong. Thus, the combination of Node and Role provides valuable feedback on exactly what went wrong and where.
Details: The SOAP Detail element, as recapped in example below, provides in-depth feedback on the fault if that fault was caused as a by-product of processing the SOAP Body.
Ex: <env:Detail>
</env:Detail>
Fault element defines four subelements. BP1.0 allows only the following four elements. But the SOAP 1.1 allows any subelements to fault provided the elements are qualified with namespace.
* faultcode This is a mandatory element in fault element.
* faultstring This is a mandatory element in fault element.
* faultactor This is an optional element in fault element.
* detail This is an optional element in fault element.Detail element is intended to notify the errors related to the Body content of the message. This element should not be used to notify the errors related to header elements. This element is intended to report any application specific error information.
SOAP 1.1 messages are delivered using HTTP Post and HTTP reply. As HTTP Get does not support payload, HTTP Post is used to transfer the messages (SOAP messages are included as payload to HTTP Post requests).

### Describe the function of SOAP in a Web service interaction and the advantages and disadvantages of using SOAP messages.
## Describing and Publishing (WSDL and UDDI)
### Explain the use of WSDL in Web services, including a description of WSDL's basic elements, binding mechanisms and the basic WSDL operation types as limited by the WS-I Basic Profile 1.0a

WSDL stands for Web Services Description language. A Web Service client has to know how to call a Web Service, what parameters to send and what messaging mode to use. A Web Service can describe itself in WSDL and publish it so that the clients can understand how to call and use the Web Service. With WSDL there are several other benefits like a SOAP Implementation vendor(Provider) can automate the process of creating stubs and interfaces required for the client to communicate with the Web Service.
Most J2EE Vendors provide a way to create the WSDL documents automatically by looking in the Web Service implementations.
With WSDL you can describe the Web Service.
* Describe the endpoint interface.
* Describe the operations supported by the endpoint and their signature.
* Address of the Web Service.
* Communication mechanism.
WSDL Basic Elements:
* import
* types
* message
* portType
* operation
* binding
* service