BlackTie 2.0.0.M4 Released

Hello BlackTie fans,

We are very excited to let you know that we have now finished QA on the latest release and its uploaded and available from here: http://www.jboss.org/blacktie/downloads.html

In terms of what's new with the release, well if you take a look at http://www.jboss.org/blacktie/release.html you can see the full list, but we basically tightened up some of the XATMI behaviour, added a few new administration capabilities and some more documentation to our wiki.

One of the cool things that we have done is finally managed to get our artifacts into the maven repository hosted at http://repository.jboss.org/.

If you are developing pure Java XATMI applications this will be especially interesting for you as you shouldn't actually need to download the whole distribution and can just configure your maven settings and update your poms to reference the new version - however, you would need to download and deploy the latest blacktie admin services from here. You'll also need an updated btconfig.xml from here.

Actually, that does lead me onto another change with this release, we are now packaging the admin services as a real EAR, rather than the Jar, so the file that you deploy to JBOSS_HOME/server/all/deploy is slightly different - this is all explained here.

Hope that you enjoy the release!

Tom

PS - Just over one week to JUDCon...

Chatting to BlackTie developers on IRC

Dear BlackTie fans,

If you're only subscribed to the BlackTie blog RSS feed or monitoring our forum, you're missing out on the most direct way to get involved in our community. If you have some questions about BlackTie that you want to ask us without posting on the forum - such as, how can I contribute ;) - then feel free to follow these instructions:

You can either use the great freenode web interface (http://webchat.freenode.net/) so you don't need to install anything, or, you can choose a client and configure it to connect to irc.freenode.net (check out http://en.wikipedia.org/wiki/Comparison_of_IRC_clients for an ample list). If you are using a client, you'll probably want to register your nickname (and a backup nickname, usually your main nickname with a "_" attached to the end).  See http://freenode.net/faq.shtml#contents-userregistration for information on how (and why!) to do so.

There are tonnes of JBoss IRC channels on freenode, but the one that the BlackTie team is always on is: #blacktie

Hope to "see" you online soon!

Tom

PS Thanks to DML for some of the template content for this post :)

Building Quality Software

Hi Guys,

Todays blog entry will focus on showing you why you can trust the code that we are developing on BlackTie to be of the high quality that you expect from JBoss projects.

To start us off, here's how you benefit in terms of the way we develop the project:

• Continuous Integration - Provided by hudson, builds run regularly throughout the day on non-developer hardware
• Unit Tests - Provided by both cppunit and Junit, we have an exhaustative set of unit tests across both Java and C testing every aspect of the XATMI API, ran during every build
• Code Coverage Testing - Provided by emma and run on our Java code during the regular builds, this ensures we keep track of the coverage of the code based during testing
• Memory Leak and Error Detection - Provided by valgrind and run on all of our C code during each test run, this ensures we are fully aware of any memory issues that may arise.
• Transparent Agile Change Control - Our Jira instance can be accessed by anyone and bugs can be enterred and voted for so you can see just what is coming in any release
• Clear Version Control - Our fisheye and subversion repositories are again easy to access
  

At runtime, you benefit from the fact that all our code has been structured to take advantage of:

• Logging - We employ the fine grained and configurable logging frameworks of log4j and log4cxx, allowing the deployer access to detailed debug information in case of error
• Re-use of 3rd party best of breed software - BlackTie is an adapter framework integrating with well understood and documented frameworks such as the number one Java application server, JBoss AS. As a thin layer it collates these technologies into something much greater than the sum of its parts
• Modular Maven Project Structure - All our code is loosely coupled and our usage of Maven ensures that even in the C libraries, our code is highly modular and open for re-use in using the standard Maven dependency mechanism. This also helps to prevent cyclic dependencies in our codebase.
• Portability - We use the ACE and APR frameworks to abstract the operating system ensuring that we never need to code directly against operating system header files in our C or C++ classes/routines.
• Maven Plugin for C++ - We have developed our own C/C++ plugin for maven ensuring consistent and clear execution of the compiler.
  

Now, the final and perhaps most significant feature of our project that ensures the project is of the very highest quality is the fact that we are truly an open source project which means that not only are we able to foster input from the best in the industry, we also have the most stringent eyes in the world checking our work - yours! You are clearly able to see and the results and contribute to our design, code and tests for BlackTie.

Hopefully this entry has helped to explain some of the advantages in build quality that BlackTie has over other XATMI implementations, we will follow up in the future either here or on the wiki with more details of each of the aspects involved. If there is anything in particular you would like explaining in more detail, please comment here on on our forum.

All the best,
The BlackTie Team

Arriving Earlier: Asynchronous XATMI

A benefit of our utilising our underlying stomp and JMS transport is that our service invocations have always been loosely coupled and asynchronous.

One way we are going to be emphasizing this in M4 is to allow the underlying queues to be always available (as long as JBoss is alive) even if the XATMI server is taken down for maintenance or similar. You can monitor our progress here.

For services of this type, no code changes are required, but as tpacall acts just like a distributed enqueue operation, it is advisable to use tpacall/tpgetrply to allow your code the maximum flexibility.

Coming Soon: Pubsub model for XATMI programming

A new feature that we are working on that we are very excited about is the addition of the pubsub communication model for XATMI services. You can track our work on this here.

What this will mean is that user code will be able to send a single notification to multiple services using the standard XATMI API.

For example:

"ServiceA" is advertised on Server 1
"ServiceA" is also advertised on Server 2

When the client sends the request to "ServiceA", this would typically be handled by a single instance of the service, however, if, ServiceA is configured with a type="topic" attribute in the servers btconfig.xml, that same message would be received by all instances! An example of where this is useful would be for event notification such as for stock ticker symbols or more trivially/importantly (depending on your point of view), a chat room.

Significantly, this will all be achieved using the standard XATMI API with the only caveat being that all requests are sent with the tpacall method and TPNOREPLY set as the client cannot receive multiple responses to the same invocation.

This issue is currently scheduled in for M1 of the 3.0.0 release so please do comment on the Jira or in our forums if you have any further suggestions for us in this area...