Java_XML_faqs

GENERAL

Q. What is XML?

A. XML, the Extensible Markup Language, is a universal syntax for describing and structuring data independent from the application logic. XML can be used to define unlimited languages for specific industries and applications.

Q. Who developed XML?

A. XML is an activity of the World Wide Web Consortium (W3C). The XML development effort started in 1996.

A diverse group of markup language experts, from industry to academia, developed a simplified version of SGML (Standard Generalized Markup Language) for the Web. In February 1998, XML 1.0 specification became a recommendation by the W3C.

Q. What are the key benefits of XML?

A. XML promises to simplify and lower the cost of data interchange and publishing in a Web environment. XML is a text-based syntax that is readable by both computer and humans. XML offers data portability and reusability across different platforms and devices. It is also flexible and extensible, allowing new tags to be added without breaking an existing document structure. Based on Unicode, XML provides global language support.

Q. What are the applications of XML?

A. XML is poised to play a prominent role as a data interchange format in B2B Web applications such as e-commerce, supply-chain management, workflow, and application integration. Another use of XML is for structured information management, including information from databases. XML also supports media-independent publishing, allowing documents to be written once and published in multiple media formats and devices. On the client, XML can be used to create customized views into data.

Q. What is the relationship between XML and Java technology?

A. XML and the Java technology are complementary. Java technology provides the portable, maintainable code to process portable, reusable XML data. In addition, XML and Java technology have a number of shared features that make them the ideal pair for Web computing, including being industry standards, platform-independence, extensible, reusable, Web-centric, and internationalized.

Q. What are the benefits of using Java technology with XML?

A. Java technology offers a substantial productivity boost for software developers compared to programming languages such as C or C++. In addition, developers using the Java platform can create sophisticated programs that are reusable and maintainable compared to programs written with scripting languages. Using XML and Java together, developers can build sophisticated, interoperable Web applications more quickly and at a lower cost.

Q. What XML-related activities is Sun participating in?

A. Sun is actively participating in W3C working groups for XML Stylesheet/Transformation Language (XSL/T), XML Schema, Xlink, and XML Query. Sun is also participating in a number of other industry consortia including Oasis, XML.org, and Apache.

Q. Where can I find additional documentation?

A. The Java Technology & XML Documentation page has a comprehensive list of all documentation related to Java Technology and XML available on this website.

Q. Where can I send comments and suggestions?

A. For feedback on the project, please send email to xml-feedback@sun.com.

Q. Are there other Sun hosted XML mailing lists I can subscribe to?

A. For general discussion about topics related to XML technologies in the Java platform, subscribe to xml-interest@java.sun.com.




Java API for XML-Based Web Services (JAX-WS)

Q. What is the difference between JAX-RPC and JAX-WS?

A. One of the main differences between JAX-RPC and JAX-WS is the programming model.
A JAX-WS-based service uses annotations, such as @WebService, to declare web service endpoints.
Using these annotations obviates the need for deployment descriptors.
With JAX-WS, you can have a web service deployed on a Java EE-compliant application server without a single deployment descriptor.
JAX-WS also provides many additional features, such as asynchronous callback support. Refer to the JAX-WS specification for more information.

Q. Does the Java EE 5 platform support JAX-WS?

A. Yes, the Java EE 5 platform supports JAX-WS-based services (in addition to JAX-RPC-based services) and makes these services portable through JSR 109.

Q. Can a JAX-WS-based service and a JAX-RPC-based service co-exist?

A. Yes.

Q. How do I develop a simple JAX-WS-based service?

A. See this tip.

Q. Can a JAX-WS-based service that was developed and deployed on Java WSDP 2.0 be deployed and run on any Java EE 5-based platform?

A. No.

Q. How do I make my JAX-WS service that was developed and deployed on Java WSDP 2.0 portable across Java EE 5 platforms?

A. See this tip.

Q. Will a JAX-WS-based web service work with a JAX-RPC client and a JAX-RPC-based web service work with a JAX-WS client?

A. Yes.

Q. Can I have a JAX-WS web service with deployment descriptors?

A. Yes. The same deployment descriptors, such as webservices.xml, web.xml, and ejb-jar.xml, can be used, just as they were with JAX-RPC-based services. If a deployment descriptor is specified, the values specified in the annotation attributes will be overridden by the corresponding values specified in the deployment descriptors.

Q. Can the deployment descriptor values be overridden?

A. No.

Q. Do I have to specify all attributes for annotations?

A. No. Well-defined default values have been specified for all attributes of annotations.





Java API for XML Processing (JAXP)


Q. What is Java API for XML Processing (JAXP)?

