Gopalan Suresh Raj

The ‘Wire’ Is Global
Whether you are going to directly base your ‘wire’ design on the internet, or you are going to limit it to some particular set of users, you want to make sure that every ‘wire’ design you do, works globally. You have to get outside of the confines of the internet. The whole point is you do not control the technologies that your consumers or your providers are using. The only way to get eBusiness to integrate is to make sure that each ‘wire’ is, by definition, Global. And the truth is, for the most part, the only global communication stack that works today is the HTTP stack – modulo, email, FTP, etc. and a few others. So you need to be suspicious of folks who tell you that you could do an abstract design and somehow you can disconnect it from HTTP – specifically, like some people who say the SOAP Envelope is independent of the underlying protocol – don’t believe it.

The ‘Wire’ Is Peer-to-Peer
A lot of conversations involve you being both a consumer and a provider. In a typical situation, when you are exchanging messages asynchronously, you are typically shipping messages to each other, and are sharing these messages through HTTP resources. In such a situation, the only thing that allows you to correlate these messages is the content in the messages themselves. You cannot rely on this shared data to be in the context of a session, or some kind of pseudo-conversational mode where you can send somebody a cookie as a systems-level cookie and somehow they return the shared state because you don’t store systems-level cookies in the database so you can associate your response with that cookie.

The ‘Wire’ Is Asynchronous
The wire is asynchronous when you are dealing with it from an infrastructure integration level. When you are doing this asynchronous integration, the exchange of messages have to be correlated to the business functionality itself. The wire is more ad-hoc than conventional integration in the sense that the messages that you are exchanging are going across business process boundaries. Each side of the business process has its own objectives that it is trying to accomplish. The wire is a network resource. We are continuously evolving what we think of as a network resource. Technical elements are continuously being added to what we think of as the wire. At the business integration layer, we are just beginning to learn what it actually takes to make these eBusiness compositions. We need to think of this composition mechanism as something fundamentally different to code composition. What we do inside of our applications to create the stream of bits which is the network resource is secondary to what the actual resource is.

Difference between Web-site Interaction and eBusiness Integration
There is a core difference between website interaction and eBusiness Integration. If you force the people who are communicating with you to reply immediately, with a business response in the same Message Exchange Pattern (MEP), you are severely constricting how they use you. By separating the business response into a separate Message Exchange Pattern (MEP) interaction, you are freeing up both sides to interact asynchronously. That is the core issue of why eBusiness Integration is very much peer-to-peer rather than client/server. If you are kind of stuck in the client/server mode of thinking, it is very difficult to architect eBusiness Integration since client/server is not the model for eBusiness Integration. The core idea in eBusiness Integration is that businesses are off on their own, doing their thing, and they communicate only when they want to and on their own schedule.

Design Focus

Message Exchange Patterns (MEPs) are transient message exchange elements. If there is work that can be accomplished in a single, one-shot, stateless, self-contained collaboration, use a single MEP. For long-running, conversational, peer-to-peer collaborations, where there is an asynchronous lag between a request and a response with shared state use multiple MEPs with correlations.

You cannot have an asynchronous collaboration without having peer-to-peer message exchanges.

Prefer ‘document’ encoding and ‘literal’ use over other types for interoperability. Services exposed using Document style encoding with Literal use are better-suited for coarse-grained interactions and better represent the data exchanged. They provide the ability to validate the XML data if the XML Schema is available. You could specify XSL transforms to Transform messages using XSLT easily. Document style encoding with Literal use provides better performance than other encoding/use styles. Since the service interface in the WSDL clearly defines the types of documents expected, it makes it easy for the consumer to develop clients for the service.

Service-Orientation is totally different from either Object-Orientation or Component-Orientation

When we think about setting up a web community through a web-site, we do not think of it as exposing a Java class. We have some important business/organizational goal. We have a community of users we are trying to approach through the web-site. We work hard to conceptually get the idea of the web-site exposed in a way that is very practical for a broad range of users. We try to make it very simple and painless so that the user community we are trying to grow is able to approach it and get some value out of it. We hope that a user community materializes to make our investment practical. That is exactly what we need to think about from a service perspective when we are trying to expose services.

