non-java clients

[fawce]

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

[adrian.brock]

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.

[fawce]

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

[adrian.brock]

"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.

[ovidiu.feodorov]

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.

[fawce]

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.

[fawce]

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

[ovidiu.feodorov]

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.

[fawce]

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.

[ovidiu.feodorov]

... 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.

[fawce]

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?

[ovidiu.feodorov]

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.

[fawce]

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

[starksm64]

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.

[ovidiu.feodorov]

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.