netzooid

Much to my surprise, it seems that somehow I managed to get two talks accepted to ApacheCon EU (May 1-4) this year. The best part is that they're on completely different sides of the spectrum.

The first talk is Navigating WS-death^H^H^H^H^H*. (It seems not everyone liked the name, so that may be changed - feel free to give feedback in the comments). There are many WS specs out there with many different versions (like WS-Addressing). When should I as a user consider using them? What benefits will they bestow on my project? How interoperable is a particular specification? What does the spec roadmap look like?

The second is entitled Building scalable, reliable, and secure RESTful services. This talk is intended to be practical advice on how to build RESTful services. I am to illustrate scalability, reliability, and security through a series of practical examples using different toolkits/frameworks.

Hope to see many of you in Amsterdam this year, I'm sure it'll be a great time!

One of the things that really bugs me is when people go about reinventing configuration, discovery, or wiring for their Java components. We have plenty of containers out their which can do this for us. By reusing them we end up with higher quality code and can focus more on features specific to our problem domain. Spring has been the most popular container for a while now, and its pretty obvious how to do configuration or wiring together of components. But how do you do discovery?

I’ve seen many examples which advocate this:

<bean id="widgetManager">
<constructor-arg>
<list>
<ref bean="widget1">
<ref bean="widget2">
</list>
</constructor-arg>
</bean>


The problem with this though is that you need to explicitly list all your widgets in your configuration file. In many cases what you’d like instead is to be able to just add acme-widget.jar to your classpath and have Spring automatically pick it up!

To get around this issue in CXF I wrote a SpringBeanMap class. What this will do is look through all your ApplicationContexts and find beans which implement a specific interface. Here is a small example of how it would be applied to the above case:


<bean id="org.widgetthingy.WidgetManager">
<constructor-arg>
<bean class="org.apache.cxf.configuration.spring.SpringBeanMap">
<property name="type" value="org.widgetthingy.Widget"/>
<property name="idsProperty" value="widgetIds"/>
</bean>
</constructor-arg>
</bean>


This will invoke the getWidgetIds method on any bean which implements the Widget interface. For each id supplied, it will use it as the key in your Map with the widget as the value. Once that is done the resulting Map gets supplied to your WidgetManager via a constructor or property.

That only solves half the problem though. We also need to discover new configuration files that have been added to the classpath. This can be done by creating a ClassPathXmlApplicationContext that looks for all the **/widget-*.xml files. Now all one has to do when writing a new widget is define their bean in a widget-foo.xml file and it will be automatically added to your application..

The only issue that I’ve found with this approach is that the Widgets aren’t lazily loaded. This isn’t a huge deal for us at the moment as the things we’re loading aren’t resource intensive. There is at least one way around this for those so inclined. Instead of instantiating the bean and invoking getWidgetIds() we could instead look at the Spring BeanDefinition for what the “widgetIds” property holds. This means that you must include the widgetIds in your Spring bean definitions though, and they can’t be hard coded into your class.

If anyone has other approaches which get around this, I’d love to hear them. I’ve recently re-enabled comments so drop me a line…

UPDATE: Arjen Poutsma pointed out via email out that if I want lazy initialization there is no other possiblity than to put the ids in the XML. If I want to get ids via the bean, I’m going to have to instantiate it. (*kicks self*) I updated SpringBeanMap to support both methods. Now if there are ids specified in the XML they are used and the bean is not initialized. If there are no ids specified, we initialize the bean and grab them. I’m fairly happy with this solution now. It is completely non invasive and very flexible!

The Geronimo team has been hacking away at their 2.0 release lately. As part of this they’ve done some work to support JAX-WS by using CXF. It seems that Jarek Gawor has recently put up a small tutorial on how to use these features as well. Cool!

I just ran across this mail from Glen Daniels announcing a public review of a JMS SOAP binding and IRI scheme from BEA, IBM, Sonic and Tibco.

