Posted early versions of Qpid Messaging API tutorial

April 19th, 2010

I have finished an early draft of the Qpid Messaging API tutorial and checked in the DocBook source at qpid/doc/book/src/High-Level-API.xml.

I built an HTML and a PDF from this and posted it here:

http://people.apache.org/~jonathan/High-Level-API.html
http://people.apache.org/~jonathan/High-Level-API.pdf

I’ll improve this and add to it, it will appear as a chapter in the DocBook documentation for Qpid when we publish that.

“Hello world!” in Java JMS

April 16th, 2010

Apache Qpid programs written in Java generally use Java JMS. Java JMS defines an API, but not a binary protocol. Using AMQP with Java JMS allows programs to exchange messages with clients in various languages, running on various platforms.

The new Messaging API has made one change that affects Java JMS programs: addresses have become simpler and more powerful. I will discuss Addresses in depth in a later post. Today, I would like to show how to use the new address syntax in a program.

Here is the same “Hello world!” program I posted earlier, written in Java JMS this time. The address of the “amq.topic” exchange is simply the string “amq.topic”. Our program needs a JNDI file that defines a connection factory for the broker we are using, and the address of the topic exchange:

java.naming.factory.initial = org.apache.qpid.jndi.PropertiesFileInitialContextFactory

connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'
destination.topicExchange = amq.topic

In the Java JMS code, we use create a JNDI context, use the context to find a connection factory and create and start a connection, create a session, and create a destination that corresponds to the topic exchange. Then we create a sender and a receiver, send a message with the sender, and receive it with the receiver. This code should be straightforward for anyone familiar with Java JMS.

package org.apache.qpid.example.jmsexample.hello;

import javax.jms.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.util.Properties;

public class Hello {

    public Hello() {
    }

    public static void main(String[] args) {
        Hello producer = new Hello();
        producer.runTest();
    }

    private void runTest() {
        try {
            Properties properties = new Properties();
            properties.load(this.getClass().getResourceAsStream("hello.properties"));
            Context context = new InitialContext(properties);

            ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup("qpidConnectionfactory");
            Connection connection = connectionFactory.createConnection();
            connection.start();

            Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
            Destination destination = (Destination) context.lookup("topicExchange");

            MessageProducer messageProducer = session.createProducer(destination);
            MessageConsumer messageConsumer = session.createConsumer(destination);

            TextMessage message = session.createTextMessage("Hello world!");
            messageProducer.send(message);

            message = (TextMessage)messageConsumer.receive();
            System.out.println(message.getText());

            connection.close();
            context.close();
        }
        catch (Exception exp) {
            exp.printStackTrace();
        }
    }
}

Hello World! New Apache Qpid Messaging API for C++ and Python

April 16th, 2010

I’m working on a tutorial for the new Apache Qpid messaging APIs, and I thought it might be useful to blog pieces of this as I go. The new APIs are much simpler to program in, more declarative, and not tied to a specific AMQP version. I’ll describe how they work in a series of blog entries, and point to the tutorial when it is available.

Apache Qpid is a reliable, asynchronous messaging system that supports the AMQP messaging protocol in several common programming languages on the Linux, Windows, Java, and Unix platforms. Apache Qpid uses Java JMS for Java programs, and WCF for the .NET platform. The Qpid Messaging API has been implemented for C++ and Python, and will be implemented in Ruby soon.

Let’s look at a simple “Hello World” program in C++ and in Python. Each of these programs looks for an AMQP broker at “localhost:5672″ and uses the “amq.topic” exchange by default. The user can specify a different broker or exchange on the command line.

“Hello world!” in C++

#include <qpid/messaging/Connection.h>
#include <qpid/messaging/Message.h>
#include <qpid/messaging/Receiver.h>
#include <qpid/messaging/Sender.h>
#include <qpid/messaging/Session.h>

#include <iostream>

using namespace qpid::messaging;

int main(int argc, char** argv) {
    std::string broker = argc > 1 ? argv[1] : "localhost:5672";
    std::string address = argc > 2 ? argv[2] : "amq.topic";
    Connection connection(broker);
    try {
        connection.open();
        Session session = connection.createSession();

        Receiver receiver = session.createReceiver(address);
        Sender sender = session.createSender(address);

        sender.send(Message("Hello world!"));

        Message message = receiver.fetch(Duration::SECOND * 1);
        std::cout << message.getContent() << std::endl;
        session.acknowledge();

        connection.close();
        return 0;
    } catch(const std::exception& error) {
        std::cerr << error.what() << std::endl;
        connection.close();
        return 1;
    }
}

"Hello world!" in Python

