Sarbanes Oxley Compliance Journal

Jacques Martin

Subscribe to Jacques Martin: eMailAlertsEmail Alerts
Get Jacques Martin: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, Apache Web Server Journal, SOA & WOA Magazine

J2EE Journal: Article

The Move to SOA

IBM releases WebSphere version 6

On October 6, 2004, IBM announced the latest release of WebSphere, version 6. The next day, Jack Martin, editor-in-chief of WebSphere Journal, sat down to talk with Dr. Bob Sutor, the director of WebSphere Foundation Software, about some of the new features in this release.

Websphere Journal: Bob, tell us about the latest news on WebSphere:
Bob Sutor: We're launching WebSphere Application Server version 6, the first major release in nearly two years, and it contains, really, a tremendous number of new features that we think our customers will really be excited about.

WJ: What's your favorite feature?
Bob: The new high-availability manager. You know, if the customer's really critical business applications are running on an application server, it can cost a tremendous amount of money if that server somehow becomes unavailable.

For example, there are really two areas that you're concerned about when servers become unavailable. First, if they're not there you can't give them new work. You need to very quickly shift that work elsewhere. The second area of concern is what do you do with those jobs that were going on when the server suddenly became unavailable?

Say you're doing a big international money exchange; is that caught in limbo? How long does it take you to get that up and running again? We've been able to reduce the downtime for some transactions from what might be 5 or 6 minutes to perhaps 10 seconds or less.

WJ: How are you doing that?
Bob: It's a number of things. It's new algorithms; it's the configuration of the WebSphere clusters; and it's making sure that they are configured with network addressable storage. It's having this new manager actually being part of WebSphere. In many cases, this gets rid of the need for external high-availability managers. Since it is right in WebSphere, it has a more innate understanding of what the app server is doing and so can manage and monitor many of the internal mechanisms.

WJ: Can you describe what this manager is and how it works?
Bob: First of all, it works with a number of servers. This is definitely a feature of the WebSphere Application Server Network Deployment product. This is an extension of the failover and workload management features we had before. What the manager is doing initially is monitoring the health of the different servers, noting if they become unresponsive in any of several different ways. When it determines that one or more servers - it could be an entire WebSphere cluster - is no longer available, it can shift the work that was intended for those servers somewhere else in that data center or perhaps to another data center far away. Then what it does is it goes in and it grabs the transaction log, assuming it is available in shared storage, and hands it off for completion of in-flight work. So the new features are about greater flexibility that yield better availability, and these translate to real business benefits.

 
Bob Sutor - Dorector of WebSphere Foundation Software

WJ: Correct me if I'm wrong; it sounds like there can be significant cost savings involved with something like this.
Bob: That's right. The question I would ask of a given customer in a given industry is "If a business-critical server becomes completely unavailable, how much is it going to cost you?" This can vary quite a bit on the top end - just think financial services, retail brokerages - it can cost about $6.5 million an hour. At the low end, say consumer banking, it can cost $17,000 an hour. In that situation, those costs might be from unavailable online banking. A customer might pick up the phone and call a service center or branch. When you're working out the problem person-to-person that can get expensive pretty quickly. So anything we can do to reduce the downtime from 5 or 6 minutes to something that's just a few seconds can save our customers quite a bit of money.

WJ: I assume that this is all still J2EE, that no one needs to develop any new skills to use this?
Bob: Yes, first and foremost WebSphere v6 is a J2EE server, specifically J2EE 1.4.

WJ: When developers look at App Server 6, what are they going to see that's different?
Bob: As I just mentioned, the developer is going to see that it has the full support for J2EE 1.4. And that means, for example, support for things like JAX-RPC which connects Web services with Java artifacts. But what you're also going to see is a brand new Java Messaging Service [JMS] 1.1 engine. The new engine is completely written in Java now; in our previous release, in version 5, it was a combination of Java and some of our other messaging code. The new engine runs faster because it runs on the same Java Virtual Machine as the application and has been highly tuned.

WJ: So everything is running native now?
Bob: It's running native. And it's running closer to what uses it. So for those reasons in our tests we've seen performance improvement up to 5 times, which is significant.

