RoadMap

[jmizell]

I would like to know if there is a roadmap for blacktie? At the current version with M4 is does it have enough features to move over my existing tuxedo code or do I need to wait for a few more releases? Would you recommend M4 be used in production or should we wait for a future release. Sorry for all the questions but I have not seen any web pages addressing them.

[tomjenkinson]

Hi jmizell,

I have uploaded the highlighted version of our roadmap onto the wiki pages at http://www.jboss.org/community/docs/DOC-13618

For clarification, the milestone releases (previously prefixed by an M, now an MR), are not intended for production. After milestone releases we get candidate releases (CR) and finally the official version (which is identified by the version number alone). On the BlackTie team, we are aiming for 8 weeks between MR releases while we complete development and add features.

At the moment, we would really like to hear feedback from people who are looking to move over code onto BlackTie as we still have opportunity to add additional features where possible so if you would be interested, perhaps you could download MR4 and let us know if there are any omissions that you would like us to add in?

Hope this is all clear,
Tom

[lazan]

I have pretty much the same question.

We are a major customer to Oracle Tuxedo, with several thousands of XATMI services in our production, and we are looking for a replacement.

We have the following requirements/requests for us to be able to migrate to BlackTie.

Full support for fielded buffers (FML), since all, but a few, of our services uses FML. As I understand it, the FML-“specifications� are not an open and free standard, hence it would be difficult/impossible to provide the exact same API. Unfortunately a large percentage of our code-base uses this API directly, but it would be manageable for us to convert to a similar API.

Coexists with Tuxedo. That is, setting up a BlacTie-“domain� that interacts with a Tuxedo domain, hence exporting, importing services to and from Tuxedo domains, and route messages, with transaction support, between Tuxedo and BlackTie. I’m not sure if this interaction with a Tuxedo domain is part of the XATMI-standard (I’m not able to read the XATM-specification right now), but my guess is that it’s not.
Chances for us to migrate to BlackTie a´la big-bang are slim to none. I’m pretty sure that management doesn’t want to take such a risk.

Able to use /Q as queue-manager. This is not a must, and we are looking for a JMS (or other) replacement for /Q anyway. But it would be convenient from a migration point of view.

So, my question is: How well does our requirement fit with BlackTie’s road map? If it’s possible at all.

That aside, I’m very found of your (JBoss) view on open-source, and your business model. And I sincerely hope that BlackTie will be a success regardless of our possibility to migrate to it.

/Fredrik

[tomjenkinson]

Hi Fredrik,

Thanks for your interest in BlackTie and your support of JBoss in general! Here is our current roadmap link:
http://www.jboss.org/community/wiki/BlackTieRoadmap

In terms of your first question, we are adding a new buffer type to BlackTie which will have a structured buffer field API and the support to route messages but this will not be added to the main development tree until after we have baselined an initial community release for BlackTie which is expected in the next few months.

In terms of your second query you will also be happy to hear that this in also on our roadmap although it is currently tentatively scheduled for version 3 (some way off). We are always happy to work with contributors in the community and so perhaps if the rest of our roadmap was considered to be in sync with your own, then perhaps this could be an area we could collaborate with you?

The specification does define a transport level communication protocol therefore, assuming Tuxedo supports this, we *should* be able to interoperate with them or any other XATMI implementation at the XATMI/TX level (although it is unlikely that we would be able to interoperate at the FML level).

Your final point about /Q, this is not something that we would be able to add ourselves as we do not have a /Q instance to test on. However, again, we are happy to work with contributors to add this if for instance you do have /Q. Our transport layer is pluggable and so it should certainly be feasible to add a transport to use /Q.

