Web Cornucopia

SOA Tips: For Asynchronous, Peer-to-Peer Collaborations Use Multiple MEPs

gopalan — Tue, 29 May 2007 07:15:36 +0000

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.

Related Blog Entries:

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Prefer Use of Document/Literal Rather than RPC

gopalan — Mon, 28 May 2007 07:39:09 +0000

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.

Related Blog Entries:

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

My Article Nominated for JDJ Annual Readers’ Choice 2007 Awards

gopalan — Sun, 27 May 2007 06:53:18 +0000

A couple of days back, my co-worker Prakash Aradhya pointed me to the JDJ Annual Readers’ Choice Awards 2007 poll indicating that my favorite Open ESB open-source project, that I’d been a committer for, has been nominated in the Best Java Enterprise Service Bus category. He also mentioned that Project Glassfish and NetBeans have also been nominated in the Best Java Application Server and the Best Java IDE Environment categories respectively. Since I am an active committer to all of these projects, I went to the JDJ website to peruse the information, and lo and behold, I realized that one of my articles entitled Implementing Service Oriented Architectures (SOA) with the Java EE SDK that I had authored a while back had also been nominated for the Best Java Technical Article category.

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.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Favor Contract First Development (a.k.a. Top-Down approach)

gopalan — Sat, 26 May 2007 12:32:05 +0000

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.

Related blog entries and videos:

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: The Wire Always Goes Forward never Back

gopalan — Fri, 25 May 2007 11:41:44 +0000

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).

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Use Separate MEPs for Business Responses

gopalan — Thu, 24 May 2007 09:20:47 +0000

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.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Message Exchange Patterns (MEPs) are the units of ‘wire’ collaboration

gopalan — Wed, 23 May 2007 08:25:44 +0000

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.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Use Correlation Values to Reference Shared State

gopalan — Tue, 22 May 2007 09:07:23 +0000

Share conversational state on the wire using self-defined correlations in the message. This ensures that subsequent processes in the collaboration tail can correlate the response to a specific request. The identifier(s) placed in the Message Property of the WSDL can serve as correlation identifier(s) that tie together message instances with a particular conversation.

To learn more about this, read this blog entry of mine entitled What is Correlation, message Property, Property Alias, and Correlation Set

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Identify Shared Conversational State Upfront

gopalan — Mon, 21 May 2007 09:12:01 +0000

We like to think of the net as a RESTful environment that is stateless, but in reality, when doing eBusiness Collaborations we have to understand how to deal with shared state. The fundamental mechanism for referring to shared state is the conversational context and the business correlation that ties the messages together. In fact, business correlation is the way we link to the implied shared state that the roles in the collaboration assume exist, and is being consistently moved forward through message exchanges.
It is important that this conversational shared state is something that is made visible through your wire design. The transitions that the shared state goes through is well defined by the semantics of the conversation.The more visible the transitions are, the easier it is to synchronize the shared state between the collaborations whatever that shared state may be – whether it is some book purchase activity that you’re trying to collaborate over, or its a Purchase Order that you are trying to push, through some eBusiness purchasing system.

Conversations always have an implied semantic shared state that participants can share and refer to in the message body to keep track of message relationships. Identify element(s) in the message that can serve as a shared state-holder, for e.g., unique business specific identifiers that are customer specific, like Social Security Numbers, Insurance Claim Numbers, Purchase Order identifiers, etc. Ensure that these values are easy to find in the message body by clearly defining XPath queries to extract the identifier(s) from within each message.

The figure above shows a new Purchase Order activity. As you already know, a Purchase Order is a business document that defines a service level agreement (SLA) between a buyer and a seller. The buyer agrees to buy a certain set of items at a particular price, and the seller agrees to provide these items at a particular price, and ship it to the specified address by a given date, so on, and so forth.

Normally, the buyer creates a new Purchase Order, assigns a Purchase Order Identifier to the document and sends it across the wire to the Seller. The Seller receives the new Purchase Order, assigns his own Purchase Order Identifier to it and returns it back to the Buyer as an agreement that he is willing to fulfill the order. In this message exchange, the shared state is the Purchase Order Identifiers that each of them assigned to the document. In any further conversations between them, if they have to refer to this Purchase Order document, they have to exchange both the Order IDs that each of them assigned to the document. This is the shared state that uniquely identifies that document in both their systems.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: What is a Conversation in a collaboration wire-design

gopalan — Mon, 21 May 2007 09:10:00 +0000

When doing wire-design for global collaborations, you have to think about how to establish Conversation. Typically in a eBusiness context, a single delivery of the message is not enough to achieve the business purpose. There is some interaction of messages involved between collaborating partners that ends up resulting in some unit of activity. These interactions of messages can therefore span multiple HTTP sessions that require a business-level correlation and are essentially peer-to-peer message exchanges.

So when designing global collaborations for wire-centric integration, you have to think about:

the roles of the participants,
what correlations you are trying to establish between them,
what is the lifecycle of this conversation – what starts the conversation, what maintains the conversation, what completes the conversation, and
the shared state that is implied to exist within the context of the conversation.

The conversation is a new computing context that you will have to think of in wire design.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema