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:

1. the roles of the participants,
2. what correlations you are trying to establish between them,
3. what is the lifecycle of this conversation – what starts the conversation, what maintains the conversation, what completes the conversation, and
4. 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.

Like this write-up? Subscribe to receive more like it.

In designing global collaborations for wire-centric integration, particular attention has to be paid to persistence of transactional business information. Transactional business information that is required by a service for processing long running collaborations should be made persistent for a number of reasons, for e.g., to handle failures, for manageability, reliability, performance, for compliance, and support for audits. Persistence of business information is also required to provide for state-management of services, processes, or composites. This includes supporting long-term transactions, or multi party/multi-partner collaborations.

A message has a header and a body. However, when you want to persist
the business data in a data store for further processing, you only
persist the message body since the message body contains the business
data. Therefore the Message body has to stand alone – do not place information that you will need to reuse to process a collaboration in the Message header.

Like this write-up? Subscribe to receive more like it.

In wire-centric integration for global collaborations, your Information model evolves over time. XML Schema and WSDL help you document those changes over time, and at any point in time, they help you validate your information model at that period in time. 

Explicitly add a version number attribute to the first element of both the request and the response message wrapper.

This will ensure the Message Exchange Pattern (MEP) and the schema of the exchanged messages evolve in tandem.

Over the years so much has been said about evolution and there are tomes of literature on the subject if you look around. Every organization has come up with their own solution to evolve their schemas and WSDLs based on a combination of facilities for evolution provided in the XML Schema specification, and their internal policies. Without over-simplifying the complexities involved in providing for versioning your information model, it is safe to say that adding a version number attribute to the first element of both the request and response message wrappers will allow you to have complete control over how to evolve your Message Exchange Patterns over time.

Assuming you have this simple mechanism in place, you have multiple approaches over how to evolve your collaborations over time. For one, as soon as the service receives the message, the whole message is not parsed, but an XPath query is executed on the message that looks for the value of the version number attribute of the first element of the message. Based on the version number, the message can now be routed to the appropriate version of the collaboration that can handle the message. I will, however, leave this topic for a more in-depth article on Evolving Service Collaborations for Wire-Centric Integration in the near future.

Like this write-up? Subscribe to receive more like it.

If the exchanged Business Objects are large and contain multiple
different types of binary content, use Message Transmission Optimization
Mechanism (MTOM) which uses XML-binary Optimized Packaging (XOP) to
transmit binary data.

Create a wrapper message that can contain multiple different types of files.

The wrapped message can then serve as a virtual message.

Use multi-part MIME to physically carry the message so at any point, you don’t have to parse the entire message at once.

This ensures efficient transmission of large binary data between the service and its consumers.

Like this write-up? Subscribe to receive more like it.

View cook-books written for the SOA and Composite Application functionality in NetBeans 6.0 Preview (M9). These cook-books from Sherry Barkodar also include multiple Flash videos along with the  LoanProcessing application demonstrated at Java One 2007. Among a lot of other features, these CookBooks also cover some new functionality that is available in NetBeans 6.0 Preview (M9) namely, Composite Application Editor/Enterprise Mashup Editor/CASA Editor Intelligent Event Processor (IEP) Engine SMTP Binding Component

Loan Processing
This tutorial provides an overview of a simple loan processing composite application and illustrates deploying, executing, and testing of a Composite Application. This tutorial includes a SOA project, Composite Application, Composite Application/Enterprise Mashup (CASA) editor, Intelligent Event Processing (IEP), XSLT and SMTP Binding Component.

SMTP Tutorial
This Flash Video is a simple helloSMTP which illustrates a basic scenario of a simple SOA project. It includes WSDL, CASA editor, and SMTP Binding Component.

Intelligent Event Processor
Creates an intelligent event processor LoanIEP that monitors the percentage of approved loans for one day.

Like this write-up? Subscribe to receive  more  like it.

Fine-grained interfaces kill system performance. Coarse-grained
interfaces reduce the cost of data processing and improves network
latency.

You have to exchange rich business documents that effect complete state changes in the system rather than exchanging  multiple small documents that only effect small state changes in a system.

Business messages may contain one or more business objects that they carry.

