Columns

Q&A: Integration in the offing

• By Jack Vaughan
• August 29, 2003

Q&A with Gordon Van Huizen, Sonic Software

Q: Have you seen signs that Sun, the parent of Java, is taking any different tacks than in the past?

A: I think there was definitely evidence at JavaOne that Sun is taking a much more open-minded view to the Java platform on many fronts. They have initiatives in play that are attracting developers to new product areas and new market opportunities, and are taking a look at the core platforms themselves, and making what, historically, would have been perceived as radical changes. For example, there’s a new JSLR Java initiative to simplify the EJB component model, which has been an issue of debate for several years. A lot of people consider the EJB model to be too complex. And apparently, Sun is acknowledging that now, and is proactive about simplifying the EJB model so that a broader class of developers can use the Java Enterprise platform.

A: I honestly don’t know at this point. At JavaOne, we primarily focused our efforts on Sun’s initiatives around integration, and I’d be happy to talk about that. We didn’t take a very detailed look at how they’re changing the J2EE existing component models.

Q: What is Sun doing with integration that interests you?

A: There’s a new initiative called the Java Business Integration Initiative, which the initial effort is around a new JSR called JSR 208, whose charge is to develop a new component model and interaction model for business integration. The J2EE model itself was originally developed for the hosting of Web apps, and has been streamlined and is highly centered on hosting synchronous Web applications. The challenges of integration are different. They’re fundamentally different. It’s a loosely coupled model, an asynchronous model, and more a model of services that have very easy-to-understand interfaces. And the JBI initiative is an attempt to standardize and codify what that kind of component model would look like.

Q: I’m just trying to get my arms around the JJ2EE Connector Architecture.

A: The J2EE Connector Architecture, as it’s currently architected and specified, is best used to integrate with EJBs and the existing J2EE component model. So its services and its way of interacting with systems is very, very app server-centric. Over time, the J2EE Connector Architecture should probably evolve to be more abstract and allow for interaction with things that aren’t EJBs for example.

Q: Does this business integration, leave room for orchestration?

A: Yes, in fact that’s a fundamental premise. The task is to orchestrate interaction of services. There are actually two JSRs -- JSR 207 is about the orchestration itself, and JSR 208 is about the component model for hosting services that can’t be orchestrated.

Q: I’ve just made a lot of effort to learn about Web services orchestration. Which way should I go?

A: These things complement each other very well, actually. The primary model will be BPEL, which is a Web services orchestration language. The “for WS” has been dropped off as it has become more broadly known. BPEL is now moved into OASIS to become a proper standard, and it’s quite likely that it will be at the core of this new orchestration and process orchestration model in Java business integration.

Q: Sonic has a lot of Fortune 1000 customers, and in those you get a variety of developers. How do you see this panning out, this Java for two classes of citizens, if you will?

I think there will be Java for three classes of citizens, and that they all exist in the organization. There will be a view into the Java platform, if you will, for the departmental level programmers that are comfortable with VB and VB-like tools, and they don’t have to be concerned with the intricacies of transaction management and all the things that VB was designed for. There’s another class of enterprise developer that focuses on the more complex infrastructure — on the transaction management, very sophisticated middleware applications — and that class of developer definitely doesn’t go away. They’re part of the same ecosystem, and the role of J2EE going forward is to tie them together.

The third developer profile, which hasn’t been served very deeply by virtually any platform today, is what we think of as the integration architect, the person whose job it is to connect multiple systems together so that the departmental level programmers and the J2EE programmers can then take advantage of these integrated systems. And we’re keenly interested in the architectural models, technologies and standards that support that third class. That’s what Sonic focuses on, the integration-oriented developer. And the existing Java models primarily serve the middleware developers themselves.

Q: So an integration developer is a little different than a middleware developer?

A: Yes. Middleware developers in the Web app case tend to focus on how do I take a particular set of data sources, how do I take some things that I already have connectivity to, and how do I service those to the broadest group of users in a very scalable way? That’s what J2EE was built for. The act of actually tying together a number of disparate systems and coordinating better activity to then provide those data views, or those interactions up to the J2EE app, is a very different kind of activity. You have to understand the applications that are in place across the enterprise, you have to understand the security and administrative concerns, and your work is about bridging those elements and then providing a simpler form of access that another developer would then consume.

Q: Some of the counter-buzz coming out of JavaOne, some discussion of going after the VB-type developer, and some people saying, well that’s all fine, but you’re going to end up with applications that work that way, that aren’t that good that are two-tier applications, and sort of too closely attached to a database.

