netzooid

Jon Udell posted a lengthy article about WS-JustRight which is unnervingly relavent for my post yesterday.

For Grossman and others, WS-JustRight means using SOAP and WSDL to strike a balance between formal contracts and agile interoperability, while laying a foundation for future use of more advanced SOA features. PGP’s Brodbeck agrees that WSDL is the key enabler of reusable business transactions and processes. He also extends the definition of WS-JustRight, however, to include enterprise-enabled RSS as the key enabler of reusable content.

I’m interested in learning more about RSS in the enterprise. Right now I associate RSS with polling and uni directional. What will be the enabler of two way RSS on a larger scale? I’m thinking it would be cool to make a little publish subscribe application via SOAP over XMPP which pushes out RSS/Atom data. Maybe I have a weekend project on my hands.

I’ve been putting a lot of thought lately into coordination as it relates software, people and organizations.

On one end we have email, RSS/Atom, and web. All very loosely coordinated. Nearly everyone has email (hey Warren Buffet, you listening?), nearly everyone uses the web, and more and more people are aware of RSS/Atom. People can go out and start sharing information in a very loosely coordinated fashion. This comes at the expense of the ability to capture domain specific data or provide high security. When you move into the enterprise things fall apart.

Which brings me to the other end of the spectrum – I’ll loosely refer to it as SOA for now. With web services industry, groups, organizations, and even individuals can create domain specific languages. We have a broad basis of web service specs now (SOAP, WSDL, WS-Addressing, WS-Security, WS-….). On top of this people are developing specs like the Physical Markup Language which is a way to share RFID data. While RSS could embed this data, it isn’t really suited for it. There a couple problems with the SOA approach though…

Thought

When embarking on the SOA approach it requires a lot of up front thought. One must develop schemas, wsdls, etc. One must get every department to agree on a schema. One must worry about extensibility and versioning. And then there is scalability. And then there is choosing the right software platforms.

Coordination

If you do anything outside your organization it requires a lot coordination. For instance in a very fragmented industry (i.e. logistics), no one player can establish The Standard for everyone else. Getting everyone on board for a standard can take years. And there are huge benefits to sharing the data NOW.

Agility

Of course once you’ve decided on a standard, its already nearly worthless. But you’ve probably already committed to the software as well for the forseeable future. What happens when you need to extend? Or even worse – you need somethign radically different?

Data Control

All the above are issues, but one concerns me more than the others. Data control. Lets take the example of RFID. This page says it all, but let me describe. An item tagged via RFID will pass from a supplier, to a warehouse, to a distributor, to a retailer. Each one of these people contains a piece of information about the product as it passes through the suppline chain.

Who owns this data? How do we get at it?

Central storage? As a manufacturer you going to require every warehouse that you work with to send their data to your database?

What about distributed query of all the partners? Will every warehouse that you use be willing to adopt the same interfaces so you can query the particular tag? Will you have to write software against each partner’s interface?

What about security? Limiting subsets of data to specific people is hard, but not insurmountable. But a twist is that there may be an implicit trust relationship involved. If I am a manufacturer, my transportation provider may be partnering with a warehouser. Since my transportation provider trusts me, can I access the warehouse database?

Does the manufacturer have an implicit ownership right to the rfid data generated at the warehouse? Even if they have a right to it, how do we get at it and do we share it in a meaninful fashion? Can the warehouser charge extra for the data?

Data ownership and control brings up a lot more questions than it answers. Will SOA, ESBs, ERPs, middleware, and a host of technologies save us from data hell? I feel there must be a better way, but I have no real answers.

Doing some map hacking today. However, I’m coming up frustrated at the lack of solutions which have good answers to all of the following.

VirtualEarth has the coolest Javascript API. Its killer flaw is that it can’t be used commercially yet. Google Maps looks good, but lack of geocoding is sucky. geocoder.us costs money for commercial use, although cheap. I may just write my own geocoder using the Tiger data. I’d like to have Canadian geocoding though too. Yahoo Maps would really rock if I didn’t have to embed their stupid web page in mine. Last, the MapPoint web service rocks, but startup is really expensive. I’d gladly pay $100/mo but I think its roughly $8K/yr minimum with MapPoint.

sigh

Java and DOM sucks. There is no decent open source DOM toolkit to be had.

Criteria:

• Efficient
• Has an intuitive and friendly API
• Uses javax.xml.namespace.QName instead of its own version or no QNames
• Has a commercial friendly license (LGPL doesn’t count because too many people are scared of it and conflicting interpretations)

DOM4J: Has #1, #4 and a little of #2

JDOM: Has #2, #4, not sure about #1

XOM: Has #1, #2

W3C DOM: Has #3 and #4, not sure about #1

Update: DOM4J performance isn’t too bad as a commenter pointed out. XOM is still faster I believe though.

Update: Looks like I’m going to have to eat my words, as it turns out this is very possible. I was just looking at the wrong place. sigh.

First, JAXB 2.0 is very cool. I was able to get up and running with the RI in a few seconds literally. XJC worked like a charm (the schema to POJO generator). Marshalling/unmarshalling was very easy.

However, I am a bit miffed at lack of an API to create a schema from one’s annotated POJOs. Especially when a stated goal is:

JAXB 2.0 will specify the mapping from Java TM to XML Schema.

It assumes I’ll only ever need to generate a schema at build time, and doesn’t even specify a standard way to do that. All I want is:

Document doc = jaxbContext.createSchema("urn:my-namespace");

Why do you need this? Instead of requiring users to build a WSDL document up front and generate stubs for SOAP services, users could create a service class with their JAXB POJOs as the method parameters. Then the SOAP toolkit can build a WSDL document dynamically. XFire can already do this with XMLBeans and I want to be able to do it with JAXB 2.0.

