Interview with Tyler Jewell on Messaging and Clustering Issues

Discussions

News: Interview with Tyler Jewell on Messaging and Clustering Issues

  1. TheServerSide.com is pleased to present a the latest intgerview in our Hard Core Tech Talks series. In this interview, Tyler Jewell, Principal Evangelist at BEA and co-author of Mastering EJB Second Ed., talks about using Message Driven Beans in J2EE applications, and Asynchronous SOAP; the need for clustering and different ways to cluster a J2EE server and more.

    Watch the interview with Tyler Jewell.
  2. Suppose we have a system with many Entity Beans. We would like to increase the scalability of the system by clustering it across several app servers. However, in clustered environment (or with shared db), EB state cannot be easily cached in the middle tier, each ejbLoad() will hit the database, which leads me to believe that clusters provide little/no scalability benefits for the system with many EBs.

    Any thoughts? Thanks
  3. clustering for fun and profit[ Go to top ]

    It doesn't matter if the bean is clustered when you can't grant exclusive access to the resource tier.

    In either situation the app server can't guarantee adherence to ACID principles unless it checks in everytime persisted information becomes involved in a TX.

    I am assuming that the resource tier can not change the state of the app server's cache (hmmmm I bet Oracle is on this one).

    Instead, suppose the app server has exclusive use of the resource tier and the bean is clustered. Now you are comparing the benefit of increased threading capacity (more CPU cycles) / heap space / IO throughput versus the overhead of syncing caches between the machines in the cluster (and whatever other inter-JVM chatting/multicasting/easter-egg-passing goes on). This chatting is most likely via dedicated high throughput hardware and lan connections.

    Should scale well.
  4. It depends on the clustering capability of the application server. To cluster multiple application server effectively, the participating server need to support in memory replication of stateful bean (SFSB or EB). ejbLoad is only invoked when necessary based on the status of beans and transaction type.
  5. hello testing
  6. Although most of the time I appreciate Tyler's insight in other threads, I am quite surprised that in this interview his comments concerning MSMQ and Queued Components vs. JMS/MDB are completely bogus.

    There are a couple of false assertions in his interview:
    1) Queued components are not a pure asynchronous approach to send/receive messages, as opposed to JMS/MDB which are "pure asynchronous".
    2) Queued Components are similar with an RMI approach. Even if the method parameters are serialized in a message while a sender is executing method X on QC object A, the sender waits for the response (?!).
    3) The transactional context is passed between the sender (i.e. the QC client) and the receiver (i.e. the queued component).

    In reality:
    1) MS Queued Components are purely asynchronous. For example the sender and the receiver are totally decoupled: when a sender is sending a message, the QC process does not even to be up and running. Also, when the QC is processing the message, the client is not even needed to be running.
    2) From the client point of view, working with QC may look similar with an RMI approach. However, the semantics of a QC "method call" is very different from the RMI/RPC approaches. In a RMI/RPC approach, the remote client waits for a response. In the Queued Components approach, the client does NOT wait for a response, more than that, after returning from the QC method call, the message may not be even delivered yet.
    3) The transactional context is passed from the client not to the QC but to the MSMQ service at the client side. This depends on the QC’s Transactional Attribute. If the attribute is “Required” and the client is in a transaction, then MSMQ will be a enlisted resource manager, so the message is sent to the server if and only if the client tx is successfully committed. This means that at the QC side, there will be no transaction context anymore (since the tx is already committed). Also, for QCs with Transactional Attribute = RequiredNew or Disabled of course the message will be sent to the server even if the client-side tx may be aborted in the meantime.

    There are also several things that should be mentioned about JMS/MSB approach for example its unnecessary complexity compared with QC, the lack of a passing security context in JMS messages (as opposed to QC/MSMQ), etc.

    Concerning the simplicity of hte QC approach, here is a complete example of a QC + client.

    // QC-Server.cs
    using System.Reflection;
    using System.EnterpriseServices;

    [assembly: ApplicationName("QCDemoSvr")]
    [assembly: ApplicationActivation(ActivationOption.Server)]
    [assembly: ApplicationQueuing(Enabled=true, QueueListenerEnabled=true)]
    [assembly: AssemblyKeyFile("QCDemoSvr.snk")]

    namespace QCDemo
    {
        public interface IQComponent
        {
            public void SendEmail(string subject, string body, string account);
            public void SendPicture(string subject, byte[] body, string account);
        }

        [InterfaceQueuing(Interface = "IQComponent")]
        public class QComponent : ServicedComponent, IQComponent
        {
            public void SendEmail(string subject, string body, string address) {…}
            public void SendPicture (string subject, byte[] picture, string address) {…}
        }
    }

    // Client.cs
    using QCDemo;
    using System.Windows.Forms;
    using System.Runtime.InteropServices;

    class Demo
    {
       public static void Main()
       {
          IQComponent iQc = null;
          try
          {
            IQComponent iQc = (IQComponent) Marshal.BindToMoniker(
    "queue:/new:QCDemo.QComponent");
            iQc. SendEmail ("Hello", “Hello World”, “myself”);
          }
          finally
          {
            Marshal.ReleaseComObject(iQc);
          }
       }
    }


    Thanks, Adi

    P.S. My posts are purely personal opinions that may or may not represent the official position of my company (Microsoft Corporation)
  7. So, I always like to be as accurate as possible, so let me try to clear things up:

    My statement that QC are pseudo-asynchronous are based purely on the research that I did at msdn.com that lead me to believe that transactional & security contexts were propagated from producer to consumer. But, if Adi's statement #3 above is correct, then QCs would be a pure asynchronous model.

    I think this is the only confusing point in the interview speech.

    The pure asynchronous vs. pseudo asynchronous aspect of a system doesn't elude to whether or not it's better, so claiming that QC were pseudo-asynchronous was not a depositioning attempt, just slightly misunderstood.

    BTW, what's interesting and dangerous about RMI is that you can do pseudo-asynchronous messaging with it. I haven't seen many implementations that actually use it, though.

    One dangerous situation for using pseudo-asynchronous is if a client starts a TX and asynchronously invokes a method that takes 5 seconds. After 2 seconds the client crashes. The asynchronous callback fails and the TX is marked for rollback. Since the TX demarcator has crashed, there is no immediate rollback of the TX and it will be automatically rolled back after some timeout (or just remain open or heuristically committed). This can get out of control in a hurry.
  8. For me the significance of this whole topic was lost with the choice of an example in “How would MDBs be used in a typical website?”. From J2EE, when we send a text mail, our app server has very little to do. It simply sends a request to the SMTP server to do the real work. The SMTP server queues these requests and gets around to our mail when it chooses.

    It’s the SMTP server that works out the correct mail server for the email address we have selected. It’s the SMTP server that tries to make a connection to the mail server. It’s the SMTP server that remembers to try sending the mail again, at a later time, when it can’t get through.

    If we listen to Tyler we’d use MDBs in front of all of this. For a single user, even if it is quicker for our servlet/ JSP to call an MDB rather than using JavaMail to send the request to the SMTP service, we have added an extra set of processing to our server. For a single server, we will speed up the response to one user at the expense of everyone else. If we could move the processing of the MDBs to another server then things would be better. However if we have the money for another machine, then we’d improve the site further by sticking with a conventional architecture and using the extra machine as another web server…

    What am I missing here? Is Tyler’s example is as bad as I think? If it is, what would a good example be?

    Quentin
  9. Quentin - I have a concern with the example too... glad you mentioned it because I thought maybe it was just me being a grinch. If I actually am being a grinch then at least I have company :) My concern is that, while there ARE going to be situations where this example is advantageous and valid, there are too many "if's" at work that may confuse someone new to the concept.

    As you point out you may already have an asynchronous delivery. Also in my experience its sometimes important that the user be notified of a failed email message. For example - if I send someone a password via email it may be better to notify right away that I couldn't send it (in case of a problem) - otherwise I also have to build in some kind of asynchronous reporting of this error to the user.

    A good example of messaging use (IMHO) may be in setting up an enterprise distributed logging system... where you want to send all log messages to a central processing location. Logging of course should be done as quickly as possible to incur a minimum of extra overhead. We presently use a JMS queue for this function quite effectively, and I know others do as well because I remember seeing an article outlining the same idea in one of the Java magazines.

    In Tyler's defence... email via JMS is a common example. I have heard it previously.

    Otherwise - a great interview... he's obviously a talented and creative individual. Now that he's self proclaimed champion of the Entity Bean he's my hero! :) Would love to have been able to view the interview in one show. And under Linux! Did get MS Media player running under wine, but its internet connectivity I think relies on Explorer to display things and that's a whole other can of worms.
  10. It's true that the actually delivering of e-mail is handled by mail server asynchronously, but it still takes significantly more time to send an e-mail, particularly content-rich e-mail with adv. and promotion, which could be generated out of WEB interation when using JMS.

    Another big advantage of JMS(XA compliant) is the capability to participate in global transaction to avoid inconsistency, eg. DB updated but no e-mail confirmation due to disconnection to mail server, etc.

    A better example could be sending orders taken from WEB to backend ERP system, so WEB users don't need to wait for the completion of orders processing, and the order will not get lost when the ERP system is down for maintainence.
  11. MDB Use cases[ Go to top ]


    There are a number of good use cases for MDB's (asynchronous messaging in general) in applications (apart from SMTP email) - even though not ALL applications are websites.

    Some could be:
    1) Profiling. You want to collect some order statistics for some marketing feedback - but you dont want your clients' responses to wait for this work to complete (especially if some part of the profiling system is down). Send a message with the relevent order details and some MDB can process them.

    2) Simulation of multi-threaded processing. Where you would normally have created an extra thread to do some concurrent processing, send a messages and let the MDB do that extra processing (in effect you are "creating" another thread via the appserver)

    3) Workflow. If some part of your application requires intervention (from a human or another system) for say, fraud detection (e.g. if an order value is over a certain threshold), then the asynchronous nature of sending of JMS messages and processing by MDB's is a good fit for this workflow.

    There's probably quite a few more...



  12. MDB Use cases[ Go to top ]

    Nick,
    1st and 3rd examples are good but i am concerned about second example. You won't get this type of situation in EJB architecture, even if you come across you will implement differently but not definitely with threads. We need to judge about overheads before using MDB's.

    Thanks,
    Srinivas Gamini
  13. MDB Use cases[ Go to top ]

    Good reasons ....

    Another possibilty with all these examples would be the MDB initiating and sending messages to a process engine listening for some sort of information. Some of task within the process engine can then be to either send an email or call services from the backend system using an adapter or whatever connectivity you have to your EIS system. This gives you a more automated way of interacting with your enterprise system
  14. Migration & Replication[ Go to top ]

    Is there any clustering product that supports heterogenous migration and replication clustering? The example I'm thinking of is where you are running WLI (where you would want migration) and utilizing other components in the container (where you would want replication).
  15. Hi:

    I have a Mac OS X or 10 , were do I down load the vedio player for Mac.

    Cheers
    David L. Wasler
    dwasler@yahoo.com