Tutorial:Review of Building Web Services for the Web Service Developer Exam
In this article, we will look provide an overview of the building web services so that a developer can succeed on the web service developer exam. We will provide an overview of SOA and web services and the standards (i.e. SOAP, WSDL, UDI, etc) that support it. We will also look at the Web Service Interoperability Basic Profile (WS-I Basic Profile) in order to understand how to combine a set of standards in order to ensure interoperability across all of your systems built on web services. Finally we will look at the use of XML Schema in JEE Web Services. This article is part of a series of articles to help you prepare for the web service developer exam.
What Are Web Services
A web service is a piece of business logic, located somewhere on the Internet, that is accessible using standard-based Internet protocols such as HTTP or SMTP. A web service is simple to use. It could be used for logging into a site or for something more complex like managing a multi- organization business negotiation.
There are a number of technologies used for web services are based on standardized XML and supported globally by most major technology firms. XML is a language-neutral means for representing data, and is globally supported in every major new software technology that leverages web services. When these are combined through software integration and interoperability, it offers an infinite number of possibilities for software programs to leverage the web services model. Web services across all the platforms that support it have common behavioral characteristics:
It uses XML as the data representation layer for all web services protocols and technologies that are created. These technologies are interoperable at a core level. As for data transport, using XML eliminates the need for any networking, operating system, or platform binding that the protocol would normally use.
This means that the consumer of a web service is not tied to that web service directly and it allows for the web service interface to change over time without compromising the client's ability to interact with the service. By using a loosely coupled architecture, software systems are more manageable and allows simpler integration between different systems.
In comparison to fine grain operations that are typical of object-oriented technologies such as Java with individual methods. Coarse-grained services are typical of web service technologies as they tend to encompass comprehensive units of business logic.
Work either Synchronously or Asynchronously
The ability to work asynchronously is a key factor to enable loosely coupled systems. With web services you have the option of using synchronous invocations, in which the client blocks and waits for the service to complete its operation before continuing or asynchronous operations where a client will invoke a service and then execute other functions. The asynchronous client will retrieve their result at a later point in time.
Supports Remote Procedure Calls (RPCs)
You can invoke procedures, functions and methods on remote objects using web services. The client can do this using an XML-based protocol. Remote procedures will expose input and output parameters that a web service must support. Components can be developed using Enterprise JavaBeans (EJBs) and .NET Components which both support object distribution and accessibility through a variety of RPC mechanisms.
Supports Document Exchange
By using XML, data is represented in a generic way. Documents can be simple or complex. Web services supports this transparent exchange of documents to facilitate business integration.
Service Oriented Architecture
SOA is a style or approach to building systems where the problem is decomposed into a collection of smaller, related pieces. Each of these pieces addresses a concern or a specific part of the problem. SOA transcends technology and automation solutions. It is an established and generic theory that can be used to address a variety of problems. What distinguishes the service-oriented approach to separating concerns is the manner in which it achieves separation. Service-oriented architecture (SOA) facilitates individual units of business logic to exist autonomously yet not isolated from each other. Units of logic are still required to conform to a set of principles that allow them to evolve independently, while still maintaining a sufficient amount of commonality and standardization. Within SOA, these units of logic are known as services.
Services Encapsulate Business Logic
Services encapsulate logic within a distinct context while retaining their independence. This context can be specific to a business task, a business entity, or some other logical grouping and the concern addressed by a service can be small or large. This means that the size and scope of the logic represented by the service can vary. Also service logic can encompass logic encapsulated in other services. In this situation, one or more services are assembled into a composite business service.
An example of this is business automation solutions which generally are an implementation of a business process. The business process is comprised of business logic that determines the actions to be performed by the solution. The logic is decomposed into a series of steps that execute in predefined sequences according to business rules and runtime conditions. In the figure below the business automation solution consist of services, each service encapsulates a task performed by an individual step or a sub-process comprised of a series of steps. A service can also encapsulate the entire process logic. In the last two cases, the services encompass the logic encapsulated by other services.
When other services want to use the logic they encapsulate they request to participate in the execution of business activities. They do this by forming a distinct relationships with those that want to use them.
Relationship Between Services
Within SOA, services can be combined with other services or used by other services or programs. All relationships between services is based on services needing to be aware of each other in order for them to interact with each other. This awareness is achieved via the use of service descriptions. Service descriptions are used to provide the service name as well as the data provided as input and output by the service. It is because services use service descriptions that we have loose coupling. This is what allows one service to understand what is required to establish a relationship with another service. An example of two services establishing a relationship with another service is shown in the figure below:
Services interact and accomplish meaningful work through an exchange of information. An example of a communications framework that is capable of facilitating loosely coupled relationship is messaging. When a service sends a message, it has lost control of what happens to the message. Messages are considered as autonomous units of communication that can be provided with the intelligence to self-govern their part of the processing logic. This is shown in the figure below:
A basic architecture for any system is provided by services with service descriptions that communicate via messages. The difference between this type of architecture and past distributed architectures that support messaging and a separation of interface from processing logic is the design of the three core components (i.e. services, descriptions, and messages). It is at this point that we see the benefits of service-orientation.
How Services are Designed
Service-orientation introduces commonly accepted principles governing the positioning and design of our architectural components. When applied, these principles allow for processing logic that is standardized and service oriented. This is what we refer to as a service-oriented solution. Key aspects of this are shown in the figure below:
Some of the key aspects of service orientated principles are discussed below:
- Loose coupling - services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.
- Service contract - services adhere to an agreement that is defined collectively by one or more service descriptions and related documents.
- Autonomy - services are in control of the logic they encapsulate.
- Abstraction - services hide logic from the outside world. Another service only knows what is described in the service contract
- Reusability - logic is separated into autonomous loosely coupled services with the intention of promoting reuse.
- Composability - services can be assembled to form composite services that can be orchestrated by one or more service.
- Statelessness - services minimize holding client state information specific to an activity.
- Discoverability - services are designed to be found and assessed by available discovery mechanisms by the use of service descriptions.
Now that we have a basic architecture through the use of components and a set of design principles that can be used to shape and standardize these components, we now require an implementation platform that will allow us to pull these pieces together to build service-oriented automation solutions. This is where web services technology comes in to provide us with offers us such a platform. An image showing the relation with core SOA specifications standards are shown below:
Until now we have discussed what one could call primitive SOA. It represents a baseline technology architecture that is supported by current major vendor platforms. All forms of SOA are based on and extend primitive SOA. Some extensions can be done today in an application using advanced design techniques and other extensions rely on the availability of pre-defined Web services specifications as well as vendor support.
Although the founding principles of SOA remain, these have been expanded upon when the opportunity has presented itself. Software vendors are pushing new web services specifications and building powerful XML and Web services support into current technology platforms. This has resulted into the extended variation of service-oriented architecture that we call contemporary SOA. Contemporary SOA leverages industry and technological advancements and builds upon the primitive SOA model to further its ideals. Contemporary SOAs have evolved despite implementation technology varying to a point where they can be associated with a set of common characteristics. Those related to interoperability among different systems is addressed in the web services interoperability basic profile (WS-I Basic Profile).
What is the WS-I Basic Profile
The Basic Profile is the conclusion of work to develop a set of core, mature specifications for Web Service Interoperability (WS-I). This set comprises a commonly supported and well aligned Web service platform whose primary purpose is to resolve interoperability issues. The benefit of the Basic Profile is that any organization that complies with the profile will ensure a certain level of industry-wide conformance. For WS-I Basic Profile 1.1, it is recommended that organizations standardize on the following specifications:
- SOAP 1.1 - Simple Object Access Protocol provides a standard packaging structure for transporting XML documents over a variety of standard Internet technologies, including SMTP, HTTP, and FTP. It is an XML based protocol used to exchange information throughout a distributed environment. It also defines encoding and binding standards for encoding non-XML RPC invocations in XML for transport. SOAP provides a simple structure for doing RPC: document exchange. By having a standard transport mechanism, heterogeneous clients and servers can suddenly become interoperable. .NET clients can invoke EJBs exposed through SOAP, and Java clients can invoke .NET Components exposed through SOAP.
- WSDL 1.1 - Web Service Description Language is an XML technology that describes the interface of a web service in a standardized way. It is an XML grammar for describing a web service as a collection of access endpoints1 capable of exchanging messages in a procedure- or document-oriented fashion. A WSDL document is a recipe used to automate the details involved in application-to-application communication.
- XML 1.0 - eXtensible Markup Language provides a language-neutral way for representing data. By using XML as the data representation layer for all web services protocols and technologies that are created, these technologies can be interoperable at their core level. As a data transport, XML eliminates any networking, operating system, or platform binding that a protocol has.
- XML Schema 1.0 - provides a means of defining and validating XML Documents to ensure that they conform with the defined standard.
- UDDI 2.0 - Universal Description, Discovery, and Integration provides a worldwide registry of web services for advertisement, discovery, and integration purposes. Business analysts and technologists use UDDI to discover available web services by searching for names, identifiers, categories, or the specifications implemented by the web service. UDDI provides a structure for representing businesses, business relationships, web services, specification metadata, and web service access points.
Outside of the recommended standards, the Basic Profile also details how the features of each specification should be implemented. Below is some examples of the the Basic Profile’s design standards:
- SOAP envelopes cannot contain Document Type Declarations or processing instructions
- Avoid the use of SOAP encodingStyle attribute within SOAP envelopes
- All required SOAP header blocks should be checked before proceeding with the processing of other header blocks and message contents.
- It is required to reference a global element declaration when using the element attribute as part of a WSDL part construct within a message construct
- The sequence of elements within the SOAP Body construct must be identical to the sequence of elements established in the corresponding WSDL parts construct
- The WSDL binding element can only use the WSDL SOAP Binding
Keys to Achieving Interoperability
In order to achieve interoperability, there are a number of things that need to be considered:
- Using the same version or compatible versions of the specifications - not all specifications are backward compatible. For example, according to the 1.2 draft specification, a node complying with SOAP 1.1 generates a SOAP Fault indicating version mismatch if it receives a SOAP Version 1.2 message.
- New versions of a web service that may not be compatible with earlier versions - it's not clear how the standards for web services will support versioning.
- Sharing semantics - the semantics must be understood and agreed upon in advance by the parties through some mechanism.
- Outside of these considerations, interoperability also depends on interpretations or misunderstandings of specifications, support for optional features within a particular web services standard, the addition of proprietary extensions, as well as the lack of a standard in a particular area.
Interoperability problems can occur at a number of levels:
- Service development - the use of a WSDL or not, differing service definition methodologies, incompatible tools, etc.
- Service discovery - the use of different registry mechanisms, service definition and representative syntax, etc.
- Service deployment - there are different security mechanisms, wire-level compatibilities such as encoding, serialization, SOAP header extensions, etc that is dependent on the way they are done via such implementations as BizTalk and ebXML
SOA and the Importance of WSDL
A key part of the SOA delivery lifecycle is the creation of WSDL definitions. Service interface design is a key deliverable and aspect of the design phase. The result of the business and technical top-down and bottom-up analysis efforts are WSDL definitions that establish themselves as the public endpoints that form a new layer of infrastructure within a service-oriented enterprise. Key design issues related to WSDL design for SOA are shown below:
- Standardized Namespaces Use- WSDL documents are made up of elements associated with different specifications, including SOAP, XML Schema as well as the WSDL specification itself. This gets supplemented by user-defined elements.
- Modular Service Definitions - WSDL supports the capability for service definitions to be composed. This allows for you to modularize your WSDL documents to facilitate reuse and centralized maintenance.
- Granularity Compatibility - Ideally you would align service interface granularity with XML document granularity. But as it is considered best practice to design theWSDL first, this often conflicts with existing XML document structures. You can deal with this by using an additional service abstraction layer as a design-time measures.
SOAP and SOA
SOAP messages are considered as fundamental to service-oriented environments as WSDL definitions. The two primary areas in which SOAP messaging can be affected are the following:
- SOAP message style and data types - The biggest impact SOA can have on an existing SOAP framework is in imposing a preferred payload structure and data type system. This relates directly to the style attribute used by the soap:binding element and the attribute assigned to the soap:body element. As introducing SOA into RPC-style distributed environments can inhibit the potential of many WS-* specifications that expect document-style payloads, you will need to make changes to accommodate SOA requirements. For example, RPC-style approaches support the transmission of granular XML documents with targeted data leading to the creation of many granular, parameter-type XML documents. This would require you to bundled XML documents to support the coarser grained, document messaging model. Also there may be a requirement to use schema modules to accommodate SOAP message payload assembly from differently structured XML data sources. By properly applying standards, you can have consistent XML document structures that accommodate the runtime assembly of document-style SOAP payloads.
- SOAP headers - As a WSDL definition describes a service, it is one of the primary deliverable for each service design processes. But it doesn’t provides a full description of the SOAP messages needed for services to communicate using contemporary SOA. Although the XSD types used by WSDL definitions define and validate the contents of a SOAP message's Body construct, it is the metadata embedded into SOAP message headers that provide logic specific to message exchange scenarios. The SOAP headers used by messages processed by a service are built primarily using WS-* specifications supported by the service-oriented architecture of which the service is a part. Identifying and defining SOAP headers is linked to the development of your SOA and the WS-* specifications it supports. These extensions will ultimately determine the overall messaging framework as well as the extent to which SOAP messages are self-governing for their message path as well as for the processing required of services that receive them. This understanding of metadata abstraction permits us to adjust service operations accordingly.
Namespaces and SOA
Namespaces in SOA are basically identifiers of business or technology domains and are used as qualifiers for corresponding WSDL elements. The WS-I Basic Profile has a set of best practices for implementing namespaces within WSDL definitions. You will still need to to ensure the proper use of namespaces in XML documents outside of WSDL definition boundaries.
UDDI and SOA
UDDI defines a standard set of Web service operations that are used to store and look up information about Web service applications. It defines a standard SOAP-based interface for a Web services registry. You use a UDDI registry to find a particular type of Web service, or to find out about the Web services hosted by a specific organization. Depending on the scope of the service-oriented architecture you are designing, UDDI may become one of the technologies established as part of the overall service-oriented environment.
Although there are a number of corporations that use UDDI to enable the discovery of service descriptions consistent with the core specifications identified by the WS-I Basic Profile, there are other organizations that have decided to use traditional directory-based approaches (i.e. LDAP) to manage their service descriptions. Irrespective of which approach is used, it is important that the service design processes take potential discovery into account by promoting the creation of intuitive service interface designs and the documentation of supplementary metadata.
The UDDI specification is now maintained by the Organization for the Advancement of Structured Information Standards (OASIS). It was originally created by a multi-vendor organization called UDDI.org that was principally the brain child of Microsoft and IBM. The UDDI.org has a number of free UDDI registries open to everyone to use. The majority of UDDI registries are private systems deployed by individual companies or trade organizations.
There are three versions of UDDI at this time, versions 1.0, 2.0, and 3.0. The Basic Profile specifies the use of UDDI version 2.0. While version 3.0 is more recent, it was only recently completed when the BP was finalized and didn’t have enough vendor support for it to be considered by the WS-I.
XML Schema and SOA
XML Schema definitions establish data integrity throughout service-oriented architectures. Their most prominent role is the definition of a service's public data model as well as it’s use in WS-* specifications. Here are some of the key things to consider for XML schemas used in support of SOA:
- Modular XSD schemas - XML or XSD schemas can be broken down into individual modules that are assembled at runtime using the include statement (for schemas with the same target namespace) or the import statement (for schemas with different target namespaces). Because WSDL documents also can be modularized, the XSD schema contents of the WSDL types construct can reside in a separate document. Schema modularization establishes a flexible data representation architecture that fits nicely into SOA because of the ability to compose elements into a data components. XML schema modules provide various definitions that can be reused by different WSDL definitions processing messages with identical or similar payloads. For entity-centric XSD schemas, these can be designed to represent specific information sets corresponding to corporate entity models.
- Document-style messages and XSD schemas - document-style SOAP messages required by SOA are based on embedding intelligence directly into the document thus placing greater emphasis on advanced validation requirements. You could easily bundle groups of XML data into a single SOAP message. It is often necessary to use extensible or redefined schemas when building documents that represent multiple data contexts. Often this can lead to a situation where the XML Schema Definition Language is insufficient. In this case, you may need to implement extensions using technologies such as XSLT, in order to provide conditional validation. In the following section we will dive in deeper into XML Schemas and their use in JEE Web Services. This is focused primarily on its importance in the design and use of service descriptions.
WSDL-related XML Schema Language Basics
As we have mentioned previously, XML Schema Definition Language (XSD) has become a central and very common part of XML and Web services architectures. This language facilitates the construction of hierarchically structured XML documents. The XSD schema structure is built on a series of rules and constraints to which XML document instances must conform in order for parsers and processors to consider them valid. In fact similar to the relation between a Java class an instance of a class, the relationship of an XSD and XML document is similar. The XSD is analogous to a class and the XML document built from the XSD is considered an instance of the corresponding schema. An example of an XML Schema is shown below:
The core data representation rules that are provided by XSD schemas are those representing data according to type. Similar to data types used in programming languages, XSD schemas provide a set of non-proprietary data types used to represent information in XML document instances. XSD schemas support an extensive number of data types some of which do not always map cleanly to the proprietary types used by programming languages. In this case, a mapping process is used to select the XSD schema types best suited to represent data originating from or being delivered to proprietary application logic and data sources.
XSD schemas are often provided as separate .xsd documents but can also be embedded in other types of documents like an XML document instances or WSDL definition. Generally an XML document instance is linked to a separate XSD schema file. This allows for the same schema to be used to validate multiple document instances. As for WSDL definitions, you can import the contents of an XSD file into the WSDL or you can embed the schema content inline.
XSD schemas are written in XML similar to almost all XML and Web services specifications. They are considered an intrinsic part of XML data representation and service-oriented architectures. Irrespective of how you define the XSD schemas for your solution, the underlying processors will use XSD schemas to execute many tasks related to the processing of XML documents through Web services. In the following section we look at the XSD schema support in JEE Web Services.
JEE Web Services Platform
The Java Enterprise Edition (JEE) is along with .NET the two primary platforms being used to develop enterprise solutions using Web services.
In JEE, there are a number of components that interrelate with other parts of the overall JEE environment to provide a platform supporting SOA. The most important specifications related to SOA are listed below:
- Java Enterprise Edition Specification - this specification establishes the distributed JEE component architecture and provides foundation standards that JEE product vendors are required to fulfill in order to claim JEE compliance.
- Java API for XML-based RPC (JAX-RPC) - this specification defines the JAX-RPC environment and associated core APIs. It also establishes the Service Endpoint Model used to realize the JAX-RPC Service Endpoint, one of the primary types of JEE Web services.
- Java Web Services - is a set of tools within Java that facilitate invoking and deploying web services. This specification defines the vanilla JEE service architecture and clearly lays out what parts of the service environment can be built by the developer, implemented in a vendor-specific manner, and which parts must be delivered according to JEE standards.
Java Web Services platform has both server-side components and client-side components. The server-side components are normally packaged within an JEE application or web container. Client-side components are normally packaged as tools for accessing Java interface instances that are bound to Web Services. Irrespective of the Web Services platform,they have to provide three core subsystems of JWS:
This mechanism is used on both the server side and the client side. On the server-side, the invocation mechanism is responsible for:
- Receiving a SOAP message from a transport (e.g., either an HTTP or JMS endpoint).
- Invoking handlers that preprocess the message , by processing the SOAP headers or persisting the message to ensure it is not lost.
- Determining the message’s target service. In most cases this will be the WSDL operation the message is intended to invoke.
- Determining the Java class/ method to invoke based on the target WSDL operation. This is referred to as dispatching.
- Handing off the SOAP message for deserialization into Java objects to the Serialization subsystem in order to be passed to the Java target as parameters.
- Invoking the Java target using the parameters generated by the Serialization subsystem and getting the Java object returned by the target method.
- Handing off the returned object to the Serialization subsystem to serialize it into an XML element conforming with the return message specified by the target WSDL operation.
- Wrapping the returned XML element as a SOAP message response conforming to the target WSDL operation.
- Handing the SOAP response back to the transport for delivery.
The client side invocation process is similar if you want to invoke a Web service using a Java interface. If you’re working with XML, it is advised to construct a SOAP message from XML and pass it to the web service. For JWS, the assumption is that you're using Java. In this case on the client-side, the invocation mechanism is responsible for:
- Creating an instance of the Web service endpoint implementing a Java interface referred to as the service endpoint interface (SEI). The invocation subsystem has one or more factories for creating SEI instances. These instances are either created on the fly, or accessed using JNDI. Typically, SEI instances are implemented using Java proxies and invocation handlers.
- Handling an invocation of the SEI instance.
- Taking the parameters passed to the SEI and passing them to the Serialization subsystem to be serialized into XML elements that conform to the XML Schema specified by the target service’s WSDL.
- Based on the target service’s WSDL, wrapping the parameter elements in a SOAP message.
- Invoking handlers that post-process the message. This can be either to persist the message or set SOAP headers based on Quality of Service (QoS) or other requirements.
- Handing off the message to the transport for delivery to the target Web service.
- Receiving the SOAP message response from the transport.
- Handing off the SOAP message to the Serialization subsystem to deserialize it into a Java object that is an instance of the class specified by the SEI’s return type.
- Completing the invocation of the SEI by returning the deserialized SOAP response.
Serialization is the process of transforming an instance of a Java class into an XML element. The inverse process, transforming an XML element into an instance of a Java class, is called deserialization.
The deployment subsystem supplies the tools for setting up a Java target so that it can be invoked as a Web service via SOAP messages. At a high level, the deployment subsystem needs to handle:
- Deploying the Java target(s) - This task varies greatly depending on the Java container where invocation takes place. For an EJB container, it may mean deploying a stateless session bean. In other situations, it simply means making each Java target’s class definition available to the class loader employed by the invocation subsystem.
- Mapping WSDL operation(s) to a Java target(s) - This involves configuring the Web Services platform so that the invocation subsystem can properly bind an incoming SOAP message with its Java target. This binding is stored as meta-data which the invocation subsystem can access from the deployment subsystem to determine the Java target that should be invoked. In addition to binding a WSDL operation with a Java method, the deployment subsystem helps the invocation system to properly interpret the SOAP binding to determine whether it is rpc vs document style, wrapped vs unwrapped parameters for the incoming message.
- Defining a serialization context - The deployment subsystem configures the serialization subsystem with the serialization context needed to bind the XML Schema types from the WSDL with the parameter and return classes from the Java target(s). This serialization context is used by the serialization subsystem to implement the binding of WSDL operation(s) to Java target(s).
- Publishing the WSDL - The deployment subsystem associates a Java target with the WSDL document containing the WSDL operation it is bound to. This WSDL document is made available to the Web service’s clients as a URL or within a UDDI registry.
- Configuring SOAP handlers - The deployment subsystem configures the necessary SOAP handlers needed to provide QoS pre- or post- invocation of the Java target. These handlers provide services such as authentication, reliability, and encryption. Although the invocation subsystem invokes the handlers, they are configured and associated with a Web service by the deployment subsystem.
- Configuring an Endpoint Listener - The deployment subsystem configures the container so that there is a SOAP message transport listener at the URI specified by the WSDL port. In some Web Services platforms, the endpoint is completed by the deployment subsystem from a deployment descriptor rather than being supplied by the WSDL.
XML Schema Support in JEE Web Services
XML Schemas are pervasively used throughout JWS is to make it easier for Java developers to create, deploy and invoke Web Services. there have been a number of features developed specifically with ease of use in mind for Java Web Services. A quick summary of some of the important features is provided below.
Source Code Annotations
Source code annotations for Web Services were introduced to help reduce deployment complexity. Annotations are defined by JAX-WS [JSR 224], WS-Metadata [JSR 181], and JAXB [JSR 222]. These annotations are used within all three subsystems defined by the WSPA:
Standard WSDL/Java Mapping
JAX-WS is the invocation subsystem of JWS. defines a standard mapping of WSDL to/from Java.
JAX-WS 2.0 specifies the invocation subsystem of JWS, part of the deployment subsystem, and even a little bit of the serialization subsystem. It provides a lot of features that integrate with the Web Services Platform Architecture. This is shown in the table below:
The JAX-WS 2.0 specification defines a standard Java/WSDL mapping. This standard Java/WSDL mapping is part of the JWS deployment subsystem. It determines how WSDL operations are bound to Java methods—in other words, when a SOAP message invokes a WSDL operation, the Java/WSDL mapping determines which Java method gets invoked and how that SOAP message is mapped to the method’s parameters. Conversely, the mapping also determines how the method’s return value gets mapped to the SOAP response.
JAX-WS lets the developer specify a static WSDL document that can bypass the automatic generation of WSDL that is based on the standard WSDL/Java and XML/Java (JAXB) mappings.
Invocation with XML
As an alternative to invocation with Java interface proxies, a Service instance can be used to invoke a Web service by sending and receiving XML messages.
JAX-WS provides support for XML Catalogs. This includes the OASIS XML Catalogs 1.1 specifications. This is helpful for WSDL documents to import external schemas to avoid duplicating the same schema information in each WSDL document whenever you use standard types.
Java API for XML Binding (JAXB)
JAXB 2.0 defines a standard Java/XML binding from Java representations to XML Schema components and vice versa. It tackles a tough problem. XML Schema is a complex and expressive language. JAXB 2.0 is best thought of as a Java/XML binding tool. That is because the annotations on the Java classes used by JAXB 2.0 define a binding. Each class maps to a unique XML Schema component based on its annotations.
Java API for XML Processing (JAXP)
This API is used to process XML document content using a number of available parsers. Both Document Object Model (DOM) and Simple API for XML (SAX) compliant models are supported, as well as the ability to transform and validate XML documents using XSLT stylesheets and XSD schemas. Example packages include:
- javax.xml.parsers - a package containing classes for different vendor-specific DOM and SAX parsers.
- org.w3c.dom and org.xml.sax - packages that expose the industry standard DOM and SAX document models.
- javax.xml.transform - a package providing classes that expose XSLT transformation functions.
In this article, we have covered the basics of web services, service orientated architecture, the WS-I Basic Profile and then looked into how JEE provides a platform called Java Web Services for creating, deploying and invoking web services within your SOA. In the next article we will dive in deep into the web service standards.