import sys
from qpid.messaging import *

broker =  "localhost:5672" if len(sys.argv)<2 else sys.argv[1]
address = "amq.topic" if len(sys.argv)<3 else sys.argv[2]

connection = Connection(broker)

try:
  connection.open()
  session = connection.session()

  sender = session.sender(address)
  receiver = session.receiver(address)

  sender.send(Message("Hello world!"));

  message = receiver.fetch(timeout=1)
  print message.content
  session.acknowledge() # acknowledge message receipt

except MessagingError,m:
  print m
finally:
  connection.close()

QpidComponents.org

July 14th, 2009

We have launched a site called QpidComponents.org for Apache Qpid components that can not be developed as part of Apache Qpid per se, generally because they use software components that use open source licenses other than the Apache license.

Currently, these components include persistence and management tools.

See http:://QpidComponents.org!

The future of XHTML – and of XML?

July 6th, 2009

I was concerned late last week when I read that the XHTML Working Group will not be allowed to finish its work. The announcement indicates that this is being done to speed the work of HTML5 – but it also raises important questions about how XML will work with data on the Web.

http://www.w3.org/News/2009#item119

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the HTML Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity.

Originally, HTML was based on SGML. XML was designed to make SGML easier to parse, so that it would be more accessible to software. From the beginning, XML was designed to support documents meant for humans to read, and data designed for programs. In modern software, there is no firm boundary between the two – data is often transformed on the fly for humans to read, and software often mixes human-readable content with data.

By representing HTML as an XML vocabulary, XHTML addresses HTML parsing issues, difficulty combining HTML with XML data, and extensibility issues:

  • An XML parser can not parse arbitrary HTML, and parsers which do are extremely complex. Tools like Tag Soup parse arbitrary HTML and convert it into XHTML, so that even legacy content in odd dialects of HTML can be processed by XML tools.
  • XML vocabularies like SVG (a graphics format) and MathML (a mathematical notation format) need to play nicely with HTML. XHTML lets them be combined with HTML using the same mechanisms all XML tools use to combine vocabularies.
  • HTML has become quite large, and XHTML provides a modularization of HTML, using XML mechanisms, that makes it easier to maintain and extend.

Typically, Working Groups are rechartered if there is active interest in their work and they are close to their goal, as the XHTML Working Group is. Another year of effort would probably be sufficient to finish the XHTML specifications. And the XHTML people are intimately familiar with XML and namespace issues, plus the issues that arise with XML and HTML software.

The FAQ that the announcement points to concerns me. Some of the work of the XHTML Working Group will not be finished, and there is even a suggestion that HTML5 will not handle namespaces correctly, and that XML vocabularies will not be able to mix freely with HTML5!

Consider this issue, to which the FAQ points:

http://www.w3.org/html/wg/tracker/issues/41

The HTML5 specification does not have a mechanism to allow decentralized parties to create their own languages, typically XML languages, and exchange them in HTML5 text/html serializations. This would allow languages such as SVG, MathML, FBML and a host of others to be included. At one point, an editors version of the HTML5 specification contained a subset and reformulation of SVG and MathML. Tim Berners-Lee described this incorporation of SVG and MathML without namespaces as horrific and the issue raiser [Dave Orchard] completely concurs with the him.

This issue limits the ability of non-HTML5 working groups to define languages as the languages must be “brought into” the HTML5 language. This dramatically increases the scope of HTML5 and decreases the ability to modularize development of orthogonal languages.

In the end, the problem could result in the text/html serialization rules becoming the standard serialization rules for XML languages, replacing XML itself. This could occur if every decentralized language has a choice between the XML serialization, the text/html serialization or both. In many cases, the language may choose the text/html serialization.

I find this last paragraph alarming. XML was designed specifically to allow decentralized parties to create their own languages, and to combine them cleanly using namespaces. By using the mechanisms defined in XML, XHTML inherits this ability, an ability that HTML5 lacks. One proposed solution is to absorb XML entirely into the HTML5 specification. I agree with Tim and Dave that incorporating SVG and MathML without namespaces is horrific, but the obvious solution is for HTML5 to support namespaces and XML cleanly – just as XHTML does.

I would like to see the XHTML Working Group finish their work, and I would like to see the result used as the XML serialization of HTML5. Legacy HTML ensures that there will always be large amounts of HTML content that is difficult to parse without tools like Tag Soup. But XHTML gives us a very sane XML vocabulary to convert such content into, and makes HTML accessible to the wide variety of XML tools that make up much of the infrastructure of the Web.

XQJ (XQuery API for Java) is now an official JSR!

