Tell us a bit about yourself and what you do at BEA?

I've been working for BEA for about five years. I've worked with education services. I have worked with all the products of BEA, which we now call as the platform suite, so WebLogic Server, Portal, Liquid Data, which is the newest product, WebLogic Integration, which is based on the messaging framework.

What does messaging mean to you?

Interesting. Well, when we talk about two applications communicating with each other, sending information to each other, there are a couple of obstacles which are involved. First of all, the main obstacle is that these two applications have to be connected to each other, which means that we are looking at both applications being active at the same time. Let's say we have a requirement or a scenario where we have one application, which needs to send the same information to several different applications, we are going to do that, we are going to first send it to one, then send it to the other, we have some kind of a redundancy there for the same information. To me, what messaging is, it's a framework basically, which enables these two applications to talk to each other, overcoming all these hurdles. Some mechanism where, we really don't care about these two applications being active at the same time, but we want to get the job done as if they were connected at the same time. That's really what messaging or what I would say is I would call it a framework and that's what I would tell messaging as.

What are the different approaches to implementing messaging?

I am going to take an example here, first of all, the way messaging framework works, the example I really like to relate to is some of the shipping companies. I am going to take FedEx as an example. When we send, as a consumer, we send a package, let's say I want to send something to you. All I have to do is, I have to first of all choose the appropriate packet. FedEx gives you envelopes or boxes or whatever. Based on what I'm sending you, I just choose an appropriate packet, put your name, address, pay the money, and then I am taking away the responsibility of sending it to you and giving that responsibility to FedEx. In the messaging world, it's the same thing. In the messaging world instead of calling it FedEx, we call it the Message-Oriented Middleware, and that's the MOM Server. The person who sends the package, we just call that particular client as the producer and of course it has to be delivered to someone, so that's the consumer at that point. However, it's not as simple as saying, "Oh well good, we have a producer, we have a consumer." In the messaging world there are a couple of things and one of the obstacles which I mentioned earlier was one application having to talk to multiple different applications with the same information. What the strategy, which is used in messaging world is that, you can have both. You can have peer to peer, which is really the point-to-point and you can have a public subscribe, which is one application sending a message to multiple. Now considering that you have these two, the MOM Server has different components that it uses in order to support these two different strategies that we call it as domains.

For what use cases would a point-to-point approach versus a public subscribe approach be more applicable?

Again, I am going to take an example here. First of all, the FedEx example, which I just gave is a point-to-point because obviously I don't want the packet to be cut into half or given to different people. That's the point-to-point. The public subscribe would be something, again I want to take BEA as an example here. Let's say we have these promotional things we run for our customers and we just go and say, "All right, we have these 100 different packages, let's just randomly pick 100 customers and send it to them," that's something which would be a publish/subscribe, where we have one company like BEA sending several different customers the same information. Being realistic in the software world, what I would say is all of us get these spam e-mails and I am pretty sure you can relate to this, because there are companies and if you subscribe to a particular magazine and again let's take TheServerSide! You subscribe, you tell this particular application, "Hey, I'm interested in listening to what you have, I want to see what are the new things which you have," so you subscribe to this magazine and then once in maybe a week or twice a week you get these e-mails, which say, all right, this is the new information you were interested in. That's again a publish/subscribe. That is one message being sent to everyone who subscribed to that particular topic or to that particular magazine. These are examples where you have point-to-point and based on what the application requires, based on whether you want this message to be sent only to one or this message sent to several, you would decide whether you want a point-to-point or publish/subscribe.

And how do these concept map into Java?

That's the nice part, because messaging is, first of all, you don't really go and write your own proprietary code, J2EE provides JMS specification, Java Messaging Service, and what does that mean, it simply means that you have a set of interfaces, a set of methods, APIs, which are well defined. If you have a vendor saying that, "Hey, I implement or I am J2EE certified," you're basically looking at portability at that point because JMS is part of J2EE. JMS is nothing but a set of APIs. You need definition for messages. It does not help anyone if a producer creates a message where the consumer can't understand it. You need a message structure, what do you want to put in this message. You need methods to send this message to receive it. Those are the things, which JMS provides and the reason why it relates to Java is because obviously we are talking about building this in a J2EE world, we are talking about a J2EE specification. That's really where messaging would fit into a Java world.

How does a developer make the leap to messaging from synchronous approaches?