The reality is that there are a lot of those types of applications that need to be built, and I think the ultimate model is a model where you can build out the infrastructure across the enterprise in such a way that a VB-style developer can view the rest of the enterprise in a two-tier way, so that the complexities of obtaining data from multiple systems are abstracted from their point of view, and they would deal with this data access as if it was a database. So I think that once you get the plumbing in place across the enterprise, there’s a lot of room for developing these “two-tier” applications, and building ad-hoc applications using office productivity tools, etc. But the plumbing isn’t there today, and what we’re really focusing on at Sonic is how to get that plumbing in place.

Q: Your parent firm bought eXcelon, and you’ve incorporated some of that technology into the Sonic line. What does XML add to the bus and the messaging?

A: XML is the lingua franca between these systems. It is a key enabling technology that makes it possible to work with multiple applications simultaneously. And at this point, we’ve already seen a tremendous shift within the enterprise to emit XML, consume XML. So the ability to handle XML in a performant and scalable way as a part of the integration infrastructure is absolutely key at this point. The ability to store XML for subsequent processing, to cache XML that you retrieve from some remote resource, the ability to transform XML into an alternate format, these are all fundamental aspects of dealing with application integration, and then providing that composite view up to that two-layer app, that the departmental level programmer deals with.

Q: So it’s not just an extra step?

A: No, it becomes inherent, ultimately, and we’re early in this, so dealing with XML is still relatively cumbersome, and the technologies need to continue to evolve. Over time it will become as natural as dealing with ASCII, or having Ethernet running through the enterprise.

Q: What kind of update are you seeing with SOAP and what kind of performance issues are non-issues?

A: The adoption of SOAP continues. I would say that it hasn’t radically accelerated over the last six months. It does take a while to get these standards in place, and it will take some length of time to converge on a binary SOAP protocol. We believe that will happen within the next 18 to 24 months, and that will be an accelerator across the network. The biggest challenge, though, in really dealing with XML is how to write a program that can manipulate it. Existing programming metaphors and tools don’t deal with XML very well. This is something that’s slowly changing, but right now it’s difficult and cumbersome. That’s where the overhead is, that’s where all the processing time goes, that’s where the developer effort goes, and work needs to be performed.

Q: How do technologies like XSLT, XPath and Xquery fit into your strategy?

A: Those are the fundamental technologies. But once you get above those technologies, how does a Java program deal with XML? That’s still an open area. There’s a lot of good exploratory work being done by multiple vendors, but it’s still hard.

Q: What is Microsoft’s place in the SOAP world?

A: I wouldn’t say they’re ahead in SOAP. Microsoft is in a very powerful position to influence SOAP-related standards, and they certainly have the capacity to implement SOAP and XML-related features in their products. They’ve definitely been one of the industry leaders in terms of moving the industry forward with SOAP and XML. I think from an implementation point of view they are substantially ahead of any other vendor. They’re in the position, as most of us are, where what they implement in their products has to be commercially viable and consumable, so the Microsoft products aren’t substantially ahead of the curve with respect to other vendors’ offerings.

Q: I’ve been writing about their XML capabilities, their database, and that was in Yukon, and now that’s been moved to the second half of 2004. Does that matter?

A: In the grand scheme of things, I don’t think so. It’s going to take us years to roll all this stuff out, so a six-month delay in any given product release I don’t think will have any substantial bearing.

Q: If I were a development manager, and a developer came in who was pretty psyched about XQuery, what would I say to them? This is going to be a lot of years, just buy a book and don’t worry about it tomorrow?

A: I think XQuery is an important technology to begin working with. I think XQuery stands to be one of the primary XML integration technologies moving forward. It shows all the signs of that. That said, it’s fairly early in the game with XQuery, but I would definitely encourage some members of my development team to start working with the technology, so that we can build organizational awareness of what it is, how it works and be ready to use it as it becomes more mainstream. We’ve certainly seen products hitting the market that use XQuery as a foundational technology for doing information integration, and we believe that it plays a strong role in that. It’s also a great way to just query a set of XML documents, period. So in a scenario where you’re capturing XML data for any length of time, querying it, bolstering against it, it’s a usable technology today. We have it in our product line, and we’ll continue to enhance our support for it.

Q: Service-Oriented Architecture was big for a while, and then people began been throwing around composite apps as a term. What the heck is all that?

A: The definition of Service-Oriented Architectures [SOA] varies quite a bit, depending on who you’re talking to. But the basic premise I think everyone would agree with is that the fundamental notion of a SOA is that you have a common way to describe all of the things that you can interact with. And typically we refer to that as a service interface. It’s a way of documenting how you interface with a given application or subset of an application’s functionality, and how you would bind into it and use it.

Opinions differ on how broad the definition of SOA is. Some folks that you talk to will consider SOA as strictly being an RPC mechanism, and SOA is a modern, open, Web services way of doing RPC. Our view is that SOA needs to expand beyond that, that the SOA model needs to become loosely coupled semantically, and asynchronous. There are those that would argue that that’s a new kind of architecture. Gartner, for example, calls this event-driven architecture, and thinks that it’s distinct from SOA, but regardless, the model is the same. You have a common way of describing a service, you can store service definitions in a directory, and you can bind into a given application’s functionality through that service interface.