As some of you may know, several companies (BEA, IBM, Progress, and TIBCO) have been working on a formal set of specifications for binding SOAP to the Java Message Service API. These specs consist of a) a SOAP binding, and b) a description of the “jms:” IRI scheme which is used for addressing. The specs do NOT cover an interoperable wire-level representation which could bridge different vendors’ JMS implementations - though a future version might go there. This version has been designed so that plugging in a different implementation should work seamlessly without recompiling any code; as such we define a BytesMessage encapsulation of SOAP (and MTOM), a “Content-Type” JMS header, and a few other needed parts. While this work has been progressing within the group up until now, we’d like to announce that the specs are now at a point we feel is suitable for public consumption.

A couple interesting notes after glancing through the spec:

• Defines an IRI header so you can address services and use JMS IRIs in the element.
• Defines a content-type header - this will make it easier to support attachments. However, as I understand it, this would be of limited value since JMS providers don’t really provide support for sending very large files.
• It defines a SOAPJMS_soapAction header. “The wsdl11soap11:operation portion of the WSDL specification explicitly disallows use of the soapAction attribute in non-HTTP bindings. This specification supersedes that requirement, and allows the use of soapAction in the <wsdl11soap11:operation> element for SOAP/JMS bindings.” I’m not sure I understand why we would want this, unless they’re trying to support legacy services?
• It defines several WSDL elements for configuring your service. For example: <soapjms:connectionFactoryName>sample.jms.ConnectionFactory</soapjms:connectionFactoryName>

It will be interesting to see where this goes! If you have feedback on the specification Glen’s email outlines instructions for submitting it back to the authors.

Before I really got to know the WS-I attachments profile I thought there were basically three ways to send attachments with SOAP: Soap w/ Attachments, DIME, and MTOM. I was wrong, there are four - the fourth being the WS-I Attachments Profile.

The goal of the profile is stated as:

This document defines the WS-I Attachments Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications that are intended to promote interoperability.

If this spec was really intended to promote interoperability it wouldn’t have defined a completely new way to do attachments. It introduces two new backward incompatible changes. First, it requires you to include the reference to the attachment in your schema via a new XML schema type called wsi:swaRef. Before you could simply reference an attachment in your mime binding without putting anything in your schema (example here).

Second it devised a completely new Content-ID format for referencing MIME parts. For example: <fooPart=somereallybignumberlikeauuid@example.com>. Notice how we have “fooPart=” in the Content-ID? This is required to tie the MIME attachment to the newly invented way to reference attachments in your schema. There is no such mention of a thing in the SOAP w/ Attachments specification.

I have come to the conclusion that there is absolutely no point in supporting the WS-I AttachmentsProfile. For it to be a profile (in my mind) it should standardize and categorize existing techniques, not invent new ones. I recommend that anyone using attachments just use MTOM which is a much better standard and more widely supported anyway.

Good adivce from Scoble for all my corporate PR & sales friends:

My friends have been asking me “why doesn’t Wall Street believe Steve Ballmer?”

That’s an easy one. Cause he didn’t convince the grass roots influence networks first. Why have Google and Apple done so well in the last three years? Cause the grassroots loves them. That’s the [power] of the industry. Ideas here don’t come from the big influencers and move down. No, they start on the street and move up. Anyone miss how Google got big? Not by throwing a press conference.

I believe there is a word for this… disintermediation. The great thing about making people in your organization available at conferences and on blogs, is that you’ve cut out the middle man. You’re getting the real deal from the real source. Thats why its so interesting to read Robert’s blog, or Jonathan Schwartz’s or any number of other people’s. Provided you have a compelling story, people will go on to talk about you.

This meshes really well with open source. It starts at the developers (the roots) and works its way up. You don’t even need a big marketing budget. If everyone on the street is using you, the press, analysts, big companies, etc will have to take notice. (Of course some of this is because the software is free as well, but I think the point still stands…)

I’m on my way back from The Server Side Java Symposium, also known as the Convention That Needs To Find a Shorter Name. All in all a really good time. I’m completely exhausted from it though. There were a ton of smart people there and it was an honor to be in the speaker lineup.

