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 &lt;, &gt;, &amp; ...
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.
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.
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 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
&lt;soap:body&gt;
 &lt;inv:invoice ...&gt;
 &lt;inv:orderNo...&gt;
 &lt;/inv:invoice&gt;
&lt;/soap:body&gt; 
&lt;soap:body&gt;
 &lt;m:purchase&gt;
 &lt;inv:invoice ...&gt;
 &lt;inv:orderNo...&gt;
 &lt;/inv:invoice&gt;
 &lt;/m:purchase&gt;
&lt;/soap:body&gt; 
Combining the communication styles and encodings we have majorly the following messaging modes.
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
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
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: &lt;env:Reason lang="en-UK"&gt;The specified account does exist at this branch&lt;/env:Reason&gt;
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:
&lt;env:Detail&gt;
 &lt;err:myfaultdetails
 xmlns:err= "http://bank.example.org/fault"&gt;
 &lt;err:invalid-account-sortcode&gt;
 &lt;bank:sortcode&gt;
 10-11-12
 &lt;/bank:sortcode&gt;
 &lt;bank:account&gt;
 12345678
 &lt;/bank:account&gt;
 &lt;/err:invalid-account-sortcode &gt;
 &lt;/err:myfaultdetails&gt;
&lt;/env:Detail&gt;
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.
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).
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.
WSDL Basic Elements:
Describe the use of UDDI data structures. Consider the requirements imposed on UDDI by the WS-I Basic Profile 1.0a.
&lt;li&gt;businessEntity
&lt;li&gt;businessService
&lt;li&gt;bindingTemplate
&lt;li&gt;tmodel
&lt;li&gt;publisherAssertion
&lt;br&gt;
UDDI represents Web service instances as uddi:bindingTemplate elements. The uddi:bindingTemplate plays a role that is the rough analog of the wsdl:port, but provides options that are not expressible in WSDL. To keep the WSDL description of an instance and its UDDI description consistent, the Profile places the following constraints on how uddi:bindingTemplate elements may be constructed.
WSDL's soapbind:address element requires the network address of the instance to be directly specified. In contrast, UDDI V2 provides two alternatives for specifying the network address of instances it represents. One, the uddi:accessPoint, mirrors the WSDL mechanism by directly specifying the address. The other, the uddi:hostingRedirector, provides a Web service-based indirection mechanism for resolving the address, and is inconsistent with the WSDL mechanism.
R3100 REGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element. 
UDDI represents Web service types as uddi:tModel elements. (See UDDI Data Structures section 8.1.1.) These may, but need not, point (using a URI) to the document that contains the actual description. Further, UDDI is agnostic with respect to the mechanisms used to describe Web service types. The Profile cannot be agnostic about this because interoperation is very much complicated if Web service types do not have descriptions or if the descriptions can take arbitrary forms.
The UDDI API Specification, appendix I.1.2.1.1 allows but does not require uddi:tModel elements that use WSDL to describe the Web service type they represent to state that they use WSDL as the description language. Not doing so leads to interoperability problems because it is then ambiguous what description language is being used.
Therefore the Profile places the following constraints on how uddi:tModel elements that describe Web service types may be constructed:
The Profile chooses WSDL as the description language because it is by far the most widely used such language.
R3002 REGDATA of type uddi:tModel representing a conformant Web service type MUST use WSDL as the description language.
To specify that conformant Web service types use WSDL, the Profile adopts the UDDI categorization for making this assertion.
R3003 REGDATA of type uddi:tModel representing a conformant Web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec".
For the uddi:overviewURL in a uddi:tModel to resolve to a wsdl:binding, the Profile must adopt a convention for distinguishing among multiple wsdl:bindings in a WSDL document. The UDDI Best Practice for Using WSDL in a UDDI Registry specifies the most widely recognized such convention.
R3010 REGDATA of type uddi:tModel representing a conformant Web service type MUST follow V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry.
It would be inconsistent if the wsdl:binding that is referenced by the uddi:tModel does not conform to the Profile.
R3011 The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST itself conform to the Profile.
Describe the basic functions provided by the UDDI Publish and Inquiry APIs to interact with a UDDI business registry..
Publish:
&lt;li&gt;save_business
&lt;li&gt;save_service
&lt;li&gt;save_binding
&lt;li&gt;save_tmodel
&lt;li&gt;delete_business
&lt;li&gt;delete_service
&lt;li&gt;delete_binding
&lt;li&gt;delete_tmodel
&lt;br&gt;
&lt;li&gt;get_authtoken
&lt;li&gt;discard_token
&lt;br&gt;
&lt;br&gt;
Inquiry:
&lt;br&gt;
&lt;br&gt;
&lt;li&gt;find_business
&lt;li&gt;get_businessdetail
&lt;li&gt;find_service
&lt;li&gt;get_servicedetail
&lt;li&gt;find_binding
&lt;li&gt;get_bindingdetail
&lt;li&gt;find_tmodel
&lt;li&gt;get_tmodeldetail
JAX-RPC.
Explain the service description model, client connection types, interaction modes, transport mechanisms/protocols, and endpoint types as they relate to JAX-RPC.
The following material is based on JAX-RPC 1.1 Spec.
JAX-RPC is Java API for XML based Remote Procedure Call mechanism. JAX-RPC supports any kind of protocol which is based on XML Infosets. JAX-RPC is independent of any communication protocol like SOAP(which is an XML based protocol using XML Infosets). JAX-RPC is also independent of any transport protocol like HTTP, SMTP.
But some aspects are more biased towards WebServices technologies like SOAP and WSDL. So may be that's the reason why the named the new version of JAX-RPC as JAX-WS(Java API for XML based WebServices). JAX-WS 2.0 is updated version of JAX-RPC 1.1.
URL for JAX-WS http://www.jcp.org/en/jsr/detail?id=224
Service description model
JAXR-RPC 1.1 specifies programming model for a service endpoint developed and deployed on a Servlet container based JAX-RPC runtime system.
Client connection types
There can be three types of client,
Interaction modes
The following are the application interaction modes supported by JAX-RPC, the JAX-RPC providers may use any kind of low-level interaction modes to support the Application interaction modes.
In this mode the service client makes a request and waits(the current thread executing the request) for the response from the server. The JAX-RPC APIs and service client programming model supports this mode through both the stub(or dynamic proxy) based model and DII Call interface.
In this mode the service client invokes a remote method and continues without waiting for the response from the service endpoint. The service client does not get any response(either return values or remote exceptions) from the Service endpoint. The JAX-RPC supports this one-way mode through DII Call interface.
In this mode the service client thread invokes a remote method and continues processing without waiting for response. It later processes the response by performing blocking receive. The JAX-RPC runtime does not need to support this mode.
Transport mechanisms/protocols
Endpoint types
There are two types of endpoints,
Explain the advantages and disadvantages of a WSDL to Java vs. a Java to WSDL development approach..
WSDL to Java
Java to WSDL
SOAP and XML Processing APIs (JAXP, JAXB, and SAAJ).
Describe the functions and capabilities of the APIs included within JAXP.
JAXP.
JAXP, Java API for XML Processing leverages the XML Parsers SAX and DOM. It also provides the support for XSL transformations.
SAX is an event based parser model.
DOM builds an Object representation of XML.
JAXP API which is packaged in javax.xml.parsers provides implementation independent interfaces to use SAX, DOM and XSL Transformers.
It provides this by using Factory Design Pattern.
xml packages
javax.xml.parsers
It provides the implementation independent classes for accessing the Parsers.
You can define which concrete implementation to use by setting the System properties using System.setProperty or by setting them as JVM parameters using -DpropertyName=propertyValue. If we don't define the properties, it uses the Sun's implementation.
SAX.
SAX parser is an event based serial parser, in the sense it reads the given XML document line-by-line (serially) and generates event when it comes across the XML elements.
SAX packages
SAX is based mainly on two interfaces, XMLReader and ContentHandler
XMLReader is the xml parser(which is a replacement for Parser of SAX1 model) which reads the XML document and calls the event callback methods of the ContentHandler. org.xml.sax.Parser is used in SAX1 model.
XMLReader has two new functionalities
Instantiating a parser factory implementation using JAXP is done using
The above instantiation is independent of the implementation.
For example, Xerces-J from Apache is an implementation of SAX.
Using Xerces-J we can instantiate using
But by using JAXP, we get independence from the vendor specific API.
Simple SOAP message parser
Lets look at a simple example of the whole story around using SAX..
The following presents a simple example parser(SAXTest.java) which reads a SOAP message (SOAPMessage.xml) and uses DefaultHanlder(SOAPMessageHandler.java). 
Simple SOAP Message(SOAPMessage.xml)
Sample code to read the SOAPMessage.xml using SAX model
A simple Handler which extends DefaultHandler, which prints a debug message when the callback method is invoked.
SAXParser
SAXParser is a wrapper class for the org.xml.sax.XMLReader. As the content is parsed by the SAXParser implementation it invokes the callback methods of the HandlerBase or DefaultHandler.
SAXParser several overloaded methods for parsing
Note: Some of the API documentation is taken directly from the Sun API Documentation.
the parse methods have mainly two input parameters,
Validation 
Namespace Awareness
Setting and Getting properties
Handlers
As the SAXParser parses the document it will call the callback methods of the handler classes. The Handler class implementations must register with the SAXParser before receiving notifications.
There are four types of Handlers (interfaces)
org.xml.sax.ContentHandler
As the SAXParser parses the XML document it will call the methods of registered ContentHandler. ContentHanlder has callback methods for major events in parsing like startDocument(), endDocument(), startElement, endElement, processingInstruction, characters.
org.xml.sax.EntityResolver
This has only method
The Parser will call this method before opening any external entity except the top-level document entity.
org.xml.sax.DTDHandler
org.xml.sax.ErrorHandler
The SAXParser invokes the methods of ErroHandler implementation as it gets XML Processing errors, rather than throwing the exceptions itself.
it has the following methods.
Use the SAAJ APIs to create and manipulate a SOAP message.
The following documentation is based on SAAJ 1.2
SAAJ - SOAP with attachments API for Java
SAAJ can be used to create, read, update and send SOAP messages. The API is standalone, in the sense that it can be used within and without the JAX-RPC context.
javax.xml.soap is the package which holds all the SAAJ API. 
MessageFactory is the main abstract class where we start creating the SOAPMessages. MessageFactory is implemented by the SAAJ vendors. For example, in Axis the MessageFactory is implemented by org.apache.axis.soap.MessageFactoryImpl
newInstance() creates a new instance of the MessageFactory.
createMessage() is used to create SOAPMessage object, usually used to create new SOAP request messages.
createMessage(MimeHeader mimeHeaders, InputStream in) creates a SAAJ SOAPMessage model (DOM) from an existing SOAP message.
As SAAJ supports Attachments with SOAP messages, a SAAJ SOAPMessage object contains one SOAPPart object and one or more AttachmentPart objects.
The following class diagram provides the overview of the major components.
JAXR.
Describe the function of JAXR in Web service architectural model, the two basic levels of business registry functionality supported by JAXR, and the function of the basic JAXR business objects and how they map to the UDDI data structures..
 JAXR is Java API for XML Registries. JAXR API to registries is similar to JDBC API for databases. JAXR API provides common interface to communicate with different registries instances (even different registry models).
JAXR Provider is the vendor who provides the JAXR API Specification implementation. There are several Registry models, out of which JAXR specifies to only UDDI and ebXML registries.
 JAXR API is divided into two main packages (components), one javax.xml.registry contains API to provide Query and LifeCycleManagement API for registries and javax.xml.registry.infomodel provides business objects which are similar to the objects maintained by the registries. JAXR infomodel is the confluence of the object models from both ebXML and UDDI registries.
 JAXR Specification does not mandate JAXR Providers to implement support for all API(or Registries). The Spec divided the API into Capability Levels. Capability Level 0 means support for UDDI registries and Capability Level 1 means support for ebXML registries. JAXR Spec requires the Provider to implement alteast Capability Level 0(support for UDDI).
Use JAXR to connect to a UDDI business registry, execute queries to locate services that meet specific requirements, and publish or update information about a business service..
kkk
References.
Basic Profile
SCDJWS Objectives
Java APIs for XML Messaging 1.0
Java API for XML Registries 1.0 (JAXR)
Java APIs for XML based RPC 1.1
Implementing Enterprise Web Services 
OCE for Java EE Web Services Preparation Article 
SCDJWS 5 Preparation Article 
SOAP.
SOAP
WSDL.
WSDL Schema 1.1