What is a Service
A Service is NOT some plumbing to put up a Java class with some getters and setters on the net. A Service IS a 24×7 commitment to expose some core business functionality up as a network resource that we are trying to share either inside of the business, or across the business boundary. That is the reason d’ etre for the service and the reason we are making the investment – it is not cheap, and it is not about exposing a Java class on the net – its a significant business functionality commitment. The fact that there might be an EJB under the covers that happens to be the entry point with some annotations on it is secondary, just as a servlet might be behind the web-site. When thinking about services, if you are thinking of putting up a Java class on the net then boy you have the wrong model in your head! A Service is NOT a Java class or a new way to share libraries.

Business-documents are the core building-blocks of a Service

You can think of business-documents as the core building blocks for building a Service for any e-Business vertical like Finance, Retail, Banking, Insurance, Health-Care, or Telecommunications, etc. When you are constructing the content for the business document, often, you have a wrapper which describes the business purpose, followed by the business data that’s embedded in the document that supports that purpose. So for e.g., if you have an Employee (a noun) creation/update (i.e., verbs) document, you have a wrapper around that data describing the business action (a verb) you are taking, and based on the data you may be able to surmise if its a new (creation) or update entry or you may have to mark that explicitly in the data itself. You can compose this up and you are doing this independent of this somewhat goofy procedure name idea that is in WSDL. You just get into the document and create it like you would any other business document while capturing in a reasonably self-describing way what it is your trying to accomplish – not from a procedural perspective, but from a business document perspective. That is the way to reason about what it is you are doing. If you do that, the reason you use Document style encoding with Literal use is so that you don’t get yet more crap into the message that is putting this weird operation name element into your perfectly valid business document. Therefore other forms of encoding – like RPC – just gets in the way`of creating perfectly legal business-documents . You have a self-defining business document that contains nouns and verbs. Each verb can be quite complicated – it isn’t a procedure name or an operation name – it is some description of a core business action.

RPC based services are stumbling-blocks rather than building-blocks

It is only when you start looking at at it from a kind of Java code-first perspective that you get confused. You do not think of business documents in Java. In Java, you’re thinking of function names and so forth and it has nothing to do with business integration. However, unfortunately, it is only when the people who are dreaming this up start thinking about the remote procedure call thing, they get all confused and we have to deal with the resulting kind of mish-mash of stuff.

So if you stick with the business document perspective, then you’ve got it. People know how to evolve business documents, they do not know how to evolve some weird operation name element inside their perfectly legal business documents.

If you did like my article, or you love project Open ESB, or Project Glassfish, or NetBeans, please do vote for these. If you chose to vote for other projects in the category, I would be grateful for your inputs in this blog indicating the features that you currently lack in these projects, or the enhancements that you would want made to these projects.

Call to Action

If you would like to see any enhancements to these projects, please tell us how we could improve it. Better still, since these are open-source projects, please get involved and influence the direction of these open source projects. We from the open-source community will forever value your invaluable inputs and contributions to make these projects the best ones in their respective categories on the planet.

Contract First Development is also called Design By Contract. Create the data contract in XSD and the behavioral contract in WSDL upfront. Use the XSD and WSDL editors provided by the NetBeans Software SOA Pack to do this. This approach forces the designer to focus on messages and contracts as the key concepts in designing a service contract.

If something goes wrong in a long-running transaction, you need to able to re-synchronize. The simplest way to re-synchronize is to do whatever you have to do and start over again. In some cases it may be some smaller fall-back in which case you can define the message to fall back to some intermediate restart point that you agree on in the collaboration design. However you look at it, it can get complicated. These collaborations do not happen in an atomic transaction, since these are transactions whose life cycle spans multiple partners and happens over a time of hours, or days, or weeks, or months. For example, in booking a reservation for travel you have your travel agent and your business process for booking a flight, a car, and a hotel. What happens when you get the flight, the car, and no hotel? Either you can choose to live with it and solve the hotel problem externally, or you could cancel the whole thing and try again with some other combination.

Certain run times or frameworks provide a previous snap-shot in time to figure out how to incrementally re-work the problem. This is more confusing than it is helpful. The very fact that you are looking at a state of the business process that does not represent the current state it is in, is more confusing than it is helpful. By giving you a view back in time where you think you are in a consistent state to make a decision, you have to understand where you currently are because you are somewhere else in time. How do you relate the previous state in time with where you currently are? So, do not rely on some generic automated runtime or framework to solve your business problem for you. It is better for you to handle this within your business logic.

Compensation is an application level function that defines the semantics for resolving issues that come up with in-flight instances. It is better handled by providing application level ‘cancellation’ functions. Think of the Collaboration as an entity that relentlessly pushes forward – it may change but it never ‘goes back’ to a previous state. If things get hopelessly stuck, then cancel and take whatever business hit cancellation costs (such as canceling a nonrefundable flight reservation).

The wire is peer-to-peer meaning that in most cases the individual collaborating parties are interacting in a peer-to-peer way. They are not restricted to some kind of limited client/server functionality where you got the big guy and a small guy and the small guy has different concerns than the big guy. Each element in the infrastructure has to deal pretty much with the same set of wire-design concerns. Simple things in a client/server world do not work the same way in the wire-design world – like HTTP session cookies, pseudo-conversational modes, and so forth – because that implies that there is this hierarchical relationship elements that are collaborating with wire design. The wire is not hierarchical, its peer-to-peer. That means that any kind of correlation between interactions is in effect up to the business logic to resolve. You are moving information back and forth and you really cannot rely on simple things like HTTP sessions to keep correlations between messages sorted out. You are pushing that to the edge to keep these correlations resolved.
When dealing with stateful interactions, mandating a business response as part of a single request/response message exchange pattern (MEP) overly restricts the asynchronous collaboration that is required. Often the business response is not available quick enough to place the acknowledgment into the response. The only way the business response can fully be decoupled from messages that produce them is to place the acknowledgment in a separate message exchange pattern.

The units of ‘wire’ collaboration are the Message Exchange Patterns (MEPs)

The most important thing to understand is that wire-design from an application perspective is made up of Message Exchange Patterns (MEPs) . These message exchange patterns are just units of simple message exchanges and are a way of incrementally shipping messages back and forth between different consumers and providers – whether it is with HTTP itself using Put, Post, Get, Delete, or WSDL 2.0 MEPs, or AS 2.0 MEPs. These are the incremental building-blocks of how data flows on the wire. These message exchange patterns are transient primitives that allow us to send a message and get back some immediate response to that message interchange.

Transient message exchanges

Message Exchange Patterns are transient message exchanges in the sense that they are simple synchronous interactions, typically end-to-end, that causes the message to be transported with some simple acknowledgment that it reached the other end. This is one of the things that distinguishes this infrastructure integration from the web-site interaction over the net because typically you are expecting a kind of full-fledged response coming back on the HTTP request and at the integration level often it is just a simple acknowledgment. Out of these simple Message Exchange building blocks we build larger practical conversations.

Design focus

The first consideration in building up a wire design is to determine which MEPs you are going to be using for what and define which particular transports you are going to be transporting these messages over. The first building-block that you have to think about in doing wire-design are which specific message exchange patterns you are going to use. It is perfectly fine to use HTTP directly. You don’t have to use a SOAP based message exchange pattern in order to do wire-design. That is a design choice you can make and it is not something that you have to feel bad about in the sense that you’re not ‘puffing up’ your wire design with the complexities of SOAP.

As we saw in previous entries, conversations are longer running contexts across which we are trying to collaborate. These conversations are built up of correlated messages. Message exchange patterns are not conversations – they are just a way of shipping the messages over the wire. From a network perspective, the network does not understand what a conversation is. Conversation is part of the wire design that is interpreted at the endpoints based on the correlations between these messages that have been described in the wire design architecture. Clearly, these conversations are peer-to-peer. Each side has some objective they are trying to achieve. Each side correlates these messages in different ways and they are just using the network to interchange these messages. So it is really important as part of the wire design to define the roles and correlations, the overall life cycle of the conversation, and the shared state that these conversations describe.

If you do not have a clear design for these, you cannot achieve a practical collaboration wire design.