In my opinion, the first thing I would start looking at is, do I have logic, which is event driven. The moment I say, "Oh well, I need something which is event driven, so I am not going to actually call a method, but if something happens I need some message or some information sent, based on which I am going to trigger some code," that's the first signal to think asynchronous. When we start thinking asynchronous, that's the first signal to think, well, there is something called JMS. That's the first thing I would look for. The second place where I would think as a thumb-rule one should think of messaging is in a process world. The reason I say that is because processes or the implementation creating these process definitions are very popular these days with still not being the paradigm and all, but when you think of a process, and the example I am going to take here is a credit card company. Again, we can all relate to it because at some point we've gone through this. Either we call in a number, 800 number, or we send some kind of an information via a form and we say we are interested in getting a credit card. We don't get it. What we are told is, it's going to take three weeks. Why? Because now the credit company is going to go to external resources, check the credit history, and get the credit score. Based on the credit score, the person is going to say, "No, this is really bad, I am going to decline it" or may be assign it to a supervisor who is going to then decide, "Well, this is not really good, so I am going to give a low-credit limit." This is the process we are talking about. If I want to do something like that, there is no way I can do it asynchronous, why because the credit card company might have their systems down, so there is no way I am going to have the client wait on the phone for a month. I need some mechanism to do this asynchronously. That's a sure place where you want to think messaging, but what I am really talking about is the underlying technology, how is it internal, if you're building web service, what are the vendors doing, how are they implementing the asynchronous behavior and by in large you find that it is using JMS in a Java world.

Are there reasons to use JMS within the JVM or is it mostly for remote asynchronous communications?

I can find several examples where it could be useful, but the way I would put it is there are several other technologies, which can be used locally within the JVM, but one example which comes to mind is, let's say, JMX, and I am talking about Java Management Extension here, is a really big specification. These days most vendors are implementing their infrastructure using that and the example I would give is for an administrator. Often I find questions when I talk to administrators, we need some kind of a notification sent to us; however, we don't want to be disturbed in the night by sending a pager or something like that, like a cell phone or anything like that. What they really want to do is, they want to have a central repository where all the messages are sent and then they just go the next morning and browse through that repository and take a look at what is going on. It's very easy to do this I know with SNMP and things like that, but let us assume we don't have any of that. We have all the specifications provided by J2EE, how can we achieve what we want to do? JMS is a very good technology to use. What you could do is write JMS clients reading these log files and then just send a message to queue or a topic. Next morning, the administrator just goes and browses that. You could write JMS client or some code to enable that administrator to browse that, may be some vendors provide utilities to do that, but that's where I would see that we always talk about communication between applications, but sometimes you might use it just because you are maybe low on resources, you don't have proper products to achieve what you want, and that's where I would see maybe JMS could be used.

What are the various approaches to asynchronous messaging in J2EE and how would one choose one over the other?

First of all, for asynchronous messaging one does not really have to use JMS. I could go and write my own code and maybe use a database for persisting certain information, which I want. How difficult or how easy it is, well, you don't want to do that, because you are going to, first of all, write all the code, you're going to maintain it. Portability is a big issue because, let's face it, when we write code ourselves we are going to have some proprietary classes there because we are not going to go and write every single code right from the foundation and we want to stay away from that, especially when we talk about a J2EE application. So having said that, is JMS the best or is it what would be the best way to go? Absolutely, because it is part of the J2EE technology and like I said, I am not talking about the implementations. I am not saying that you have to write a JMS client, but what I am saying is, if you're writing asynchronous web services, you might want to take a look at how that is implemented with the vendor you're going and publishing this web service, which you're using as a service provider. That's where I would say JMS is very popular only because J2EE 1.3 app servers are implementing JMS by default, reason being EJBs, you have a message through a bean. You're not really going and buying extra stuff. You're just using what you already have and you're buying an app server when you talk J2EE, so why not make the most use of it and that's where I would JMS is definitely what is commonly used.

How do J2EE Servers implement MOM or Message-Oriented Middleware concepts?

When we say that J2EE app servers implement or are MOM Servers as well. When we talked we spoke earlier about point-to-point and publish/subscribe and I said that the messages sent to this MOM Server and related it to FedEx. What is this MOM Server and what does it mean to have a MOM Server? In a point-to-point, when a producer sends this message there has to be some component on the MOM Server to store the message because we also saw the obstacle of the other application not being active and the component used or the term used is a queue. In a publish/subscribe, it's a topic. The very fact that I say there is a queue and a topic, there has to be an infrastructure to maintain it. When we say app servers implement or we call messaging servers, at times, which are not app servers but only messaging servers, the whole concept behind that is it has an infrastructure built-in to create these queues, create these topics, create connections to these MOM Servers, so the producer can send the message, consumer can receive the message. Certain things like, again back to my analogy, FedEx stores this packet for you. Same way, the app servers need to have some persistent storage so that the messages are not lost and that's what it really means to implement a MOM Server within an app server.

How does WebLogic Server implement guaranteed message delivery?