I guess its time to get on the JAXB mailing list…

Lately companies like IBM, BEA, and Simula Labs have been swooping in on open source projects like Spring, Geronimo, and ActiveMQ. Are they letting the open source community absorb the risk in creating software?

For instance, projects are created. They stew and incubate. The buzz spreads. Developers fawn. Hani biles. During this process the “open source community” (*cough* I hate that term) provides a feed back loop during development so it happens quickly and efficiently. Once projects mature, larger companies swoop in, pick up the developers, provide support, integrate them with their products etc. Or at least this is what I’m seeing happen.

I still question the business plans of such companies. Service and support is not in my mind a sure fire combo – and definitely not a way to come up with billions in the bank. I lost the link, but there was an article about how as more and more people become comfortable with open source, the less likely they are going to want to support. They’ll start asking, if they really need a lifeline? And, does it really pay? In addition there is the up-sell strategy and a hundred other angles…

But will they result in successful businesses with a decent ROI? Maybe… There certainly seem to be some winners lately. I think it depends on how much value you can actually add on top of the open source offering. But that is a whole new blog entry…

Thoughts?

We’ve all seen open source being adopted by major companies. Even recently Microsoft. One thing that I’ve noticed most recently is that open source projects are an efficient way to incubate and bring a project to maturity. I’m hypothesizing that by being closer to their users, getting feedback earlier on and being able to gauge project adoption, a company is able to create better software.

So I’d like to take a look how open source can help in software development and potentially in business as well during what I would call a ‘project incubation period.’ (Although let me make it clear: Open Source != Good Business IMO) Project incubation period doesn’t necessarily mean alpha or pre 1.0 as I see it, it is the time between when a development starts on a project or a portion of the project and the time when it reaches ‘success.’ Although your definition of success may vary…

The Feedback Loop

Let me take an example from my development efforts: XFire. XFire started as just a way for me to play around with SOAP and develop services faster. It became clear early on that the people I talked to favored a component oriented approach. So now we have support for the Spring, Plexus, and Loom containers. It also resulted in a much more flexible design and users consistently talk about how easy it is to embed now.

By engaging your users you’re able to understand their needs more. During a marketing campaign the will always do focus groups. Developers should be doing the same thing. Product adoption isn’t always technical, it’s psychological as well. What you view as a small nitpick may be the defining hurdle that stops a user from using your project.

If this all sounds like agile programming – I think thats what it is. Open Source adds an additional spin though. By engaging a larger audience you may find “stories” which are important to your users or completely new audiences that you didn’t think of.

(more to come on this topic tomorrow…)

Thanks to the help of Hani Suleiman and Hiram Chirino, I got an XFire JMS transport working yesterday (having zero JMS knowledge the day before). Check it out if you’re at all interested in a reliable transport for SOAP. I’ll try and get some docs up in the next couple days which shows how to use ActiveMQ’s Spring configuration and XFire’s Spring configuration together.

As a sidenote, let me add that Active MQ rocks! Not only is it “crazy fast” as James says, its “crazy easy” too. I was to embed it into a test case with about 5 lines of code. Definitely check it out if you have a need.

Davanum Srinivas:

Verisign has graciously initiated the process for donating TSIK to Apache. As part of the process, we started discussions on legal aspects and found that any one who implements WS-Security needs licenses from IBM and Microsoft. Note that this does not only affect TSIK incubation, but also the existing Apache WSS4J project.

This is no good, no good at all…

XFire’s new service model and channel features are something I’ve been meaning to write about for a while (this post prompted me to get off my behind – although I’m sure its not quite what the author had in mind). Warning: Currently this stuff in only in CVS and does not have a lot of documentation. With that said, we’re doing a release soon and I’m starting to work on documentation.

Message Channels

The best way to grok channels is to look at some code.

LocalTransport transport = new LocalTransport();
Channel channel1 = transport.createChannel("urn:xfire:local:Peer1");
channel1.open();

Channel channel2 = transport.createChannel("urn:xfire:local:Peer2");
channel2.setEndpoint(new DocumentEndpoint());

// Document to send
Element root = new Element("root");
root.appendChild("hello");
Document doc = new Document(root);

MessageContext context = new MessageContext();

OutMessage msg = new OutMessage("urn:xfire:local:Peer2");
msg.setSerializer(new DocumentSerializer());
msg.setBody(doc);

channel1.send(context, msg);
Thread.sleep(1000);

channel1.send(context, msg);
Thread.sleep(1000);

channel1.close();
channel2.close();

What happens here is we’re using the LocalTransport to send messages to another channel. Each channel has a unique uri (not url) which identifies them. In this example, the DocumentEndpoint receives messages on the channel and prints them to stdout for us to see. This is all completely stream based so we don’t have to passing around documents if we don’t want to, keeping memory low.

public class DocumentEndpoint
    implements ChannelEndpoint
{
    public void onReceive(MessageContext context, InMessage msg)
    {
        StaxBuilder builder = new StaxBuilder();
        try
        {
            Document doc = builder.build(msg.getXMLStreamReader());

            System.out.println(doc.toXML());
        }
        catch (XMLStreamException e)
        {
            e.printStackTrace();
        }
    }
}

Upon running this you’ll see this come out on your console:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><root>hello</root></soap:Body></soap:Envelope>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><root>hello</root></soap:Body></soap:Envelope>

This is really handy for just sending messages across the wire, routing them around, using as a soap stack base :-), etc. Right now we have local, http, and xmpp support in cvs. JMS support is coming Real Soon Now.

I’ll also be working with a student in the Google summer of code program to implement Reliable Messaging over top of this. One can see how easy it would be. Just create a new ReliableMessagingChannel which wraps an existing transport and sends/resends messages as needed.