1 2 Previous Next 20 Replies Latest reply on Jan 19, 2006 11:28 AM by Kurt De Wit

    non-java clients

    John Fawcett Newbie

      Hi,

      I worked on an open protocol for the old jbossmq (http://csil.sourceforge.net), which only runs in jboss3.2. It encodes messages in an xml format, and provides a library for c# to connect to jbossmq. I've been using it in production quite successfully for the past two years.

      Last time around, I did the design in isolation, and built on top of the UIL, which was replaced by the UIL2 almost at the same time that I finished the first version of the new protocol. I was hoping I could get some additional guidance this time. I and another collaborator were granted cvs access to do this work. Circumstances got the better of us, and we didn't make much progress porting from UIL to UIL2. However, I now have time to work on jbossmq, and I'd like to dive in again (assuming I haven't worn out my welcome).

      To get started, I have a few questions:
      First, should I abandon the idea of porting the code I wrote to be based on the UIL2?

      Secondly, would a language independent protocol be a new facade, or would I add a component to the JMS facade?

      thanks,
      fawce

        • 1. Re: non-java clients
          Adrian Brock Master

          According to sourceforge you still have cvs access:

          http://sourceforge.net/project/memberlist.php?group_id=22866


          For JBossMQ it would be integrated as an IL like you did before, but not using
          the buggy old UIL code as a basis.

          For the new JBoss Messaging, I guess it would be done as a facade
          and probably integrate through JBoss Remoting? I'll leave Ovidiu to
          discuss it with you.

          If you are going to add code, you need to support it, or find somebody else
          that is going to support it.
          Stuff that is unused/unsupported generally gets removed.

          • 2. Re: non-java clients
            John Fawcett Newbie

            Adrian,

            Thanks for the direction. I am anxious to move off of the UIL, so perhaps I should start with the UIL2 port? We have to support the library now anyway, as we use it in production. We'd really benefit from broader use, so that issues get flushed out sooner. So, in other words, we're ready for the responsibility.

            How much life would you say remains for the old jbossmq? I'm just trying to guage whether a UIL2-based protocol will have much of a lifespan. Will the existing jbossmq and UIL2 be in jb4.0? (Is there a place of reference for this, sorry if I am asking a dumb question).

            Regarding cvs, can I just cut a branch to work from? What should I use as my branch point?

            On the implementation, my plan was to actually modify UIL2 to not use ObjectStreams, and to accept additional configuration parameters to either use the existing java oriented message encoding, or the new message encoding we would add. Alternatively, I could create a new package and completely separate IL.

            thanks,
            fawce

            • 3. Re: non-java clients
              Adrian Brock Master

               

              "fawce" wrote:

              How much life would you say remains for the old jbossmq? I'm just trying to guage whether a UIL2-based protocol will have much of a lifespan. Will the existing jbossmq and UIL2 be in jb4.0? (Is there a place of reference for this, sorry if I am asking a dumb question).

              http://www.jboss.org/wiki/Wiki.jsp?page=JBossMQ


              Regarding cvs, can I just cut a branch to work from? What should I use as my branch point?

              On the implementation, my plan was to actually modify UIL2 to not use ObjectStreams, and to accept additional configuration parameters to either use the existing java oriented message encoding, or the new message encoding we would add. Alternatively, I could create a new package and completely separate IL.


              Just create a UIL3 (or whatever you want to call it) in jboss-head.
              Under no circumstances should you change the wire format of UIL2.
              That would break backward compatibility.

              • 4. Re: non-java clients
                Ovidiu Feodorov Master

                To get an overview of the JBoss Messaging architecture, go to http://www.jboss.org/wiki/Wiki.jsp?page=JBossMessaging. You'll find there Messaging Core and JMS Facade design documents. This should give you a pretty good idea where your layer might fit in.

                The most straigtforward way to implement it is probably a new facade. You can call it CSharpMS or whatever you want to call it. You'll need a server-side facade layer that hooks into JBoss Remoting and also code that translates you XML traffic into messages/management traffic. Your interface layer must know how to interact with the Client Manager, Destination Manager, and so on.

                Take a look at the org.jboss.messaging and org.jboss.jms packages under the jboss-head/jms project.

                As for the lifespan of JBossMQ, the plan is to be replaced by JBoss Messaging as soon as the later proves to be production ready.

                • 5. Re: non-java clients
                  John Fawcett Newbie

                  Having mulled it over, my plan is to first implement a new IL based on the existing csil wireline protocol, in the original jbossmq. Thanks for the guidance.

                  • 6. Re: non-java clients
                    John Fawcett Newbie

                    Hi all,

                    Well, it took longer than expected, but XIL2 is finally ready. XIL2 is a new language-neutral IL from the CsIL project team. It is finally ready for download.

                    XIL2 runs in jboss4 and is based on the UIL2 structure, but uses xml encoding.

                    Because we moved so slowly on implementation, my cvs commit rights have vanished, so I've posted the new stuff to the csil project on sourceforge. I'm hoping the JBossMQ team will find it sufficiently useful and high quality to consider adding it to the jboss cvs tree.

                    csil homepage: http://csil.sourceforge.net

                    thanks,
                    fawce

                    • 7. Re: non-java clients
                      Ovidiu Feodorov Master

                      Thanks.

                      Have you considered porting it to JBoss Messaging?

                      Messaging is using a completely different transport approach, it uses JBoss Remoting, so I won't be able to use an UIL2-type transport with it.

                      • 8. Re: non-java clients
                        John Fawcett Newbie

                        I've considered it, but I haven't hit upon a good solution.

                        I've read your architectural summary (the power point slides, which were very informative). The slides gave the overview, so I didn't see a clear point in the architecture to abstract out the wireline protocol. Can you give me some advice?

                        One thing that I was unclear on is the role of JGroups. Will all the messaging be conveyed by JGroups? If so, that would make JGroups the point requiring abstraction, and I remember JGroups being very java centric -- doesn't rely heavily on object serialization?

                        Lastly, won't JbossMQ be around until Jboss7 timeframe? So says the wiki.

                        Ultimately, I need messaging integration for jboss and c#. I am hopeful that jbossmq and csil will remain in use for a few/several years, and allow time for a port to jbossmessaging.

                        • 9. Re: non-java clients
                          Ovidiu Feodorov Master

                           

                          ... so I didn't see a clear point in the architecture to abstract out the wireline protocol. Can you give me some advice?


                          The facade client-side sends invocations (org.jboss.aop.joinpoint.Invocation) into the server. See org.jboss.jms.client.delegate.DelegateSupport:

                           ...
                           InvocationResponse response = (InvocationResponse)client.invoke(invocation, null);
                           ...
                          


                          where "client" is a org.jboss.remoting.Client instance.

                          The invocations are marshalled/unmarshalled by JBoss Remoting http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jbossremoting. Conceptually, the whole mechanism is relatively similar to the invocation layers.

                          One thing that I was unclear on is the role of JGroups. Will all the messaging be conveyed by JGroups? If so, that would make JGroups the point requiring abstraction, and I remember JGroups being very java centric -- doesn't rely heavily on object serialization?


                          No, JGroups has nothing to do with the front end transport. It is used for back-end multicasting/replication, the client-side doesn't need to know anything about JGroups. Not unless Remoting chooses to use it, anyway.

                          Lastly, won't JbossMQ be around until Jboss7 timeframe? So says the wiki.

                          Ultimately, I need messaging integration for jboss and c#. I am hopeful that jbossmq and csil will remain in use for a few/several years, and allow time for a port to jbossmessaging.


                          Yes, that's correct.

                          OK, let's keep then porting to Messaging on the back burner. I will create a JIRA task not assigned to any release yet with you as owner, if you wish.


                          • 10. Re: non-java clients
                            John Fawcett Newbie

                            Thank you for the feedback. Please create the Jira for me.

                            I will need to do some code reading to understand fully how to proceed with Jboss messaging. One question I would like to figure out is what the pattern would be on the c# side. Would I still be trying to create a JMS-style messaging system? In other words, could I re-use the csil JMS code base, and just focus on the lower level connectivity?

                            • 11. Re: non-java clients
                              Ovidiu Feodorov Master

                              This is the JIRA issue http://jira.jboss.org/jira/browse/JBMESSAGING-196. I don't know your JIRA id so I cannot currently assign it to you. You probably can do that yourself. If not, let me know your id and I will do it.

                              You should start with reading a bit about Remoting. A Marshaller is probably what you want to write.

                              I am standing by to answer your questions.

                              • 12. Re: non-java clients
                                John Fawcett Newbie

                                I just logged into Jira for the first time as fawce.

                                • 13. Re: non-java clients
                                  Scott Stark Master

                                  John is the reporter of the JBMESSAGING-196 issue now. Once there is a proposed implementation it should be attached to the issue for review.

                                  • 14. Re: non-java clients
                                    Ovidiu Feodorov Master

                                    John,

                                    I uploaded the latest JBoss Messaging presentation (Barcelona, Sep 2005) on the web site: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessaging.

                                    You may find it useful, it's the most recent one.

                                    1 2 Previous Next