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

<addresses>
  <address> 
  </address>
</addresses>

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>

<inv:invoice ...>
 <inv:orderNo....>
</inv:invoice>

</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>

<m:purchase>
 <inv:invoice ...>
  <inv:orderNo....>
 </inv:invoice>
</m:purchase>

</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>

 <err:myfaultdetails
   xmlns:err= "http://bank.example.org/fault">
   <err:invalid-account-sortcode>
     <bank:sortcode>
       10-11-12
     </bank:sortcode>
     <bank:account>
       12345678
     </bank:account>
   </err:invalid-account-sortcode >
 </err:myfaultdetails>

</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).

Create a SOAP message that contains an attachment (Example).

Describe the restrictions placed on the use of SOAP by the WS-I Basic Profile 1.0a.

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

Describe how W3C XML Schema is used as a typing mechanism in WSDL 1.1

Describe the use of UDDI data structures. Consider the requirements imposed on UDDI by the WS-I Basic Profile 1.0a

businessEntity

businessService

bindingTemplate

tmodel

publisherAssertion

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:

save_business

save_service

save_binding

save_tmodel

delete_business

delete_service

delete_binding

delete_tmodel

get_authtoken

discard_token

Inquiry:

find_business

get_businessdetail

find_service

get_servicedetail

find_binding

get_bindingdetail

find_tmodel

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,

Static Stub based client
Proxy Client
DII

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.

Synchronous Request Response Mode

Request-Response Mode

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.

One-way RPC Mode

JAX-RPC One Way Application Interaction mode

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.

Non-blocking RPC Invocation

JAX-RPC Non-blocking application interaction mode

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

Protocol will be SOAP (Simple Object Access Protocol)
Transport can be HTTP / JMS

Endpoint types There are two types of endpoints,

Servlet Based Endpoints
EJB based Endpoints (JAX-RPC spec does not specify. R08 p24)

Given a set of requirements for a Web service, such as transactional needs, and security requirements, design and develop Web service applications that use servlet-based endpoints and EJB based endpoints.

Given an set of requirements, design and develop a Web service client, such as a J2EE client and a stand-alone Java client, using the appropriate JAX-RPC client connection style.

Given a set of requirements, develop and configure a Web service client that accesses a stateful Web service.

Explain the advantages and disadvantages of a WSDL to Java vs. a Java to WSDL development approach.

WSDL to Java

Java to WSDL

Advantages

Disadvantages
- Java supports inheritance for Interfaces(Service Endpoint Interface) which can not be directly translated in to WSDL definitions(which does not have inheritance concept for portType definitions).

Describe the advantages and disadvantages of web service applications that use either synchronous/request response, one-way RPC, or non-blocking RPC invocation modes.

Use the JAX-RPC Handler API to create a SOAP message handler, describe the function of a handler chain, and describe the role of SAAJ when creating a message handler.

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 - which provides an implementation independent API for using SAX, DOM and XSL Transformers.
org.w3c.dom - API using Document Object model for parsing XML.
org.xml.sax - API for event based XML parsing model.
javax.xml.transform - XSLT APIs which are used to transform XML documents in to different formats(XML, HTML..)

javax.xml.parsers It provides the implementation independent classes for accessing the Parsers.

javax.xml.parsers.SAXParserFactory
javax.xml.parsers.DocumentBuilderFactory
javax.xml.transform.TransformerFactory

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

org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers

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

it adds a standard way to query and set features and properties
it adds Namespace support

Instantiating a parser factory implementation using JAXP is done using

  SAXParserFactory factory = SAXParserFactory.newInstance();
  SAXParser parser = factory.newSAXParser();

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

  SAXParserFactory factory = new org.apache.xerces.jaxp.SAXParserFactoryImpl();
  SAXParser parser = factory.newSAXParser();

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)

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<getProductDetails xmlns="http://www.javaspirit.com/pr">
			<productID>827635</productID>
		</getProductDetails>
	</soap:Body>