Composite apps, as a term, is probably even more hazily defined than that. The concern that I would have about using the term composite apps is that composite apps sounds very tightly coupled to me. It sounds like very carefully nesting a set of applications into one composite whole. To me that sounds very brittle, difficult to manage and it doesn’t sound loosely coupled. The notion of a meta application is that it is a loosely coupled set of relationships between applications that give you new functionality. If I’m implementing an automated order processing system, I could think of that as a meta application, and the various systems that I need to touch to implement this process, and what results isn’t really an application. It isn’t something you deploy to an application server, but it performs the function of an application within the organization. And that’s why I tend to prefer the term meta application.

The other problem with composite applications from my perspective is that, again, it implies a single thing that you’re deploying, that you would somehow build this composite app and then deploy it to a cluster of servers. It’s not really how business processes work across the enterprise. What you really have is a series of loosely collaborating systems and so that’s the vision we’re trying to promote. Whatever terminology ends up solidifying in the industry, we will certainly adopt, but quite clearly we believe in a very loosely coupled model where the organization has the ability to mix, match and upgrade components of the infrastructure over time.

Q: Sonic is a little bit of a difficult company to characterize. You started off pretty obviously as a messaging middleware firm, and it seems that you sallied into the same issues that people had in the ORB and CORBA days, but these things are quite different.

A: ORBs, I think it’s fair to say, never fulfilled the promise of connecting disparate applications across the enterprise. Although a lot of the right intentions were there, for a variety of reasons, it just didn’t play out that way. So yes, the infrastructure that Sonic provides is intended to couple applications across the enterprise. We tend to not think of it as application development, we tend to not think of it as composite apps, we think of it as application integration, and this is the next wave of application integration. Coming from the messaging background is a very natural place to come from when trying to solve this problem. In fact, a messaging background is where virtually all EAI players started.

The way that we moved into the space was actually at the request of our customers and prospects. They saw the standards-based communications infrastructure that we had. They saw that it could be deployed very broadly, that you could deploy lots of things, that we could connect various data centers through the Internet, that we could connect end business partners relatively easily, and they came to us and said: “Wow, that sounds like a great basis for building and integration platform. That’s exactly what we’d like to have underneath our integration platform, and because you guys are standards-based, we trust that. We trust that we’ll be able to plug in more things, we trust that the infrastructure will evolve, and we’re not interested in buying proprietary solutions to solve this problem.”

So it was our customers and prospects that actually pushed us into moving up the stack from pure messaging into providing service abstraction on top of that, and a deployment environment on top of that, and orchestration capabilities across it.

Q: Over time, will the application server companies begin to look more like you? Or will you look more like them somehow?

A: I think in varying degrees each is true. I think application server vendors will certainly run into the same issues that we did when we began connecting lots of endpoints across the enterprise; so I believe the deployment model and component models they employ will move more in the direction of an enterprise service bus, as Sonic has. And then certain app server capabilities, what can be thought of at a very high level as app server capabilities, are already present in an enterprise service bus. The ability to configure, deploy and manage all the attributes that you would associate with an enterprise application these days in a managed environment are in an enterprise service bus. Interestingly, the J2EE specification itself may extend to include enterprise service bus qualities in architectures. The Java business integration initiative will fit in with J2EE in some manner, so there will be a standards-based architecture for doing what we do in our enterprise service bus.

Q: You’re in a pretty good position to gauge some of these Web services standards and WS-I, which has Sun, Microsoft and IBM trading barbs with one another. What do you think of these major players, the way they’ve behaved with the WS standards and how it plays in with Java standards?

A: Vendor motivation obviously plays a very key role in standards definition. And because of that, there tends to be a fair amount of friction between potentially competing standards and competing vendors. In the grand scheme of things, I think that’s healthy. I think it ultimately produces a usable set of specifications. If we all agreed on Day one, we’d have CORBA again and we wouldn’t be fulfilling the goal. So although it’s easy to become restless, or be frustrated by the pace or some of the in-fighting, I think it’s just a natural consequence of trying to move this stuff forward. And in certain key areas we’ve seen a great deal of alignment around the Business Process Execution Language, or BPEL. There’s a great deal of alignment behind that at this point, and now it’s in OASIS, and at least all the significant players are behind it, as well as smaller players. So there is certainly the potential to align behind a standard and stick to it.

In SOAP, it’s been a little bit messier. The challenge with SOAP is that no one has wanted to burden SOAP by adding in too much at once, and I think that’s a good thing. The downside is that there are a lot of competing incremental enhancements to SOAP, and without having one governing body that just says, “This is how it’s going to work, kids,” it’s hard to rationalize that, so it’s taken longer.