Excellent point actually, because we always talk about messaging and I have come across so many different customers who always ask me, what happens if a message is lost. That's the really good part about JMS. I am going to start with JMS first and then I will get into WebLogic, the reason being JMS has a concept or a feature built in within the specification called the guaranteed message delivery. What it really means is, if you say that you are a vendor who supports or implements the J2EE technology and JMS, you have to support guaranteed message delivery. The way WebLogic supports it is you can control or configure where you want to store this message and we give two choices. You have a file store and a database store. The moment you say, yes, I want to store it, automatically WebLogic says, this is a message, which cannot be lost; it has to be delivered. It then goes and stores it automatically within one of those stores, you can obviously control the table you want and things like that, but that's really how WebLogic has implemented guaranteed message delivery.

The server you are calling is a point of failure when taking the synchronous approach, what about the asynchronous approach with messaging? What support is there for, say, clustering and failover?

Very interesting actually, if you has asked me this three years back, I would have said, "I don't think we have one," but over the years JMS has evolved a lot and in fact there is clustering for JMS. It's just the way it's done is obviously different for different vendors and I am going to take WebLogic as an example. We have both load balancing and failover, but what we do is, with JMS involved it is very difficult to say that I am going to send a message to three servers in a cluster, the reason being, let's take an example of point-to-point, where I said one message can be consumed only by one particular JMS client. I send this message to three servers because I am worried about failover or I just believe that what if server A goes down? However, in this scenario, we also have another issue. If the same message is in all three servers, what if there are two consumers going at the same time to Server A and one to Server B, what happens then? We don't want this message to be processed by these two different consumers because it's a point-to-point. What we have done is, we have a concept called Distributed Destination. You have a distributed queue and you have a distributed topic, and all that means is it's a logical grouping of these physical queues or physical topics and this particular Distributed Destination, which is a logical destination, has the algorithm to send the message either to a particular queue in case of point-to-point or in publish/subscribe sends to all the topics because we really don't care in a publish/subscribe. That's the whole point of the domain. This logic is built into this Distributed Destination component as just another object, which sits there. The developer instead of using the physical destination simply uses the Distributed Destination or rather I should say the JNDI name of this Distributed Destination and then internally WebLogic does the load balancing. With the failover, you have a concept called migration and all that means is you preconfigure, if there is a source and a target or a destination, you just preconfigure that and if the source goes down, you just simply go and say, "Oh well, now go and send all these messages to the target" and then the destination or the target server goes and processes those messages. When I say you have to go and hit the migrate you can automate that by creating events and things like that, but it's a preconfigured option, which is available.

Can JMS be used to solve extreme high volume problems such as stock exchange examples?

In fact, that's the exact example I would take. I have this, I should say, a very interesting scenario, which I would like to share and this is quite some time back, it was prior to when J2EE became very popular and things like that, but the interesting situation was there was an application where there was a database and all these applications, which required the information would poll the database and they would just scroll whenever they needed it to the database and we all know that we want to keep the request to the database to a minimal. Just assume that you have 50 applications going and saying, I want that information, and they are looking for the same information. That is a strain on the database and I would say that's not a good practice because you are in for a performance problem at that point. What I would say is, that's where JMS would come and your example of stock, I am going to take the same example. We go to the stock application where we go and give a symbol. Obviously we know there are thousands of symbols and we don't really care about the others, maybe I am a trader and I care about 20 of those symbols. That's a very good application where I would implement using the messaging framework, I would create maybe different topics and those 20 symbols which I am interested in, I would just go and subscribe for them, so I get the information about it and I don't really care about the 980 other symbols which exist. Just answering your question, I think messaging works, in fact, one of the places you might think of messaging is where you have a lot of transactions taking place. I am not saying you do not require synchronous, all I am saying is, you have to decide is this information available to a lot of applications, then maybe messaging is the way to go, but if I have one application which randomly goes and does polling to a database, I probably wouldn't use messaging at that point.

How do you see messaging fitting into Service-Oriented Architectures?

First of all, SOA is the big paradigm now and I see a lot of customers actually building their applications using the architecture, but with SOA, we often say SOA is web services, but really SOA is not web services. There are other components, but for a moment, let's just say SOA is equal to web services, so everything I do in this application is going to be web services. Web service is the first and foremost thing is well, I have these two services, which I implemented on different operating systems, let's say, BEA and Microsoft, so .NET server. However, I still have a problem there. What if these two web services are not active at the same time? What if they can't communicate with each other at the same time? What if I need a mechanism to upgrade one of these applications because one of the services needs an update? I have a problem at that point. Although we are looking at web services, but what internally might be happening, which is what BEA is doing is we are using JMS. We have, internally, message-driven beans, which we are using to implement this asynchronous behavior between these two services. Now, I did say that SOA is really not equal to web services, what are the other things you can implement? I spoke about process definitions before. That example, which I was talking about of the credit card approval, I could build services around that. One of the services I could have is "get credit report." This service obviously we know, is asynchronous. How do I implement it? I need JMS or messaging framework for that. In fact, what I feel in my experience and in my opinion is that SOA is going to make JMS more popular than it was only because of the fact that we need a framework to implement asynchronous activity for all these services and in a J2EE world, obviously we talk about web services also in a non-J2EE world, but in a J2EE world, the best way is using JMS because we have the infrastructure. So, we are not going and looking at something new. We are not at a point where we have to say, "Oh! We have this problem, now we need to think of a solution." We have a solution, we just need to use it. That's where I see JMS being very popular with SOA.

