Canonical Data Model

I am designing several applications to work together through Messaging. Each application has its own internal data format.

How can you minimize dependencies when integrating applications that use different data formats?

Therefore, design a Canonical Data Model that is independent from any specific application. Require each application to produce and consume messages in this common format.

The Canonical Data Model provides an additional level of indirection between application's individual data formats. If a new application is added to the integration solution only transformation between the Canonical Data Model has to created, independent from the number of applications that already participate.

Top Five Java Technologies to Learn in 2008

• #5 OSGI - Reality check, monolithic containers carry too much baggage and Java libraries are so richly cross dependent. The trend is there, a lot of frameworks are moving towards OSGI to bring some sanity in their deployment. Projects that have employed OSGI in anger are Eclipse via Equinox, Nuxeo and BEA Event Server,
• #4 JCR - Reality check, not all data fits well within a relational database. In most cases, users want to store their own documents and have those properly managed (i.e. versioned). JCR with it's Jackrabbit implementation is becoming the de-facto standard for maintaining data other than the structured kind. Some examples of projects that have used this in unexpected and innovative ways are Drools BRMS for managing business rules, Apache Sling for universal resource storage and Mule Galaxy for SOA governance management.
• #3 GWT - Reality check, AJAX is here to stay and Javascript is still a pain to work with. GWT is gaining traction like wildfire at the expense of other Java web technologies like JSF. A lot of projects have begun creating extremely cool products with it. Some impressive examples are Queplix a CRM, Compiere an ERP and GPokr a multiplayer Texas hold-em poker game.
• #2 Groovy - Reality check, sometimes you have to write quick and dirty scripts to get your tasks done quickly. There's a lot of traction these days for dynamic scripting languages like Ruby. However if you want to truly leverage your existing skill set, then it's more efficient to take a evolutionary step. Groovy has come a long way since it's rocky beginnings. I believe Groovy is finally mature enough (it finally has a debugger) that it's safe to dip your toes in it. Furthermore, there's are a of books, books about frameworks (i.e. Grails) and tools (i.e. IntelliJ) that help you from getting lost.
• #1 Cloud Computing - Reality check, sometimes it just isn't worth it to setup your own physical servers. Amazon's services are going to be an extreme boon to development productivity. One of the most time consuming efforts, and one that is too often taken for granted, is the deployment of a load and performance testing harness. In a lot of rigid organization, it is sometime problematic to acquire so much hardware for use only for short time periods. There aren't many tools out there yet for the Java developer (see: "Grid Gain Distributed JUnit"), however it's ramping up pretty quickly. So just as we create our builds from the cloud via Maven repositories, one shouldn't be surprised to find cloud based testing resources to be part of every developer's tool chain in the future.

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.