The JMS provider we use for testing is JBoss Messaging 1.4, although we will move to the latest version, renamed HornetMQ (http://jboss.org/hornetq) as soon as that GA's.

I look forward to hearing back from you,
Tom

[lazan]

Hi Tom, Thanks for the quick reply.

I'm not sure a fully understand some of what you indicate is coming in a future BlackTie-release.

I'm glad to hear that there will be a FML-like API in the near future, but I'm not sure what you mean by "support to route messages". This has nothing to do with the structured buffer field API I presume? Or do you mean some sort of "data dependent routing"? Or, perhaps, do you mean something like the functionality provided by the TMQFORWARD server?

Regarding your answer to my second query, I'm a bit puzzled (maybe because of my lack of expertise in the inner workings of XATMI/TX). I don't know if BlackTie have/will have a "domain"-concept like Tuxedo does, or is this redundant? (I.e. BlackTie support dynamic configuration, hence you don't have to shutdown a whole domain to change the configuration, and there is some other mechanism to balance against hardware). But IMHO BlackTie has to have some knowledge of Tuxedo Domains since it has to route a service call to the correct Tuxedo Domain where the requested service is located (assuming a call: BlackTie -> Tuxedo), and vice versa (in Tuxedo terms: GWTDOMAIN to GWTDOMAIN). Is this what you mean by "transport level communication protocol"?

I interpret "is unlikely that we would be able to interoperate at the FML level" as the underlying buffer of BlackTies future structured buffer field will not be compatible with Tuxedo's underlying FML-buffer, which would in practice prevent a seamless transition to BlackTie for us. I find it hard to see a non-intrusive solution in general since most of our code base uses Tuxedo FML-API directly, more or less. In our newer realizations we have a much better abstraction and could adapt to whatever message-format, since the user code has no knowledge of the transport layer.

I was (still am :)) hoping for a migration scenario where we "choose" a set of implementations that will be converted to work with BlackTie, and deploy these. So we could do the total migration over time. As I understand it now, this would not work. Or am I missing something?

/Fredrik

[tomjenkinson]

Hi Fredrik,

My apologies for any ambiguities in my previous response, hopefully I will be able to clarify the points you raised here:

On point 1, our portable buffer format will achieve the same key features of FML/VIEWs:
1. Provide a mapping file definition of structs that the user wants to ship around
2. Provide an api to access a hashmap buffer by key/value
3. Allow BlackTie to perform routing on the data as it is now aware of the structure of the data, achieving the same purpose as data dependent routing

On point 2, interoperability with Tuxedo will only be possible at the specification defined level, from what we know today, this will most likely be achieved with Tuxedo using the TMA:
http://download-llnw.oracle.com/docs/cd/E13161_01/tuxedo/ositp/v100/pdf/ositpug.pdf
This link is also useful for background information (if a little old):
http://download.oracle.com/docs/cd/E13203_01/tuxedo/ositp/v81/ositpug/intro.htm

On point 3, as FML is a proprietary format we would most likely need to use the features provided by Tuxedo to export this buffer type into an X_C_TYPE/X_COMMON buffer, if you go to:
http://download-llnw.oracle.com/docs/cd/E13161_01/tuxedo/tcp/v100/tuxug/tuxintr.html
and search for FML you will see some information on this.

To summarise, it is certainly our intention to support users deploying BlackTie into the same ecosystem as Tuxedo and have them peacefully co-exist, but we are some way off that at the moment and would welcome contributors in the community to assist with this where possible!

Hope this is clearer!
Tom

[lazan]

Hi Tom.

To my delight, it turns out that the reason for my lack of understanding was my lack of expertise :). Could not have hoped for a better outcome than that.

Thank you for your patience with me, it's much clearer. I did try to find information like this on this site though, but were unsuccessful.

We, which in reality means me, are going to do a POC, just to get our hands on, and to have a ground for further decisions regarding our possible transition to BlackTie.

I've been trying to get an OK to take an active role as a contributor in the BlackTie community, since my participation in the BlackTie "event" that RedHat held in Stockholm a while back. Even if it's just 20-30%. It's been... well, I still have hope.

Regards
/Fredrik

[tomjenkinson]

Hi Fredrik,

I am glad that the answers you received were to your liking!

All the best and we look forward to collaborating with you in the future!

Tom

[tomjenkinson]

Hi Frederik,

We have just released MR6 which although it does not address your specific areas of interest on FML and interop, we would still recommend you take a look at as it is a considerable step forward from MR5!

All the best,
Tom