What is WebLogic's messaging offering?

First of all, WebLogic does implement JMS. Everything we've spoken about, queues, topics, connecting, it's a full-fledged MOM Server, but what I also mentioned, we do have clustering. We have certain features, which are very helpful, one is flow control and the biggest, I would say, one of the key things a customer would look for is performance. "All right, all this sounds great, how is it going to perform?" We have flow control for that so that the server does not have N number of messages coming in per second, but you can control that, you can give a threshold, so then the server says, ok, I am going to start reducing that. We also have a very, very useful feature called the messaging bridge. What that does for you is, WebLogic is a MOM Server, great, now let's talk about, let's say I have this application spanned across regions. I have the same app in New York, I have one in Boston, one in Chicago. I don't want to use the same MOM Server across these three locations because I am really in for a performance problem at that point. What we have is this messaging bridge, which allows MOM servers to talk to each other and synchronize the messages on the queues or the topics, whatever you configure. How does that help? You could now have a gatekeeper. You could have the New York server send it to this gatekeeper, Chicago server, Boston Server do the same and this gatekeeper really becomes the central repository. This is a built-in feature. Not just that, let's also talk about, say I have a messaging framework, which is non-J2EE and I want to use it. Messaging bridge allows you to connect to a non-J2EE MOM Server as well or a message infrastructure, I should say, at that point. That's another feature which is available. You could have multiple servers running and then you have these queues based on Distributed Destination, we have the concept of pooling. It's similar to all the other pools we speak about, but the only difference is, you can have multiple threads either sending or receiving messages. There are a couple of neat features, but I would say one of the most popular is the clustering feature.

What are some key new features coming in future versions of JMS and WebLogic JMS?

With the JMS specification, one of the things which is going to come out is common interface, common API. Right now, you have APIs for queues, you have APIs for topics, and what really is being worked on is a common API for both, just making life easier, I guess, for developers. That's really what the specification has, but what WebLogic is doing is we have several new features. I am just going to name a few and tell you what it's all about. Right now, when you implement JMS, it is a different component. You have your enterprise application and then you have all these different components, which are separate from your enterprise application. They go into the server configuration file and things like that. It would be really nice to include all that information within your enterprise app, why, because when you move from one environment to the other, everything is in one package now. We have the concept of deployment, which is modular. We know about the Java module, we know about the web apps, we know about EJBs. Now, you're also going to start hearing about JMS modules. Like the other deployment descriptors, we have XML file, which is the deployment descriptor for your JMS module. All you're worried about is this one package. You do have the option though because we realize that there are customers who might want to upgrade from existing versions and may not be very happy going with this modular way, so you're still going to get deployment of the JMS, which is separate but you have a choice. The other cool feature is the store-and-forward. What if you don't want to talk to a remote server or if you want to have something locally? I just spoke about that gatekeeper feature, now that is something we have to implement, but that's going to be something you will get out of box with the product and we call that as store-and-forward. You just simply send it to the local server. The local server is going to take care of forwarding it to a remote server. The other neat thing, which might not be a big deal in terms of a new feature, but it's really a big deal for developers and that's a unified distributed destination. What that means is right now I said distributed queue or topic, you are going to have one component, which you could work with in either of the domains. Another cool feature is it's really a UI enhancement. Many times we have heard our customers say, "Hey you have this great messaging server implementation, but I want to go see the messages. I want to go and see, maybe a message should have been sent and if it does go now, it doesn't make any sense, I want to control that kind of thing." We are giving that. We are giving UI enhancement so that messages can be seen. We are also giving enhancements of stop or pause, I should say, pause-and-resume destinations, so you might want to say, I just want to stop processing these messages for a while because I know that it won't work or whatever the reason might be. That's coming in the next version of WebLogic. That's a cool feature, I think, which administrators would like. We are catering to the different roles, developers, administrators, just trying to make their life easy. The rest will just remain, clustering is going to still remain and of course, we are going to implement the latest JMS specification.

All right, thanks.