The Java API for XML Processing, or "JAXP" for short, enables applications to parse and transform XML documents using an API that is independent of a particular XML processor implementation. JAXP also provides a pluggability feature which enables applications to easily switch between particular XML processor implementations.

To achieve the goal of XML processor independence, an application should limit itself to the JAXP API and avoid implementation-dependent APIs. This may or may not be easy depending on the application. JAXP includes industry standard APIs such as DOM and SAX.

The reason for the existance of JAXP is to facilitate the use of XML on the Java platform. For example, current APIs such as DOM Level 2 do not provide a method to bootstrap a DOM Document object from an XML input document, JAXP does. (When DOM Level 3 provides this functionality, a new version of the JAXP specification will probably support the new Level 3 scheme also.) Other parts of JAXP such as the javax.xml.transform portion do not have any other equivalent APIs that are XSLT processor independent.

Q. Where can I read more about JAXP?

A. See the JAXP FAQ for more information.




Java Architecture for XML Binding (JAXB)

Q. What is Java Architecture for XML Binding (JAXB)?

A. The Java Architecture for XML Binding (JAXB) simplifies the creation and maintenance of XML-enabled Java applications. JAXB provides a binding compiler and a runtime framework to support a two-way mapping between XML documents and Java objects. The binding compiler translates W3C XML Schema into one or more Java classes without requiring the developer to write complex parsing code. The schema-derived classes and binding framework enable error and validity checking of incoming and outgoing XML documents, thereby making it possible to ensure that only valid, error-free messages are accepted, processed, and generated by a system. For more information, see the Reference Implementation and the Public Draft Specification, both available for download from the JAXB homepage.

Q. What is the difference between JAXB, SAX, and DOM? Which one should I use?

A. SAX is an event-driven XML parser that is appropriate for high-speed processing of XML because it does not produce a representation of the data in memory. DOM, on the other hand, produces an in-memory data representation, which allows an application to manipulate the contents in memory. Both SAX and DOM automatically perform structure validation. An application could perform content validation with SAX and DOM, but such an application must provide the necessary extra code, which might be complicated, error-prone, and difficult to maintain.

A JAXB application can perform structure and content validation with Java classes that it generates from a schema. A JAXB application builds an in-memory data structure, like a DOM, by marshalling an XML document to build a content tree, which contains objects that are instances of the derived classes. However, unlike a DOM tree, a content tree is specific to one source schema, does not contain extra tree-manipulation functionality, allows access to its data with the derived classes' accessor methods, and is not built dynamically. For these reasons, a JAXB application uses memory more efficiently than a DOM application does. If the content of a document is more dynamic and not well-constrained, DOM and SAX are more appropriate than JAXB for processing XML content that does not have a well-known schema prior to processing the content.

Q. How does JAXB work?

A. To build a JAXB application, start with an XML schema. The beta release requires that the schema language be W3C 2001 Recommendation for XML Schema.


After obtaining an XML Schema, you build and use a JAXB application by performing these steps:

Generate the Java source files by submitting the XML Schema to the binding compiler.

You can use custom binding declarations to override the default binding of XML Schema components to Java representations

Compile the Java source code.

With the classes and the binding framework, write Java applications that:

Build object trees representing XML data that is valid against the XML Schema by either unmarshalling the data from a document or instantiating the classes you created.

Access and modify the data.

Optionally validate the modifications to the data relative to the constraints expressed in the XML Schema

Marshal the data to new XML documents.

Q. Who is involved in developing JAXB?

A. JAXB is being developed through the Java Community Process (JCP) with an expert group consisting of IBM, Software AG, BEA Systems, Hewlett-Packard, TIBCO Software Inc., Oracle, Fujitsu Limited, Breeze Factor LLC, Macromedia, Inc. and Intalio, Inc. Sun is an active member of the W3C XML Schema Working Group and is also working with other industry consortia such as OASIS and xml.org.

Q. Where can I read more about JAXB?

A. For a higher-level explanation of JAXB, refer to the JAXB chapters in the Java Web Services Tutorial. Also note that a detailed user's guide is included as part of the JAXB distribution. For a more technical and detailed description of JAXB, see the the latest version of the Specification, which you can download from the JAXB homepage. Please note that the Specification is in Adobe Acrobat PDF format. Download Adobe Acrobat for free.




Java API for XML Messaging (JAXM)

Q. What is the Java API for XML Messaging (JAXM)?

A: The Java API for XML Messaging (JAXM) is an API designed specifically for the exchange of XML business documents over the Internet. Examples of XML documents that might typically be exchanged are purchase orders, order confirmations, and invoices. You can send non-XML data by adding attachments to your message.

Q: What standards is JAXM based on?