</soap:Envelope>

Sample code to read the SOAPMessage.xml using SAX model

package com.javaspirit.tutorial.sax;

import java.io.IOException;
import java.io.InputStream;

import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;

import org.apache.log4j.Logger;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;

public class SAXTest {
    
    private static final Logger logger = Logger.getLogger(SAXTest.class);
    
    public static void main(String[] args) {
        
        // Gets the SAXParserFactory implementation
        // In this case we get org.apache.xerces.jaxp.SAXParserFactoryImpl
        // We configure this using the JVM property 
        // -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

        SAXParserFactory factory = SAXParserFactory.newInstance();
        
        if(logger.isDebugEnabled()) logger.debug(factory.getClass());
        
        SAXParser parser;
        
        try {
            
            // We get Xerces implementation of SAXParser which is org.apache.xerces.jaxp.SAXParserImpl
            parser = factory.newSAXParser();
            
            if(logger.isDebugEnabled()) logger.debug(parser.getClass());
            
            DefaultHandler handler = new SOAPMessageHander();
            
            // Read the SOAPMessage.xml ( which contains a simple SOAP Message )
            InputStream in = Thread.currentThread().getContextClassLoader()
                    .getResourceAsStream(
                            "com/javaspirit/tutorial/sax/SOAPMessage.xml");
            
            // Register the DefaultHandler with the parser/
            // The SAXParser will invoke the callback methods defined by the DefaultHandler
            parser.parse(in, handler);
            
        } catch (ParserConfigurationException e) {
            e.printStackTrace();
        } catch (SAXException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        
    }
}

A simple Handler which extends DefaultHandler, which prints a debug message when the callback method is invoked.

package com.javaspirit.tutorial.sax;

import org.apache.log4j.Logger;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;

public class SOAPMessageHander extends DefaultHandler{
    
    private static final Logger logger = Logger.getLogger(SOAPMessageHander.class);
    
    /* (non-Javadoc)
     * @see org.xml.sax.ContentHandler#startElement(java.lang.String, java.lang.String, java.lang.String, org.xml.sax.Attributes)
     */
    public void startElement(String uri, String localName, String qName,
            Attributes attributes) throws SAXException {
        logger.debug("in startElement() method");
        super.startElement(uri, localName, qName, attributes);
    }
    
    /* (non-Javadoc)
     * @see org.xml.sax.ContentHandler#endElement(java.lang.String, java.lang.String, java.lang.String)
     */
    public void endElement(String uri, String localName, String qName)
            throws SAXException {
        logger.debug("in endElement() method");
        super.endElement(uri, localName, qName);
    }

}

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.

 void 	parse(File f, DefaultHandler dh)
          Parse the content of the file specified as XML using the specified DefaultHandler.
 void 	parse(File f, HandlerBase hb)
          Parse the content of the file specified as XML using the specified HandlerBase.
 void 	parse(InputSource is, DefaultHandler dh)
          Parse the content given InputSource as XML using the specified DefaultHandler.
 void 	parse(InputSource is, HandlerBase hb)
          Parse the content given InputSource as XML using the specified HandlerBase.

the parse methods have mainly two input parameters,

source - source of the XML document, the possible sources are File, InputStream, String
hanlder - HandlerBase or DefaultHandler ( or their subclasses)

Validation

abstract  boolean 	isValidating()
          Indicates whether or not this parser is configured to validate XML documents.

Namespace Awareness

abstract  boolean 	isNamespaceAware()
          Indicates whether or not this parser is configured to understand namespaces.

Setting and Getting properties

abstract  void 	setProperty(String name, Object value)
          Sets the particular property in the underlying implementation of XMLReader.
abstract  Object 	getProperty(String name)
          Returns the particular property requested for in the underlying implementation of XMLReader.

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

InputSource 	resolveEntity(String publicId, String systemId)

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.

