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.

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.

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

      
 * 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.

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.

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: The specified account does exist at this branch

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

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 the use of UDDI data structures. Consider the requirements imposed on UDDI by the WS-I Basic Profile 1.0a
<li>businessEntity <li>businessService <li>bindingTemplate <li>tmodel <li>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:

<li>save_business <li>save_service <li>save_binding <li>save_tmodel <li>delete_business <li>delete_service <li>delete_binding <li>delete_tmodel <li>get_authtoken <li>discard_token Inquiry: <li>find_business <li>get_businessdetail <li>find_service <li>get_servicedetail <li>find_binding <li>get_bindingdetail <li>find_tmodel <li>get_tmodeldetail

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

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.
 * One-way RPC 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.
 * Non-blocking RPC Invocation

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. ===

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

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.

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.



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

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. ===

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. ===

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. ===

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. ===

SOAP
SOAP

WSDL
WSDL Schema 1.1