IBM Points Devs at Java-to-Non-Java Integration

Over the past few weeks, IBM has left no doubt that business-level integration and workflow are not just developer add-ons anymore -- these are core platform services. IBM WebSphere and DB2 are beginning to add such cross-platform data-driven integration. Integration Developer News spoke with Websphere execs to get details on how deep IBM expects Java/J2EE developers to go with Java-to-non-Java business-driven development.

Tags: Web Services, Integration, Developers, IBM, Workflow, Business Integration, Support,

Over the past few weeks, IBM has left no doubt that business-level integration and workflow are not just add-ons anymore -- these are core platform services. IBM WebSphere and DB2 products have both added significant support for cross-platform data-driven integration.

Last month, IBM introduced a small- and mid-sized business edition of its WebSphere Business Integration Server, designed to make it easier and less costly for such companies to integrate J2EE apps and data. Notably, the "light" version of the WBIS, which will be sold as part of IBM's Express line, comes with technology add-ons to support a wide range of integration approaches (including adapters/connectors, JCA, JDBC and XML-based web services).

And, in June, BM delivered an open beta of the next version of DB2 Information Integrator software, (code-named Masala), which delivers easier, faster and even automated cross-platform integration for corporate DB2-based data. Key to the upgrade will be Masala's ability to provide real-time access and integration of both proprietary and emerging data sources, (including structured and unstructured data), as if it was stored in one place regardless of vendor -- including Oracle, Microsoft, and Documentum, among others.

If Java/J2EE devs think they see a pattern here, rest assured: You do. Integration Developer News spoke with WebSphere Business Integration Server's program manager Scott Cosby, to get more details on how deep IBM expects Java/J2EE developers to go with Java-to-non-Java business-driven development.

Interview with Scott Cosby, Program Manager,
WebSphere Business Integration Server, IBM

IDN: Does IBM intend for Java/J2EE developers to get more involved with business rules and workflows. If so, what help do you intend to provide to help them take the "next step"?

Cosby: There are two key next steps to helping developers get down that road. One, there is evolving a higher requirement for developers to not be distanced or isolated from other applications in the infrastructure; in fact, to be tied into it. In that vein, we are becoming more interested in the key concept of the ESB (Enterprise Services Bus). You can call it an enterprise central nervous system that becomes a vehicle from which a developer would put on top or pull off of services or data.

IDN: There are a lot of vendors out there talking about the "Enterprise Service Bus." How would IBM define an ESB at this time?

Cosby: As I see it now, if products are a reflection of belief of how markets evolve, I think there's a little bit of a disconnect [between how other companies see the ESB and how IBM sees it]. Here's why:

People who talk about ESBs in a narrow context as being just about web services, are really missing the broader play here. The world's systems don't work well in a service-integrated environment today. That's just not how they've been built up, which has been more message-oriented. So, when you think about an enterprise, you need to think about interacting in all the styles of integration.

IDN: So, you see the ESB as being able to accommodate the gamut of assets, including both just-designed web services, and older systems?

Cosby: Yes. That's it. In fact, along that line I see the ESB should support three styles of integration.

IDN: And, the three (3) types are?

  • Message-oriented -- It's been around for a long time, and when I go to my ATM, I know my account will go through no matter whose systems are down or up, and my account will be debited once and only once.
  • Event-oriented -- This is starting to take more of an interest around JMS (Java Message Service) and other emerging event-type of approaches to integration.
  • Service-oriented -- This is where web services are becoming more important. And, this would also include newer SOA (service-oriented architecture) designs, as well.
An ESB that will handle the needs of an enterprise today in the future has to be able to handle all those styles; that's what our customers are telling us. I can't forget about this infrastructure I have. It's not broken.

IDN: How does IBM business integration support the creation of service-oriented architectures?

Cosby: As I said, SOA is one of the elements of an ESB.

IDN: Would you consider ESB elements, such as SOA, an extension of a WebSphere ecosystem, or are they independent from WebSphere and will blend into WebSphere?

Cosby: I think ESBs are independent architectures, which are supported today within WebSphere and will continue to be. From a product point of view, we support all three types: messaging through the MQ-product family; event-oriented through event broker/message broker products; and for support of service-oriented, our WebSphere app server has been the industry's leading provider of that support.

IDN: Which professionals or skill sets are pushing this blending of architectures?

Cosby: You find [many of] them at a departmental level. We see Java developers most[ly] trying to solve these departmental challenges using web services.

IDN: How would you describe these departmental "challenges" -- as tasks or projects?

Cosby: Their challenge is generally trying to access previously inaccessible systems, typically legacy [systems or applications]-- likely to be home-grown, custom coded, and maybe even running on the mainframe. This [challenge] presents a different programming environment, a different system environment than a Java programmer is typically familiar with.

IDN: So, in the tools space, what do you see that has to happen to help developers better cope with these "SOA" approaches?

Cosby: Two things have to happen. One, the owners or developers of the siloed application have to help or make part of their application available via web services. They have to expose some of those embedded assets as web services, and that takes someone who knows that application very well.

Two, then the developer has to invoke and interact with [what has been exposed].it. But it's much easier to do that via web services than by using a hard-coded environment, or an more rigid adapter approach that ties to a particular environment.

