Gopalan Suresh Raj's Web Cornucopia

Open ESB Partner Ecosystem: Creating a Binding Component Deployment Plug-In for Netbeans

Posted in OpenESB by gsraj on June 4, 2007
Gestalt LLC Gestalt
LLC
., is an Open ESB partner. They are contributing a number of
different component containers and NetBeans Plug-ins for the open
source Open ESB project like the UDDI binding component, and the RSS
binding component among others. These plug-ins are bundled with the Open ESB Installer which is freely downloadable from the Open ESB download site.

Gestalt‘s Chad Gallemore has blogged about creating a Binding Component Deployment plug-in for NetBeans.

 

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

Deliver Composite Applications with Java, WS-BPEL & SOA

Posted in JBI and SOA by gsraj on May 30, 2007

Deliver Composite Applications with Java, WS-BPEL & SOA - Supporting the complete lifecycle

My co-workers Prabhu Balashanmugam, Kevin Schmidt, and yours truly
had an article published in the March 2007 issue of Java Developers’
Journal entitled Deliver Composite Applications with Java, WS-BPEL & SOA – Supporting the complete lifecycleTuesday
morning I walked into the office after the Memorial Day weekend, and I
find this issue dropped on my chair by Kevin. Too bad Prabhu
and me found our photos swapped.

The article discusses and demonstrates the many capabilities available
in the Java EE 5 SDK Tools Bundle for delivering composite applications
using Java, WS-BPEL, and SOA technologies. It discusses the benefits of
these two technologies and how they can work together to enable the
development of next-generation applications.

This article also demonstrates how NetBeans provides a truly integrated
development environment that allows users to extend existing Java
services, create new Java services, and compose Java services with a
business process. Also described is how NetBeans can be used to
iteratively develop, build, deploy, and test composite applications
seamlessly, thereby reducing the overall turnaround time and effort
required to deliver composite applications.

Deliver Composite Applications with Java, WS-BPEL and SOA

Scenario

The scenario is a new external-facing application that is being developed iteratively by reusing functions from existing Java EE applications and external Web services.

There are three existing Java EE Applications:

  1. the Performance Evaluator – provides evaluations on the fiscal performance of existing customers;
  2. the Vehicle Information Server – evaluates market conditions and vehicle history and serves a detailed report on the worthiness of the vehicle; and
  3. the Financial Index Server – provides the current running rates and values that should be used to compute the loan details.

The new application should provide a service to receive loan applications over the Web and respond with a decision.

The loan decision should be arrived at by applying predefined processing rules on the following data:

  1. applicant’s financial worthiness,
  2. vehicle’s value,
  3. loan amount, and
  4. current policies and indices for loans.

You can read the complete article from here

Related Links 

 

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

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

Posted in A Tip a Day by gsraj on May 29, 2007

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: 

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

Open ESB Partner Ecosystem: Videos on using SOAPUI with Open ESB, NetBeans, and GlassFish

Posted in OpenESB by gsraj on May 28, 2007
 Eviware SoapUi Logo Eviware is an Open ESB partner. Their popular Web Service testing tool  SoapUI (which has both a FREE version and a Pro version), is integrated with NetBeans - the design-time environment of choice for Open ESB. The SoapUI NetBeans plugin is bundled as an add-on with the Open ESB Installer which is freely downloadable from the Open ESB download site.

 

Eviware‘s Ole Matzura has created a series of videos demonstrating how SoapUI can be used to test Open ESB and JAX-WS deployments using SoapUI, NetBeans 6.0 (M9), Open ESB 2.0, and GlassFish.  

  • The first video demonstrates how to create a simple WSDL using NetBeans, implement and deploy that WSDL with a BPEL process to the Open ESB runtime, and finally test the deployed process with the soapUI module.
  • The second video demonstrates how to create a simple WSDL using NetBeans, create a Mock Implementation of that WSDL with the soapUI module, create a java application client that calls the Mock Implementation, and then finally how to implement the WSDL with a BPEL process using NetBeans.
  • The third video demonstrates how to create a simple JAX-WS Web Service using NetBeans and deploy/test it with the soapUI module.

 

You can view these demonstration videos hosted on the SoapUI website from here.

 

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

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

Posted in A Tip a Day by gsraj on May 28, 2007

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.

 Document-Literal

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:

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

My Article Nominated for JDJ Annual Readers’ Choice 2007 Awards

Posted in Sun by gsraj on May 26, 2007

 JDJ Readers Choice 2007  

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. 

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

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

Posted in A Tip a Day by gsraj on May 26, 2007

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.

Design By Contract 

Related blog entries and videos:

 

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

JBI/SOA Tips: The Wire Always Goes Forward never Back

Posted in A Tip a Day by gsraj on May 25, 2007

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 for Business Processes

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

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

 

JBI/SOA Tips: Use Separate MEPs for Business Responses

Posted in A Tip a Day by gsraj on May 24, 2007

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.

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

 

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

Posted in A Tip a Day by gsraj on May 23, 2007

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.

Message Exchange Patterns are the units of wire collaboration
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.

 

 

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

 

Follow

Get every new post delivered to your Inbox.