July 2nd, 2009

The Expert Group for for JSR-000225 XQuery API for Java
has (finally!!!) completed its work and published XQJ as a Final Release.

You can get the XQJ specification at either of the following URLs:

Missing Balisage this year …

June 29th, 2009

I often attend the Balisage XML conference in Montreal, the best “geek-fest” gathering for XML techies:

http://www.balisage.net/

Balisage will be meeting from August 11 — 14, 2009, in Montréal, Canada. On August 10th, Mike Kay is doing a workshop on Processing XML Efficiently that looks especially interesting.

I hope my friends at Balisage will excuse my absence this year. I will be on my honeymoon.

MRG Messaging: A Programmer’s Overview

June 26th, 2009

I am going to be giving a presentation on MRG Messaging for programmers at the Red Hat Summit in Chicago, Thursday, September 3, from 1:30 to 2:30 p.m.

You can see the schedule here:

http://www.redhat.com/promo/summit/2009/agenda/tracks/

Here’s the blurb for the talk:

MRG Messaging: A Programmer’s Overview
Jonathan Robie, Software Engineer, Red Hat

Red Hat Enterprise MRG is an open source messaging system based on Advanced Message Queuing Protocol (AMPQ), an open standard for enterprise messaging. Red Hat Enterprise MRG allows users to write applications for simple, high-speed messaging in multiple languages (Java JMS, C++, Python, Ruby) and it allows users to run the applications on multiple platforms (Linux, Unix, Macintosh, or Windows). Red Hat Enterprise MRG provides guaranteed delivery, speed, and security.

This presentation serves as a programmer’s overview of Red Hat Enterprise MRG and is designed to teach programmers what they need to know to get started writing messaging applications. This presentation will feature:

  • Overviews of Red Hat Enterprise MRG, Apache Qpid, C++, and Python Messaging APIs
  • Discussion of the AMQP messaging standard and Apache Qpid
  • API summary for C++ and Python
  • Description of how to use Red Hat Enterprise MRG with Java JMS
  • Demonstration of how to write applications based on common messaging paradigms (e.g., direct, fanout, publish-subscribe, request-response, and XML content-based routing)
  • Demonstration of how to write Java JMS programs that use Red Hat Enterprise MRG
  • Demonstration of how to implement persistence, messaging transactions, and failover for clients using a high-availability cluster
  • Demonstration of the tools that can be used to manage the messaging server, view of the configuration, and track the state of messages in the system

Apache Qpid 0.5 is released!

May 27th, 2009

Apache Qpid 0.5 is now released! Download it here:

http://qpid.apache.org/download.html

Here is the text of the announcement:

http://mail-archives.apache.org/mod_mbox/qpid-users/200905.mbox/browser

The Apache Qpid community is pleased to announce the release of Apache Qpid 0.5

Apache Qpid (http://qpid.apache.org) is a cross platform enterprise messaging solution which implements the Advanced Message Queueing Protocol (http://www.amqp.org). It provides brokers written in C++ and Java and clients in C++, Java (including a JMS implementation), .Net, Python, and Ruby.

New features included in this release are:

C++ Broker

  • [QPID-1567] – Queue replication (asynchronous) between two sites
  • [QPID-1669] – Client connection management in the qpid-cluster CLI utility
  • [QPID-1673] – Dynamic Library Build on Windows (DLL)

Java Broker

  • [QPID-1583] – IP White/Black lists for virtual hosts
  • [QPID-1648] – Enable live reconfiguration of Log4J settings for
    the Java broker via JMX
  • [QPID-1699] – Reload security section in configuration files through JMX

C++ Client

  • [QPID-1673] – Dynamic Library Build on Windows (DLL)

Java Client

Ruby Client

Java Management : JMX Console

  • [QPID-1500] – Mac OS X Build
  • [QPID-1648] – Enable live reconfiguration of Log4J settings for the Java broker via JMX
  • [QPID-1691] – Linux x86-64 and Solaris builds

Java Management : QMan

It is available to download from:

http://qpid.apache.org/download.html

Complete release notes are available here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520&styleName=Html&version=12313597

Tim Fox: AMQP “of strategic importance” for JBoss

April 23rd, 2009

Tim Fox has announced that

JBoss Messaging 2.x will implement AMQP, as we consider this to be of strategic importance, along with JMS, and of course the full set of enterprise messaging functionality that you’d expect in any serious messaging broker.

And also that JBoss will be licensed under Apache 2.0:

JBoss Messaging will also be relicensing it’s code under the ASL 2.0 licence (moving away from LGPL) in order to be usable by the widest range of interested parties.