Document-Based Web Services

In the RPC-based interaction, the web service is viewed by the consumer as a single logical application or component with encapsulated data, where the WSDL described by the
publicly-exposed interface and the XML in the SOAP messages exchanged is formatted to map to the discrete operations exposed by that application. In fact, the messages directly
map onto input and output parameters of the procedure calls or operations. Typically, such invocations occur over a synchronous transport protocol like HTTP, where the SOAP
request and response is piggybacked on the protocol-level request-and-response, respectively, to form synchronous request-response interaction patterns. For example, see Figure
1, which illustrates a payment service that accepts payments and returns a status, or a stock quote service that accepts a ticker symbol and returns the current quote in the HTTP
response.

In a document-based interaction, the service consumer interacts with the service using documents that are meant to be processed as complete entities. These documents typically
take the form of XML, which is defined by a commonly agreed upon schema between the service provider and service consumer. It is also possible that the document exchanged in
such an interaction could be in a format other than XML (such as encrypted files); however, the value of agreeing on a XML schema is to facilitate interoperability. In other words,
the document represents a complete unit of information and may be completely self-describing.

Document-based message exchanges are more common to asynchronous communication architectures. Also, the effort and complexity involved in building a document-oriented web service is usually more than the effort involved in using an RPC-based architecture. This is because it involves extra steps, such as designing the schema for the documents that will be
exchanged, negotiating and arriving at an agreement with business partners on that design, and validating the document against the schema.

A SOAP message on the wire can be represented in either RPC style or document style. This choice is governed by the value of the style attribute in the WSDL file.

Development of a document-driven web service typically starts with the definition of the schemas and the WSDL describing the document exchange.

Asynchronous Web Service

The use of WS-Addressing 1.0 is automatically performed by WebLogic Server when implementing asynchronous web service features.

Buffered oneway operations are implemented by Web Service tier.

With buffered oneway operations, the generic client invokes the service synchronously. Beneath the covers, the synchronous call only completes upon the delivery of the request on the server-side JMS queue. Once the request is delivered successfully to the JMS queue, the client is unblocked and proceeds with its client-side execution. The JMS queue "weblogic.wsee.DefaultQueue" is used by default, although the buffered operation may specify a custom JMS queue if desired.

The oneway annotation @Oneway() marks a web service operation as buffered: the operation must return void. The optional @BufferQueue annotation specifies the JMS Queue used for a buffered operation. Without this annotation, the default queue "weblogic.wsee.DefaultQueue" will be used.

Asynchronous request-response operations are implemented by client tier.

In asynchronous request-response model, the client request is delivered to a client-side asynchronous handler. The Async Handler synchronously invokes the remote operation, and triggers the response handler method in the client to process the response.

The @ServiceClient annotation specifies the variables used to call a desired service asynchronously.
The @AsyncResponse annotation specifies the method to handle a response to an async request.
The @AsyncFailure annotation specifies the method to handle an error from an async request.

Happy Path

In the context of software, a happy path is a default scenario that features no exceptional or error conditions. For example, the happy path for a function that validates credit card numbers would be the one where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.

- Wikipedia

XML Basics

The XML schema document is an XML document that defines a set of valid XML documents.

A well-formed XML document follows the rules of the XML specification. A valid XML document conforms to a particular XML schema.

XML schemas define data models. XML data binding technologies use data models to translate XML document instances into native data objects. Some of the XML data binding technologies are Castor, JAXB, and XMLBeans (http://xmlbeans.apache.org).

XPath is a language for finding information in XML documents. XPath uses path expressions to navigate XML. XPath is a W3C standard (http://www.w3.org/TR/xpath).

XQuery is often referred as "SQL for XML". XQuery leverages XPath expressions. http://www.w3.org/TR/xquery. The XMLBeans API provides execQuery method for executing XQuery expressions. An XMLBean can be transformed into another XMLBean using XQuery.

Enterprise Web Services

A Port is an instance of a Web Service object. The Port terminology is defined by JSR-109, which states: "A service instance, called a Port, is created and managed by the server."

If a JWS file does not implement a service endpoint interface, all public methods other than those inherited from java.lang.Object will be exposed as Web Service operations. You can override this behavior by using the @WebMethod annotation to specify explicitly those public methods that are to be exposed. If @WebMethod annotation is present, only the methods to which it is applied are exposed.

Web service operations are equivalent to Java public methods. They are the whole reason for having a web service.

Coarse-grained interfaces are recommended as a best practice for external integration in SOA.

A standalone web service client leverages client artifacts to make a call on a web service operation. The client first creates a service. It then obtains a port from the service. Then methods corresponding to the web service's operations can be called on the port.