A: JAXM is based on the Simple Object Access Protocol (SOAP) 1.1 and SOAP with Attachments specifications. JAXM also allows the implementation of standard protocols on top of the SOAP implementation, such as SOAP-RP or the ebXML Transport, Routing & Packaging V1.0 - Message Service Specification.

Q. Do I have to use the J2EE platform to use JAXM?

A: No, you are free to use the Java 2 Platform, Standard Edition (J2SE) as well as the Java 2 Platform, Enterprise Edition (J2EE). A stand-alone client (a client that does not use a messaging provider) can use the J2SE platform to send request-response messages to Web services that process request-response messages. This requires no deployment or configuration from the client, so it is easy to do.

Q. What is a messaging provider?

A: A messaging provider is a service that works with the messaging infrastructure to route and transmit messages. What it does is completely transparent to the client sending or receiving a message. An application that uses a messaging provider must use a connection that goes to the provider, called a ProviderConnection object in the JAXM API. Using a messaging provider also requires some deployment and configuration. Normally, a client using a messaging provider runs in a container -- either a servlet or a J2EE container. At deployment time, the client needs to give the container information about the messaging provider. In the future, there will be a deployment tool that makes this easy.

Q. Do I have to use a messaging provider?

A: No. You need to use a messaging provider only when your application requires one-way (asynchronous) messaging. In this type of messaging, a message is sent to a recipient as one operation, and the recipient responds at some later time in a different operation. If you application uses a request-response style of messaging, in which the response to a message is sent back as part of the same operation, you do not need a messaging provider. When you do not use a messaging provider, you use a SOAPConnection object, which supports the simpler request-response messaging model.

Q. Can a JAXM message be routed to more than one destination?

Yes. Intermediate recipients can be specified in a message's header. One way this capability can be used is to automate business processes. For example, two businesses can agree to the conditions under which they exchange XML documents so that they can implement the automatic generation of messages and responses. Assume that two businesses have an arrangement specifying that purchase orders will go first to the order entry department, then to the order confirmation department, then to the shipping department, and finally to the billing department. Each department is an intermediate recipient (called an actor). After an actor has done its part, it removes everything in the header that relates to it and sends the message on to the next actor listed in the header.

Q. Can I use ebXML headers in a JAXM message?

A: Yes, you can use ebXML headers if you use an ebXML profile that is implemented on top of SOAP. A profile is a standard protocol, such as ebXML TRP or SOAP-RP, that works on top of SOAP to give you added functionality. You need to use a messaging provider that supports the profile, and you need to arrange with your recipients to use the same profile.




Java API for XML Registries (JAXR)

Q. What is the Java API for XML Registries (JAXR)?

A. The Java API for XML Registries (JAXR) API provides a uniform and standard Java API for accessing different kinds of XML Registries. XML registries are an enabling infrastructure for building, deployment, and discovery of Web services.

Q. What is the relationship between the JAXR API and other XML APIs?

A. Implementations of JAXR providers may use the Jav API for XML-Based RPC (JAX-RPC) for communication between JAXR providers and registry providers that export a SOAP based RPC-like interface (for example, UDDI).

Implementations of JAXR providers may use the Java API for XML Messaging (JAXM) API for communication between JAXR providers and registry providers that export an XML Messaging-based interface (for example, ebXML TRP).

The Java API for XML Processing (JAXP) and Java Architecture for XML Binding (JAXB) may be used by implementers of JAXR providers and JAXR clients for processing XML content that is submitted to or retrieved from the Registry.

Q. Why do we need a new JAXR API when we have the Java Naming and Directory Interface (JNDI)?

A. The JNDI API was designed with a very different set of requirements from the JAXR API. Both are abstraction APIs over existing specifications. However, the abstraction in directory services differs considerably from that of XML Registries used for publishing and discovery of Web services. The JAXR API needs richer metadata capabilities for classification and association, as well as richer query capabilities.

Q. Would it not be better to have enhanced the JNDI API with the added functionality of the JAXR API?

A. That option was considered. Meeting the additional requirements of XML Registries requires an elaborate information model. The JNDI API has an existing information model that is constrained by design to address the requirements for directory services. Extending the JNDI API would overly constrain the JAXR API and would create backward compatibility issues for the JNDI API.

Q. What is the purpose of Association in the JAXR information model? It is not used anywhere in the API.

A. An Association relates two RegistryObjects to each other. An Association may be defined between two objects in the registry and submitted using the GenericLifeCycleManager's saveObjects method.

Q. What is the purpose of Classification in the JAXR information model? It is not used anywhere in the API.

A. A Classification classifies a RegistryObject. A Classification may be defined for a RegistryObject and submitted using the GenericLifeCycleManager's saveObjects method.