When
designing global collaborations for wire-centric integration, if you
have a complicated interchange that has multiple business objects to it,
aggregate these messages together by wrapping them.

Ensure that the container of the wrapped messages has a unique top-level element name.

This
wrapper can serve as an open-ended container that sets the business
context for what to do with these messages and ensures these messages
are self-defining.

Like this write-up? Subscribe to receive more like it.

The Wire is cross-platform and heterogeneous in nature. Collaborations take place through the message-based wire. In doing so, we have to ensure that we collaborate with the least amount of overhead. An important consideration in designing for wire-centric integration is to  separate the collaboration design from the individual implementation details. It is important to look into the individual pieces that make up the collaboration and discuss how to handle:

1. Information Exchange
2. Evolution
• Versioning issues in XML Schema: The XML
  Infoset makes it extremely easy to extend the document design. Add
  attributes and elements anywhere you want and extend the document
  design it’s that easy. In most cases, people do not even think of it as
  extensions.
3. Compensation
4. Identity
5. Access/security

The focus of the collaboration design in wire-centric integrations is the architecture of the collaboration itself – it is not the architecture of the individual components that participate in the collaboration or their implementation details. In a wire-centric integration design, there are no ambiguous messages. Therefore, the best practices for designing global collaborations are to have a consistent collaboration design. To do that, we have to consistently evolve the collaboration in Toto. Messages have to be self-defining in a formal sense to clearly interact with the version of the collaboration that they are dealing with. In a global collaboration, all conversations – whether they are bi-directional or multi-partner – occur within a specific version of the collaboration.

Capturing Collaboration Design

Capture broad use-cases. Have a Formal Schema Design for your Information Model that may evolve over time. The design of the collaboration should be succinct yet complete. It should capture the Collaboration. Remember that WSDL plays only a very small part in all of this since WSDL defines the output of a Collaboration design, rather than a description of the Collaboration.

A Wire Design Separates the Wire From the Applications That Use It

The Collaboration design is a complete design element that captures the full semantic content of the collaboration and stands apart from the applications. Even if you throw away the implementation of the roles, you should still be left with a complete collaboration design that documents well-defined semantics. A third-party should be able to follow everything that’s going on, about all the messages that flow through the system by just looking at the design.

In subsequent web logs, I intend to identify some simple basic best-practices to do good collaboration design for Wire-centric Integration.

Like this write-up? Subscribe to receive  more  like it.

Just came back from San Fransisco after attending JavaOne 2007.

Here are the slides for our technical session (TS-8897) entitled Designing Service Collaborations: ‘Wire’-Centric Integration which I presented with Mark Hapner at the JavaOne 2007 conference on Thursday May 10, ’07 at 10:55 am.at the Esplanade A/B Moscone South Tower – Room #304/306.

Mark Hapner went first and for the first half of the presentation talked about:

• Focus shifts to the ‘wire’
• What the ‘wire’ isn’t
• What the ‘wire’ is
• ‘Wire’ design

I did the second half with 15 ‘Wire’ design best practices.

We had so many ‘Wire’ design best practices, but in a session that is limited to an hour, there are only as many that you can talk about. I hope to talk about so many other best practices through my blog here and various articles and white-papers that I plan to write.

Like this write-up? Subscribe to receive  more  like it.

Technical Sessions related to Open ESB today

TS-8683 Introduction to CASA: An Open Source Composite Applications Editor
May 11, Friday 12:10 p.m.

Like this write-up? Subscribe to receive  more  like it. 

 Technical Sessions related to Open ESB today

1. # TS-8897 Designing Service Collaborations – ‘Wire’ Centric Integration
   May 10, Thursday 10:55 a.m. by Mark Hapner and Gopalan Suresh Raj at the Esplanade A/B – Moscone South Tower.
2. # TS-8434 AJAX Push (aka Comet) with Java Business Integration (JBI)
   May 10, Thursday 2:50 p.m.

 Minitalks today

1. 1:00pm – Aspect Orientation for Enterprise Mashups using OpenESB
   by Gopalan Suresh Raj and Yoke Lee
2. 3:00 pm – Orchestrating business processes using BPEL
3. 3:30 pm – NetBeans tools for developing OpenESB composite applications

  Like this write-up? Subscribe to receive  more  like it.