The second thing they're going to see is that we've done a lot of work in improving the administrative console. In particular, you can configure the new Java messaging engine much more easily than you've been able to do in the past. One of the types of configurations that you can do now is to connect the JMS engine with a particular message queue. So let's say that you have a messaging backbone that's based on WebSphere MQ, and this is connecting to your different enterprise applications, your mainframes, and your databases. It's much easier now to tie in your application servers to this messaging backbone. It is very much, I would say, advancing the state of the art of what one can do around the notion of an enterprise service bus (ESB), which as many people know is very much a part of this evolving notion of a service-oriented architecture.

WJ: Right. It sounds to me like you may be leveraging the MQ experience into WebSphere?
Bob: Certainly. We now have over 10 years of experience with MQ. I mean, nobody knows how to do secure and reliable messaging better than IBM.

WJ: MQ is definitely the king of that space.
Bob: It's the king. And we are always leveraging this experience in any way we can. Likewise, there is evidence of that completely through the J2EE stack. What we try to do really is give people the best of both worlds. Many people think of JMS as Java-to-Java communications. For the messaging backbone or MQ types of things, people think of connecting COBOL applications with databases, that is, more generally enterprise application integration. So when you can connect Java communications to existing enterprise communications you get something very powerful. This kind of legacy enablement with new use of standards gives you something that is definitely greater than the sum of the parts.

WJ: Let me ask you a hypothetical: suppose I was an MQ shop but I was not a WebSphere App Server shop. Does App Server 6 have enough going on with messaging that I would give serious consideration to becoming a WebSphere shop?
Bob: First of all, I would give consideration to why you were not a WebSphere Application Server shop if you were using any app server at all.

WJ: Let's just say my brother worked for BEA and I gave him the order.
Bob: I would want to consider WebSphere certainly because of its new messaging engine and its connections with MQ, among many other reasons. I think that the WebSphere Application Server has the most sophisticated support for Java and Web services standards in the industry. And when you can connect that smoothly into the legacy infrastructure that you have, it's a very powerful statement.

WJ: IBM has taken a real forward leadership position on service-oriented architecture; has put the rubber to the road and actually delivered product. From what I see here, this looks like the first major product supporting SOA from IBM.
Bob: Actually, this is not the first. We have been leaders in Web services, a way of doing part of SOA, since the beginning, back in 2000. Just to give you an example: we announced with Microsoft the first Web services spec, SOAP 1.1, in April 2000, and within two days of that announcement we had code available for developers to download for free. In fact, it was on a Friday and over the weekend 400 developers downloaded that first Java-based SOAP engine. The next month we donated it to the Apache Software Foundation, thereby kick-starting the whole open source Web services work to follow. We put it in the next release of the WebSphere Application Server as well. So, in some cases, WebSphere products are on perhaps their third or fourth generation of Web services standards.

The product we introduced last April, WebSphere Business Integration, includes support for BPEL, Business Process Execution Language. That is opening the door for people doing what we call service choreography, essentially a form of service-oriented integration. That product had strong SOA features and demonstrated our commitment to delivering key SOA features for what we call the foundation of the platform. WebSphere is designed to build applications on top of it - some by us, some by customers and business partners. We estimate that there are approximately 3,000 ISV solutions that run on top of WebSphere. That's coming from about 1,300 partners that are certified with WebSphere skills, not to mention how many more there might be that just haven't gotten their certifications yet.

It's important that we include these capabilities in the application server because this is the base, this is the foundation, on which so many other people will build. They are expecting to leverage this plumbing that we are building into it. We're master plumbers!

WJ: When you look at Application Server 6, how do you see the migration going?
Bob: I think customers will migrate for several reasons. I think they will do so for the high-availability manager. They will migrate for J2EE 1.4. It's been a little while since J2EE 1.3 was new and I think a lot of customers are ready to move on, particularly because of the Web services support.