 void 	error(SAXParseException exception)
          Receive notification of a recoverable error.
 void 	fatalError(SAXParseException exception)
          Receive notification of a non-recoverable error.
 void 	warning(SAXParseException exception)
          Receive notification of a warning.

Given a scenario, select the proper mechanism for parsing and processing the information in an XML document

Describe the functions and capabilities of JAXB, including the JAXB process flow, such as XML-to-Java and Java-to-XML, and the binding and validation mechanisms provided by JAXB.

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

public abstract class MessageFactory {
    public static MessageFactory newInstance() throws SOAPException {
        // Implementation
    }

    public abstract SOAPMessage createMessage() throws SOAPException;

    public abstract SOAPMessage createMessage(
        MimeHeaders mimeheaders, InputStream inputstream)
        throws IOException, SOAPException;
}

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.

SOAP API Overview

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

J2EE Web Services

Identify the characteristics of and the services and APIs included in the J2EE platform.

Explain the benefits of using the J2EE platform for creating and deploying Web service applications.

Describe the functions and capabilities of the JAXP, DOM, SAX, JAXR, JAX-RPC, and SAAJ in the J2EE platform.

Describe the role of the WS-I Basic Profile when designing J2EE Web services.

Security

Explain basic security mechanisms including: transport level security, such as basic and mutual authentication and SSL, message level security, XML encryption, XML Digital Signature, and federated identity and trust.

Transport Level security

Message Level security

Identify the purpose and benefits of Web services security oriented initiatives and standards such as Username Token Profile, SAML, XACML, XKMS, WS-Security, and the Liberty Project.

Given a scenario, implement J2EE based web service web-tier and/or EJB-tier basic security mechanisms, such as mutual authentication, SSL, and access control. =

Describe factors that impact the security requirements of a Web service, such as the relationship between the client and service provider, the type of data being exchanged, the message format, and the transport mechanism.

Developing Web Services

Describe the steps required to configure, package, and deploy J2EE Web services and service clients, including a description of the packaging formats, such as .ear, .war, .jar, deployment descriptor settings, the associated Web services description file, RPC mapping files, and service reference elements used for EJB and servlet endpoints.

Given a set of requirements, develop code to process XML files using the SAX, DOM, XSLT, and JAXB APIs.

Given an XML schema for a document style Web service create a WSDL file that describes the service and generate a service implementation.

Given a set of requirements, develop code to create an XML-based, document style, Web service using the JAX-RPC APIs.

Implement a SOAP logging mechanism for testing and debugging a Web service application using J2EE Web Service APIs.

Given a set of requirements, develop code to handle system and service exceptions and faults received by a Web services client.

General Design and Architecture

Describe the characteristics of a service oriented architecture and how Web services fits to this model.

Given a scenario, design a J2EE service using the business delegate, service locator, and/or proxy client-side design patterns and the adapter, command, Web service broker, and/or faade server-side patterns.

Describe alternatives for dealing with issues that impact the quality of service provided by a Web service and methods to improve the system reliability, maintainability, security, and performance of a service.

Describe how to handle the various types of return values, faults, errors, and exceptions that can occur during a Web service interaction.

Describe the role that Web services play when integrating data, application functions, or business processes in a J2EE application.

Describe how to design a stateless Web service that exposes the functionality of a stateful business process.

Endpoint Design and Architecture

Given a scenario, design Web service applications using information models that are either procedure-style or document-style.

Describe the function of the service interaction and processing layers in a Web service.

Describe the tasks performed by each phase of an XML-based, document oriented, Web service application, including the consumption, business processing, and production phases.

Design a Web service for an asynchronous, document-style process and describe how to refactor a Web service from a synchronous to an asynchronous model.

Describe how the characteristics, such as resource utilization, conversational capabilities, and operational modes, of the various types of Web service clients impact the design of a Web service or determine the type of client that might interact with a particular service.

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

WSDL

WSDL Schema 1.1