There were a lot of really great sessions and unforunately I missed many of them, but heres a quick recap.
XFire Session: Yeah, so this is one I had to attend because I was speaking :-). I realized afterward that my session had very little to do with XFire at all. It ended up being about SOA, JAX-WS, and how to write effective web services. I think it was well received. The most surprising (and cool) part to me was about the dozen or so individuals coming up to me afterward to tell me that they were using XFire and in many cases how much they liked it. Thanks everyone!

The slides from my talk are posted here if you’re interested.

SOA with POJOs: James Strachan gave a talk on the first day that gave a nice recap on the principles of SOA. He also gave a good quick overview of JAX-WS, SCA, etc.

Mobile Java Application Continuum: OK, I didn’t attend this talk but I really wish I had. Eugene Ciurana put it on and talked about all the problems in developing J2ME applications. J2ME is unique because most of the problems that you run into are not technical, but rather political. Its a lot of carriers trying to protect their turf and it is just sickening. This talk will also go down as having one of the nicest entries from Hani ever.

Ted Neward on Messaging: Ted gave a good overview of when we should use RPC and when we should use messaging. While Paul Brown was nitpicking a few things during the session, it was overall very good - Ted is a good speaker and easy to listen to.

Codehaus BOF: while almost no one showed up to the Codehaus BOF because it wasn’t listed on the schedule, I did meet a half dozen great people which was excellent. The other reason that people didn’t show was because of Crazy Bob’s crazy star trek wedding, which nearly all the Codehausers went to. Congrats Bob and I hope you’re feeling more coherent now than the last time I saw you!

About a week and a half ago I finally received my new Sun T2000 machine. While I was expecting a big machine, I wasn’t expecting a forklift pallette with a couple boxes on it. Nor was I expecting it to take two people to get down into my office. So it is a bit cluttered with boxes right now.

My first experience with the machine was a disappointment. I had a little run in with the Advanced Lights Out Manager (ALOM). ALOM is for “remote out-of-band management”. I.e. its a mini OS that lets you turn the machine on and off. When you start up the machine ALOM boots and you need to log into it to turn on Solaris. However, to log onto this machine you need a Serial->RJ45 cable and have to connect through your computer’s local serial port. Oy! What year is this? This actually wouldn’t have been that bad except that they didn’t ship that cable to me and no one in west Michigan sells one. So after a couple trips to the computer store and some soldering work, I managed to assemble one myself.

Power on. “My goodness, it sounds like a hurricane.”

Onto benchmarks. I had a specific project which I needed to benchmark last weekend involving web services. My first realization was that between my laptop and my desktop I wasn’t able to throw enough raw data at it to make it hurt. The benchmark involved 1K request and 1K response SOAP messages. I was maxing out at 1100 tx/s (about 1MB read/1MB write per second). While this was about 4-5x faster than my 2GHz Dell, I knew I wasn’t pushing it. CPU utilization on the Sun box was about 40% and both my client machines were at 100%. So this weekend I did a more thorough benchmark with large message sizes. I hope to do a follow up benchmark soon with small message sizes (1-5K), but I need to find more client computers first.

The Benchmark

• Server: Sun T2000, 4x 1 Ghz cores, 16 GB RAM
• Client: Dell Dimension 2400
• Network: Crossover cable, full duplex 100 MB/s

The benchmark was designed to test the web service performance of the machine. I developed a Customer web service. It contains the following operations:

• Add: Allows you to to submit an array of customers. (100K request, .4K response)
• Add Async: Same as Add, except no response message (100K request)
• Get: Allows you to retreive an array of customers. (.4K request, 100K response)
• Echo: Echoes an array of customers that you sent back to you (100K request, 100K response)

This should give a good idea of real world scenarios where data is being shared via a webservice. The web service used is described by this WSDL. The web service was run on XFire and Jetty. The underlying XML parser was Woodstox.