Version 6 has very good coexistence with version 5. By that I mean, let's say a customer is running a cluster of version 5 application servers. They're all in production. Now, it can sometimes be a little scary for them to consider upgrading software if that means taking multiple servers out of production for a little while and then bringing them back up. It's time-consuming, and it's time that might mean there is some money lost. When you have a cluster of servers that are now at the version 5 level, you can systematically upgrade the servers one by one. Version 6 will happily understand that there are some version 5 servers and that the version 5 servers can do some things while the version 6 servers can do other things.

WJ: That's going to be very easy then.
Bob: I think for many customers it's going to be easier than its ever been in the past. Once they decide to make the jump because of the "must have" features in version 6, they'll be able to do it in a systematic way at their own rate.

WJ: You have a whole bunch of new wizards and all kinds of things to help people develop faster than they used to; that's a kind of standard thing that comes out of IBM every day to make developers' lives easier. But I get the sense that there is something very different going on.
Bob: We have really been spending a lot of time looking at the daily activities of developers who use WebSphere software. By that I mean that we are always asking ourselves what we can do to make developers' lives easier and how we can make those developers more efficient. One of the things that we've added in version 6 is what we call WebSphere Rapid Deployment. It basically says, you can go in, you can edit a Java file, and in order to deploy it, you can pick it up and drop it in a directory. We do ask that you add some hints to the source files so we understand what you intend that code to be for, say part of a certain type of Enterprise JavaBean. Once it goes into that directory, WebSphere can look at it and say, ah, this is a new file or it's an updated file; I know that I need to wrap it with a certain amount of code and compile it. I need to put it in a certain place and everything else it needs in the right locations. It really simplifies the process of writing and deploying code so that you can quickly test it and repeat the cycle if necessary.

There are other improvements in the tools themselves. We've improved the wizards. And in fact, we've improved the wizards so much that with many standard development activities, we've been able to improve the efficiency by about 75%.

WJ: Seventy-five percent is an enormous reduction. Where would someone be expected to find and pick that up right away?
Bob: You can expect to see that, for example, when you are starting a new project or a new piece of code within a project. Say you were going to create a Web service. Well, you can certainly start and you can write it all by hand with everything it might require. You might have a wizard that helps you do a little bit of this job. What we're saying is that we have gone through and we have systematically looked at the wizards that are in the tools. We've also tried to understand what additional wizards were necessary so that we can do a maximum amount of work for you, with your guidance. We hope in this way to make available the incredible features of WebSphere while ensuring that the simple things remain simple to do. You will always have to go in and customize your particular application, but we try to do the best job we can to get you as far along as possible.

WJ: And these wizards are located where? Do they come inside of App Server or inside of Studio?
Bob: They are in the tools. We rebranded some of the tools, by the way. WebSphere Studio Site Developer is now called Rational Web Developer for WebSphere Software. WebSphere Studio Application Developer is now called Rational Application Developer for WebSphere Software. The wizards live in those two tools.

WJ: When someone walks away from hearing this announcement, Bob, in your opinion, what are the three most important things they should know about WebSphere Application Server 6?
Bob: First of all, WebSphere Application Server is really part of the foundation for building an on demand application infrastructure.The features for high availability and secure, optimum use of resources are part of that.

The second is that version 6 has the key building blocks for service-oriented architecture. This product is going to be absolutely at the core of how our customers implement their service-oriented architecture. And that's by support of the latest Web services standards and optimizing use of the new Java messaging engine in addition to your current enterprise messaging solution.

Finally, I want people to walk away knowing that we're very focused on rapid development and deployment. We've tried to make sure that right out-of-the-box, this application server is tuned as much as practical in the ways our customers are going to want to use it. That is, we want to make sure that the default installation is going to be pretty close to what people want right from the very beginning.

More Stories By Jacques Martin

Jack Martin, editor-in-chief of WebSphere Journal, is cofounder and CEO of Simplex Knowledge Company (publisher of Sarbanes-Oxley Compliance Journal http://www.s-ox.com), an Internet software boutique specializing in WebSphere development. Simplex developed the first remote video transmission system designed specifically for childcare centers, which received worldwide media attention, and the world's first diagnostic quality ultrasound broadcast system. Jack is co-author of Understanding WebSphere, from Prentice Hall.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.