Q. Why is JAXR an abstraction API and not targeted to a specific registry such as UDDI or ebXML?

A. An abstraction-based JAXR API gives developers the ability to write registry client programs that are portable across different target registries. This is consistent with the Java philosophy of Write Once, Run Anywhere. It also enables value-added capabilities beyond what the underlying registries are capable of. For example, a non-JAXR UDDI client does not have the ability to do taxonomy browsing and taxonomy-aware smart queries, which are available to a JAXR client for UDDI.

Q. Why does the JAXR API not use UDDI terms and concepts?

A. The JAXR API is not specific to UDDI or any other registry specification. It is an abstraction API that covers multiple specifications. It is designed to enable developer choice in the use of a Web service registry and/or repository. The JAXR API uses UDDI terms and concepts when they fit the JAXR information model (for example, Service, ServiceBinding, and method names in BusinessQueryManager and BusinessLifeCycleManager).

Q. Why did the JAXR information model use the ebXML Registry Information Model as its basis rather than the UDDI data structures?

A. The JAXR API is designed to support multiple registries. The ebXML Registry Information Model is more generic and extensible than the UDDI data structures. Because of this characteristic, it was possible to extend the ebXML Registry Information Model to satisfy the needs of UDDI and other registries.

Q. Why was the JAXR information model not designed from the ground up?

A. Information models take time to develop. It was easier to start with an existing information model and improve upon it.




Java API for XML-Based RPC (JAX-RPC)

Q. What is the Java API for XML-Based RPC (JAX-RPC)?

A. The Java API for XML-Based RPC (JAX-RPC) enables Java technology developers to build Web applications and Web services incorporating XML-based RPC functionality according to the SOAP (Simple Object Access Protocol) 1.1 specification.

Q. How does JAX-RPC use SOAP?

A. Please refer to JSR-101.

Q. What is RPC?

A. RPC stands for remote procedure call, a mechanism that allows a client to execute procedures on other systems. The RPC mechanism is often used in a distributed client/server model. The server defines a service as a collection of procedures that may be called by remote clients.

Q. How is XML related to RPC?

A. The remote procedure call is represented by an XML-based protocol, such as SOAP. In addition to defining envelope structure and encoding rules, the SOAP specification defines a convention for representing remote procedure calls and responses.

Q. What does JAX-RPC have to do with Web services?

A. An XML-based RPC server application can define, describe, and export a Web service as an RPC-based service. WSDL (Web Service Description Language) specifies an XML format for describing a service as a set of endpoints operating on messages. With the JAX-RPC API, developers can implement clients and services described by WSDL.

Q. What are the modes of interaction between clients and JAX-RPC services?

A. There are three different modes:

Synchronous Request-Response: The client invokes a remote procedure and blocks until it receives a return or an exception.


One-Way RPC: The client invokes a remote procedure but it does not block or wait until it receives a return. The runtime system for the JAX-RPC client may throw an exception.


Non-Blocking RPC Invocation: The client invokes a remote procedure and continues processing in the same thread without waiting for a return. Later, the client processes the remote method return by blocking for the receive or polling for the return.


Q. Can a remote method call or response carry service context information?

A. Yes. For example, it may carry a unique transaction identifier or digital signature.

Q. Why doesn't xrpcc generate a WSDL file?

A. The xrpcc tool does in fact generate the WSDL file, but due to a bug it gets deleted along with the source files if the -keep option is not specified. You can use the -keep option which will cause xrpcc to not delete the WSDL or .java source files. If you also use the -s sourcepath option, all of the source files will be placed in the sourcepath directory and then you can easily delete them. The WSDL file will still be placed in the current directory or the directory specified by the -d option.




Java 2 Platform, Enterprise Edition

Q. Does the Java 2 Platform, Enterprise Edition (J2EE) use XML?

A. The Java 2 Platform, Enterprise Edition (J2EE) promotes the use of XML for data messaging between loosely-coupled business systems. The J2EE reference implementation includes the Java API for XML Parsing (JAXP).

JavaServer Pages (JSP) can generate and consume XML between multi-tier servers or between server and client. Java Message Service (JMS) provides an asynchronous transport mechanism for XML data messaging. Enterprise JavaBeans (EJB) offers a robust, synchronous transport mechanism by allowing a business service object to be invoked by XML tags. EJB also uses XML to describe its deployment properties, such as transactions and security.

Q. Can I generate dynamic XML documents using JSP pages?

A. JSP pages enables the authoring of XML pages. XML pages can be generated using JSP pages, which include elements to produce the dynamic portions of the document. The JSP specification includes a powerful tag extension mechanism that can be used to perform XML-based operations, such as applying an XSLT transformation to an XML document.