A Dev's View Inside the Enterprise Service Bus
Go in-depth with Dave Chappell in an Q&A on ESBs on the eve of the release of his O'Reilly book on the Enterprise Service Bus. Integration Developer News spoke with Chappell to get insights on how ESBs work, and more importantly, how they may change how Java devs look at XML, XPath, messaging and transaction-driven integration projects.
Chief Technology Evangelist
IDN: Do J2EE developers need to shift their focus to interoperability with Java and non-Java assets?
Chappell: Yes. In fact, it makes an engineer more marketable if they can understand how Java can work in a cross-platform, service-oriented integration environment. Java is fragmented already, but there's still a core set of it that depends on the JCP, and that's a good thing.
IDN: What's a dev's first step toward getting out from this tightly bundled architecture and to something in a SOA direction?
Chappell: If you have an app server installation that has become an island of itself, you really need to start looking at integrating that with other things across your organizations. Using loosely coupled, message-based interfaces would be a good first step in that.
IDN: What skills should a Java developer focus on to learn more about integration readiness?
Chappell: Learning more about XML technology is an important thing. I hate to use the word "lingua franca," but XML is fast becoming the language of integration.
IDN: What's your view of the position of some vendors who say that developers don't need to know native XML and can rely on tools to do all that XML work?
Chappell: Certainly having tools to help you read, write and parse in XML is a requirement. But as a developer, you usually have to be conscious of what's going on underneath there, particularly when things go wrong. The good news is that integration environments and debugging tools that are very XML-aware are advancing.
Do you think that J2EE 1.4 dodged a bullet last year when it decided at the last minute to include web services and native XML?
Chappell: I definitely think that J2EE did dodge a bullet, and it was able to recover. But, there's a bigger issue here. The future of the J2EE stack today can't continue to grow and advance as well as it once did. If everything that gets added to it has to be part of that stack, it takes too much time. The stack is too heavy and rigid. This doesn't necessarily provide a fertile environment for fostering innovation.
IDN: So, is XML a key technology for developers to use to apply if-then statements across a queue, so that it applies to a message packet rather than within an internal application?
Chappell: A key factor in that scenario would be a dynamic router service that examines the content of a message, using XPath, which lets you peek into elements of an XML document and is using a declarative statement rather than writing procedural programs.
IDN: While XPath may be a steroid for XML performance, it has other uses?
Chappell:Yes. XPath and XQuery, being a superset of XPath, both give me the ability to reach down into an XML document and say, "Give me the value of the line item that is down in the purchase order sub-element."
IDN: XPath might extract "What does this visitor want from me?"
Chappell: Yes, absolutelyÃ¢â¬Â¦.and "where should it go next?"
IDN: Where would a developer make this conversion from "point-to-point" to a "meshed network" or SOA?
Chappell: You could set intelligent process flows that depend on situational context, so that at each step of the way, some dynamic evaluation goes on and determines whether or not a message should continue on its predetermined path, or that it's done and needs to get back to the originator (or some other destination that is determined to be the ultimate receiver of the message).
IDN: That seems a step above the common XPath conversation.
Chappell: It's a different way of using XPath to do business process routing based on message content and situational context.
IDN: Is the basic idea here that the dataset you are exposing becomes the trigger for rules you have pre-embedded?
Chappell: Yes, rules can be declaratively specified and made available to an ESB routing service at runtime, and the XPath parsers can also help add a further dynamic aspect by performing runtime evaluations against live message data as it travels across the bus. In addition, more sophistication conditional process routing can also be accomplished by plugging in process orchestration engines into an ESB as a value-added service that is layered on top of an ESB.
IDN: With ESBs, you're bringing these XML and other integration technologies more to the forefront, then, for better integration and more efficient deployment of J2EE app servers. Taken all together, it sound like ESBs are raising the bar on today's JMS approach.
<Chappell: Yes, absolutely. However it should be noted that this isn't just a JMS-plus-web services approach. An Enterprise Service Bus is not just a messaging bus. It's more about having an "integration infrastructure," and how developers think about how to connect applications and services in a SOA -- integrating through standards-based interfaces.
IDN: So does JMS, for instance, go away with an ESB architecture?
Chappell: Not really, but there are more choices with an ESB. So, for example, a JMS can be one of these interfaces, and message-oriented middleware is definitely an important part of an ESB architecture. But that doesn't imply that all, or even any part, of an ESB is implemented in Java.
IDN: How do you see the nature of a JMS changing? Just because it's a thread from Silo A to Silo B doesn't mean it will be used in the same way or carry the same kinds of traffic?
Chappell: JMS has evolved into something that can carry SOAP and XML messages across an enterprise, so it's not just something that is used as a pipe between two end points -- it's something that higher-level routing networks, such as what can be found in an ESB, can be built on top of.
IDN: How does JMS deal with the idea of a meshed network driven by self-directed XML?
Chappell: In a network of self-directed XML messages -- if a message goes from Point A to Point B, and it needs to go somewhere else, like Point C, everything is already in the [XML] message to tell it to go to Point C now -- including all the data that Point C will need. That's a very powerful concept. JMS by itself does not enable self-directed XML messaging, without requiring handcoding of the routing logic into the applications (JMS messaging clients).
IDN: So, does the ESB really come into its own when people think of XML as being that self-directed?
Chappell: Yes, absolutely. That's one of the biggest and most important things that makes an ESB a highly distributed integration fabric: the ability for messages to carry their own routing instructions with them, and for the ESB to able to act on those routing instructions without the need to continually refer back to a centralized rules engine.
IDN: Can JMS support that now, or will it need to be revved to support that?
Chappell: JMS itself will not be revved to support that; it's already at a level of the stack where higher-level routing concepts are being built above that. JMS wouldn't break [doing this]. That's another reason why separating routing logic from the application is so important. That's because you can even separate the routing logic from how the underlying messaging is implemented.
So, let's say I want to define a higher-level business process that says, "I go from Point A to Point B to Point C." If I can administratively configure that under the covers to go across two queue connections, then watch what happens.
If at some later point, I decide that I want that to do to Points D, E, and F simultaneously, I can change one of those [JMS] links underneath to say it's now a "publish-and subscribe" link instead of a "point-to-point" link, and that all just happens, without needing to recode any of the individual endpoints. You'd change it in the place that describes the routing for the message, or administratively in the definition of the services that are involved in the processing.
IDN: So, given that Java may or may not be part of an ESB architecture, how does a Java developer get his brain around this approach to integrating outside-the-Java-silo?
Chappell: There is a broader picture we find when we work with IT architects and professionals, and that may help the Java developer better understand the issues. When an organization wants to integrate applications, it can't just make a decision that says everything will be JMS across the whole company. Even with all the [buzz] about web services, the IT architects can't even say that everything will be web services.
There is no big switch on the wall that you can just flip one day and say "All applications will be speaking JMS, or all apps will be speaking web services." And besides, IT's staffing and budgetary restrictions [are] such that nobody can worry about dropping daily operations and embarking on a "Let's replace the entire infrastructure."
So, in this environment, where companies want easier and less costly ways to connect their applications, developers will find they'll need to bridge together these apps in a way that they (the apps) will want to be communicated with, and in a fashion that is non-intrusive.
IDN: So, that's the attraction of the ESB -- Less costly integration that takes into account the individual requirements (interface schema, rules, etc.) of an existing application?
Chappell: That's exactly how the ESB is being architected. And, while [the ESB] may certainly use some existing Java technologies, like JMS, there will be a variety of both Java and non-Java technologies that will be prevalent. The "integration architect," for example, will be responsible for integrating a various systems using a number of different technologies, which can be Java, XML and C#.
IDN: Does the use of an ESB avoid needing app server stacks installed everywhere?
Chappell: Exactly. Why put an app server everywhere when all you need is a specialized integration service?
IDN: Interesting point. So, going back to C# for a moment, how do you see C# fit into a Java developer's skill set?
Chappell: I'm not advocating that all Java developers go out and learn C#, but they may need to be aware of it because there are going to be .NET applications that they'll need to integrate with it. Even then, that level of knowledge required may depend on the level of integration you choose, which could range from writing C# code, to using Web services interfaces, to using 3rd party application adapters that don't require any coding.
IDN: As it stands now, is the notion of standards based integration still a dream, or is it a reality, especially on the topic of getting Java vendors and Microsoft to agree on evolving standards?
Chappell: Yes, it's interesting that a lot of folks are focused on "Standards Wars," and some lack of progress in some evolving nascent standards. But there are a number of standards that have been around a few years that have reached maturity, and are helping to foster standards-based integration. For instance, XSLT for XML transformation, JMS for messaging interface, and even the Java servlet API for web services integration, and JAAS and JSSE for security.
As far as getting all vendors to agree on evolving standards--I don't think that's going to happen anytime soon. However, they don't need to agree in order for ESBs to be successful. What Microsoft is building in Indigo and Longhorn will enable loosely-coupled message-driven applications, which will make those applications much better endpoints for integrating into an ESB fabric.
IDN: Right now, ESB seems to be a rickety bridge because there are so many planks missing. Critical mass is missing; vendor alignment over interoperability protocols is missing. Is there a hazard-free way to implement an ESB?
Chappell: An example of where an ESB architect can use existing technologies today and avoid falling off the bridge, so to speak, could go something like this. You can plug into an app server using a well-known JMS and message-driven bean interface. You could plug into an ERP system using an adapter that you might get from a third-party adapter company, such as iWay or DataDirect.
IDN: So, you would consider an iWay or DataDirect adapter a fully compliant ESB component?
Chappell: It would be a component of an ESB project. As a Java programmer, you probably already know JMS and message-driven beans, and you probably ought to learn about the J2EE connector architecture.
IDN: What brings those components from lower level connecting to this higher-level business process integration?
Chappell: On the implementation side of the ESB, you don't actually need to code up all that stuff; you can just plug that into a tool environment where you administratively configure how they talk to each other. That's where this new idea of an IDE for the integration architect comes into play. You're not coding JMS and coding JCA adapters; you're buying an adapter from a 3rd party, or licensing it from an ESB vendor. And you're using a tool infrastructure to administratively specify that this is going to talk to this application, it sits inside a particular ESB container and it's going to route messages inside this message queue until it gets to a point where I want it to be translated into another format. At which point, it will plug into another service, which may be a JBI-compliant transformation service that was acquired from somebody else.
IDN: From a Java developer perspective, is there any difference in the way I would work with iWay today versus using it as an ESB component?
Chappell: There is something new. Vendors like iWay and DataDirect are working with vendors like us so they're pluggable into the ESB infrastructure.
IDN: Aside from Sonic, who else is out there?
Chappell: IBM has announced its intentions to provide an ESB by the end of this year or sometime next year; and then there are other integration companies and web services toolkit companies, including WebMethods, SeeBeyond, Iona, CapeClear, PolarLake, SpiritSoft to name a few.
IDN: Can you put this new way of using adapters into a real, on-the-job perspective?
Chappell: Sure, I'll give you an example of that.
The application server vendors, for instance, continually just think that every new technology [that] comes along can be just piled on top of a J2EE application stack. Take integration as an example.
If you look at what BEA is doing. For instance, they're actually saying: "When [a developer] uses this high-level tool infrastructure, you don't have to worry about what goes on underneath there." But [I think] the developer really should [know about what's going on underneath], because when you look at what goes on underneath; it generates XML to describe routing and choreography instructions between multiple processes and places that inside a Java doc inside your Java code. Furthermore, the resulting routing configurations are compiled into class files that need to be redeployed every time a change needs to be made. An ESB allows configurations to be changed without redeploying all of the affected services.
IDN: Are you saying that putting that inside the Java doc may not be the right approach?
Chappell: I'm saying that's a really odd way to store your routing logic for your business processes. Think of having the definition of how I get from application A to application B to application C embedded in the code. I think that's the wrong model. I think they really don't completely get it that business processing logic and routing logic need to be separated from the application layer.
IDN: You don't see BEA's approach as even a baby step to get Java developers to think in terms of integration -- just Step One of an ongoing evolution?
Chappell: No, I don't think it's Step One in an ongoing evolution -- I think it's Step One toward creating a big, unmanageable mess. Down the road, if you have all your routing logic built into your Java doc and your source code that's spread out all across your enterprise, how do you deal with all that?
IDN: That's certainly a possible minus. But isn't the plus for a Java developer that he can be a workflow expert without needing to know much about how they work? The developer can use abstractions and templates -- and isn't that a good thing?
Chappell: Right. But there is this notion of a new kind of IDE called an ISE (Integrated Service Environment), where you can do those kinds of workflow-type of things. But the key difference is that the place where the information is stored is not embedded in the source code all over the place. The ISE uses a directory service or a repository, so that's more easily manageable over time. That's my point.
IDN: What types of companies or IDEs/ISEs come close to that?
Chappell: Well, Sonic does. (laughs)
IDN: OK. Are there other vendors, or are there standards that enable those tools?
Chappell: There are standards that will help enable that model, the separation of business processing from the implementation. One of the things Sonic has been involved with is the Java Business Integration effort, also known as JSR 208. JBI is really about being able to provide pluggable integration components that can interoperate with each other, and have those pluggable integration components come from different vendor implementations and house things that are proprietary, even opaque to the JBI environment.
IDN: Would you say that JSR 208 is a piece of helping Java developers move into integration more easily -- in other words, moving from learning about Java APIs to a world where you're working with Java to non-Java resources?
Chappell: That would be one aspect of it: being able to house integration components that are non-Java services. But to get back to this idea of separating the processing logic from the actual code implementation itself, in a JBI environment, an integration architect doesn't need to know the intimate details of the thing that the JBI container is holding. All you need to know is that the container holds an integration component, and you're plugging together a number of these containers into an integration architecture. It's very much like an ESB approach.
IDN: How much unraveling in a typical J2EE app deployment would a Java developer need to do to get to this idea of workflow and app logic being aware of each other but not interwoven with each other? After all, this tying together can hurt you.
Chappell: Yes, it certainly does. That's a great example; with larger corporations, with merger and acquisitions there's often a situation that even if different business units standardize on J2EE, they're often using different app servers. So, you need a more heterogeneous approach that doesn't tightly embed everything.
IDN: But the installed-based app servers, like IBM and BEA, probably don't want me to un-embed. How do I get to an SOA-friendly environment, given that tight bundling has been my standard operating procedure?
Chappell: My recommendation is that you don't try and rip out the existing tightly-bundled systems that you have today; rather that you try to convert them [using ESBs] into loosely coupled pieces that are connected into a wider services-oriented architecture.
IDN: Are there certified ESBs at this point? Aren't we kind of early for that?
Chappell: No, there's no certifying body for ESBs, but that's one of the things that JBI will help enable -- to have a standard for how those disparate pieces can plug together, so an app server installation could be wrapped as a JBI container.
IDN: Aside from Sonic, are there other companies pushing to bring ESBs into a critical mass technology?
Chappell: ESBs are coming into critical mass even without having some global standards body that defines it. And that's because ESBs aren't about the over-arching standards that define this is what a ESB is -- it's because ESBs are about all the [smaller] pieces that make it up. Those are mature enough and have standards that people can use them today. It's also because ESBs are grounded in reality. Many of the concepts of an ESB come from IT leaders who are trying to figure out how to do large-scale integration using XML and messaging and related maturing technologies.
IDN: What do you think about the middleware wars? Sun says "Middleware is dead," and at the same time IBM says, "Middleware is everywhere." Do you have any thoughts on that?
Chappell: I think Sun is just trying to do a counter-attack on IBM's "Middleware is everywhere" ad campaign. But if you look at some of the public statements that Jonathan Swartz has made, I think he is trying to say that that middleware as you know it is history.
IDN: But middleware was not really a big part of the Java conversation. As someone who's looked at the idea that Java needs to be more integratable for a long time, I'd be interested in hearing your view. Does this help or confuse the issues?
Chappell: It definitely confuses things. Is middleware alive or is it dead? I say it's alive and well, but it's dead in the sense that middleware as we used to think of it is dead. There's a new breed of message-oriented middleware that has evolved over the past few years that's very different from what the incumbent middleware vendors built in the '90s.
What we have now is middleware that has the ability to link business units across the globe and through firewalls in a secure and reliable fashion, using modern standards based on XML in a federated environment with full security, access control, and firewall traversal techniques. You just didn't have those things 5 years ago. At one point I was considering having a subheading in one of my chapters in my new book, "Not Your Mom's MOM.[Message-Oriented Middleware]."
And, looking forward, think about middleware really as a concept of having message routers that can route all sorts of messages across global organizations, whether they're based on JMS or reliable SOAP, or controlled by WS-Notification. It doesn't matter what the standard technology is; the real question is: Can this thing deliver messages to all the app end-points it needs to in a scalable fashion and do that in a standards-based way still -- no matter what the standard happens to be at the time?
IDN: Are you aligning with the right companies when it comes to pushing the ESB concept? Do you have concerns about grouping Sonic in with some crippled web services companies, or incumbent integration companies?
Chappell: That's something I like to bring up. There's a new business model enabled by ESB that's based on the idea that integration should be pervasive throughout the enterprise. That's why we like to say that the ESB is changing the economics of integration.
The traditional integration vendors have long made a practice of charging $500,000 minimum for an individual product just for the licensing, and at least five times that for the specialized consulting to make it work. Even if they do have, or could build, a distributed, lightweight integration network to change their technology to become an ESB, it's questionable that they'll change their business model to become one.
IDN: Who would you include in that category?
Chappell: IBM, TIBCO, WebMethods, Vitria and SeeBeyond.
IDN: These firms really wanted to relocate your data and rules inside their silos, didn't they?
Chappell: That's right. All it does is lead to vendor lock-in. Interestingly, within JSR 208, one of the goals of that is to foster an ecosystem where individual vendors will be able to write their value-added services into the JBI framework. So, the goal will be that it's not dependent on the entire J2EE stack. We want it to be something that more vendors than just a handful of app servers will be able to work with.
IDN: In your vision, does the SOAP envelope include only XML schema and implicit workflow, and the app logic stays on the server? Or, in the SOAP envelope, does there have to be some co-mingling between the XML messaging and the event instruction; what has to take place when it gets to its destination?
Chappell: Now, that's an interesting discussion. I think what has to take place are instructions about where to route the data and what the data means when it gets to a particular destination; that's an important concept that people ought to be thinking about. The idea is that the XML message carries with it a set of routing instructions that aren't dependent on any centralized rules engine to know how to go from place to place.
Aside from his new book Enterprise Service Bus, (O'Reilly, to be published June 2004), David Chappell is coauthor of Java Web Services (O'Reilly, 2002) and The Java Message Service (O'Reilly, 2001). As Director of Engineering for Sonic Software, Chappell led the development effort for SonicMQ, which has grown to become synonymous with enterprise messaging and the Java Message Service (JMS). Chappell has published numerous articles on integration technology in leading industry publications, such as Java Developers Journal, JavaPro, Web Services Journal, XML Journal and Network World.