Results

I was mostly interested in two main numbers: throughput (MB XML/s) and latency (ms). Lets look at througput first:

As you can see, once we reach enough clients throughput is very consistent. Likewise, the latency scales very consitently with the # of clients:

Conclusions

The T2000 is a great machine. I would recommend it to anyone doing high volume web services. It can easily do 10 MB/s of XML/Web service throughput. To put the above numbers in comparison, it gets more than 5 times the througput of my Intel 2GHz Dell. I really regret not ordering the 8 core version as I think that would have made a big difference in my throughput. Latency is also quite reasonable provided you aren’t throwing more than 10MB/s of data at it. But if you do have spiked loads, it can definitely handle the extra connections. They’ll just need to wait their turn.

The one possible downside of the T2000 is that all the cores are 1GHz. So latency for any single message may be slower than if you were running a 4GHz machine. However, I don’t anticipate this being that much of an issue.

There has been some more good discussion on the need for a WS-QueuedMessaging spec. James responded to my post with:

But there is a need for some kinda WS-QueueMessaging specification so that durability and the full quality of service metadata can be specified - such as to ensure that a message is written to disk before it is acknowledged etc. Even something so apparently simple as writing to disk - you may want to also wait until the disk buffer is really flushed to the disk itself before assuming its written to disk (most disk writes in an operating system go into a RAM buffer that asynchronously gets flushed to disk).

Paul Fremantle also comments:

…WS-RM was never designed to talk about the implementation. RM is a protocol and as such it only talks about the messages and state machines at each end. Talking about the implementations would be a mistake because it would violate the concept of loose-coupling inherent in the Web Services designs. And from what I can tell of the OpenWire spec, it is just the same. The durability of the messages is a function of the JMS servers, not the wire protocol.

Agreed. While I ragged on spec making in my last post, I do believe more support for this type of thing in the WS-* stack would be a good thing. As James said, putting this stuff in policy/metdata would be helpful to specify the QoS.

Paul also does a little SOAP/JMS bashing:

RM also layers much more cleanly with SOAP (and therefore with a wider variety of programming models) than JMS does. For example, at the present, there is no standard definition of a SOAP/JMS binding. Another example is that using WS-RM doesn’t require any further configuration than “turning it on”. Using SOAP/JMS means defining queues, queue connection factories, and all sorts of JMS config.

Not quite sure I agree here. The point about JMS, is that if you are looking at using it, you most likely control both endpoints, so a standard format won’t do you that much good. I don’t think JMS is quite that hard. Or WS-RM that easy.

If JMS is an option, I believe the performance benefits outweigh the “lack of standards” and configuration issues. My order of preference based soley on performance would look like so:

1. JMS< ->JMS
2. OpenWire (Java/C/.NET < -> Java/C/.NET)
3. WS-RM with a durable store

So to answer the title of my post - do we need WS-RM and WS-QueuedMessaging. Yes. There are a lot of situations where we need a standard, reliable protocol. Its just not the right fit for everything.

(Now I’m wondering if I’m like one of those people who won’t give up assembly programming… Am I not embracing the future for “performance reasons”? Or am I being realistic? Or should I get some sleep? Yes sleep…)

Update: James expands on what should go into a WS-QM spec and when JMS does/doesn’t fit. Good stuff. So I wonder who is going to start this spec…

Alexander talks about reasons “to SOAP or not to SOAP”. Now, for the sake of everyone listening (and to keep myself from getting bored), I won’t get into the whole SOAP vs. REST thing. I’d like to pick out one thing, his chart. I don’t think its fair to use the public services (EBay, Amazon, Paypal, etc) as examples for enterprise software. If they use REST or SOAP, does that mean it is appropriate for us? I would be much more interested in a survey of how many enterprises are using SOAP or REST.

I feel that current SOA developments still fall far short of where we could be. I think we need to get rid of XML Schema and WSDL down the line. They’re both abominations. Instead I would like to see Relax NG and something like SSDL.