IDN: Is this approach different than the traditional one, where a legacy owner has to expose a java API so the developer can work with it?

Cosby: There are plusses and minus. Adapters may not be as dynamic in terms of a service-oriented approach, but they're much more robust. For instance, we sell a [WebSphere] adapter for SAP. all the APIs that SAP exposes can be invoked by our integration platform that is easy to understand and consume.

For web services, you have to know which function that you want to expose, how to interface with it, what the custom formats are of the information that has to go in and out, security, and a lot of other stuff.

IDN: So, let's ask it this way. With adapters, it's long been said that the Java/J2EE developer doesn't have to know what's in back of the APIs to use them, just so long as they have the API information in enough detail. Are there differences in working with SOA "end points" as you see it?

Cosby: There is still an abstraction layer [in web services] for the developer. And the nice part of that is that the abstraction layer is built on web services as a standard. So, for example, whatever I can describe in WSDL, that should be enough for me to understand how to interact, what should be required and what I'll be getting back from the systems. That's nice because that then gives me an automatic way to understand that metadata around the interface. That means developers don't have to know the technologies underneath it, or whether the data is coming from CICS or an ISeries, but they still need to know the interfaces.

IDN: Given that description, how far up the stack does IBM Business Integration go, so far as supporting a developer's effort to go higher in the J2EE stack? In other words, do you care as much about the context of the workflow as you do about the data connectivity?

Cosby: Yes, definitely.

IDN: If that's the case, WSDLs don't necessarily help you work with customizing workflows. So, won't a developer need more than just the 'interfaces" when he's dealing with these end-to-end programming projects?

Cosby: That's right.

IDN: How do you see IBM helping developers with that transition?

Cosby: An example would be MQWorkflow. Within that [product], there are very well-defined workflow capabilities to handle whatever process may be involved. You can invoke a web service in that process, and the MQWorkflow structure provides context that keeps track of the workflow.

IDN: Have your customers been asking for your help in getting developers to more actively engage in workflow projects?

Cosby: We do a lot of work in helping to evolve standards on multiple fronts. One is to take some experience we have and apply that knowledge in a standard, such as message-based transactional types of standards. We also work with early-adopter customers.

IDN: Are any of these early adopters expressing any interest in emerging workflow standards, such as BPEL?

Cosby: We've put together a proposal to move [BPEL] forward with Microsoft and others. There are a lot of other ideas out there in the industry. It's not atypical in the web services standards evolution that different ideas come to the table at different times, and we'll work it all out over time.

IDN: How do you see the prospects for BPEL? Are all the pieces, and vendor support, in place to make that a standard that Java/J2EE developers (as well as /NET devs) rely on?

Cosby: BPEL, will evolve to be an "open" standard and as it gets widely adopted it will become very important in terms of the integration developer needing to think broader, and as you say, up the stack a little more. I would say it's vitally important.

We're at the early stages of this standardized way to describe business process execution. BPEL is pretty good in terms of how it describes flows, but there's a whole lot of complexity in flows. So, when you look at event correlation, for instance, and ask 'How do you handle that?' …that [aspect to workflow] gets a whole lot more complicated pretty quickly. As you're trying to deal with integrating not just data but process flows together, there are interdependencies and rollback capabilities you [will] want to have, and so it gets a lot more sophisticated.

But, to get started on that road, developers should get to know BPEL to learn about how they might think about those issues.

IDN: How important is it to this integration-focused view of development that BPEL and similar workflow standards be supported by all Java and .NET major players, such as IBM, BEA and Microsoft?

Cosby: It's critical. From IBM's customer base perspective, very few live in homogenous environments -- whether it be OSes, programming languages, databases, across the gamut. So, being able to have this standardized way to do this integration, regardless of the underlying technology, is very important.

IDN: So, with BPEL becoming so important, how do you suggest a developer begin to get up to speed on it?

Cosby: A couple of ways. On the IBM DeveloperWorks site in the Java zone, there are tons of BPEL articles, including some IBM co-authored with BEA and Microsoft. Getting educated about BPEL is Step One. And, you should know, IBM is committed to bringing this work into an open standard, as well.

IDN: So, in a broader context, what would you say are the guiding principals that a Java developer could use to self-educate himself about these new types of integration-directed technologies? .

Cosby: I think you'll see an absolute trend: There will be less of an importance [put] on J2EE, per se, and more importance put on how [developers] use Java to do integration tasks. I don't mean to say that in terms of a dividing line. But, I would put it this way: [In the past} the focus around J2EE has been on building enterprise-class applications -- and less on how do [developers] build integrated, composite applications. You can't do that anymore. .

IDN: So, what unlocks the brains of Java/J2EE devs to that integration-focused world? Are we coming to the end of "the more APIs I know, the better my career"?

Cosby: I can't predict the customer-demand market around that. Certainly, J2EE is still a highly valued skill.

But, if you're thinking ahead to "How do I evolve my skills, and am I tuned to the emerging hot stuff in the industry?" I think you have to pay attention to web services. It has a great synergy with existing Java skills. It opens up a whole new world or paradigm in terms of how you might do an integration. And the idea of now being able to take Java/J2EE skills and leveraging that to build new composite applications can open a whole lot of new doors. That's why web services and SOAs are things that developers should actively learn more about.