gettin all zoidal on ya
If anyone tells you that Office 2007 is anything less than incredible, don’t listen to them. It is incredibly intuitive. Its a pleasure to use. The resulting documents also look better thanks to things like SmartArt and an improved color scheme. But, the bottom line is you spend less time creating your documents than you do with older versions of Office, and that is a good feeling.
I was doing a bit of a thought experiment recently about the effects of reliability on performance. Basically I wanted to know a) will WS-RM affect the performance of my application and b) how does it compare to a RESTful HTTP approach. The quick answer is that it depends (like most complex questions in life).
WS-ReliableMessaging
In the RM case the first question that needs to be asked is what type of message exchange patterns am I working with?
WS-RM specifies that we receive a <SequenceAcknowledgment> for every N messages. If we are using a request/response this gets combined into the SOAP response headers. If we have one way messages we’ll receive a new SOAP Envelope every so often with just some acknowledgement headers. There will also be a <Sequence> header with each request message. And if you aren’t already using WS-Addressing, headers will be inserted for it on both the request and response.
In a typical service invocation we have the following items which consume our processing time:
Right away, we can see if we’re dealing with large messages, RM will have very little performance affect on our service. Whats another 600 bytes if you’re already sending around 20K?
So lets look at what might be the worst case: one way message which are < 1K. For 1K one way messages HTTP ends up being about 30% of the processing time (roughly). Lets also assume for now that your time spent in the service (i.e. doing database stuff) is negligable.
Performance degradation = (1K*1.3 + .6K) / (1K*1.3) = 146%
The “*1.3″ is to factor in HTTP processing time – which ends up being the equivalent time of processing a .3K message.
Its important to remember that this completely disregards server side processing time, so I think the worst case for a 1K one way message is probably more around 30% degradation in performance. For larger messages its probably safe to assume that it will probably have a 5% or less performance impact.
Acknowledgements
You may have noticed this completely ignores acknowledgements. For now I’ve assumed those will only occur every so often, so they won’t have a huge performance impact. If we look at the extreme situation, I can see where we might have 100 clients, each sending 1-2 messages per second. How many messages will the server want to buffer here? If these are small messages and we end up acknowledging ever 3rd or 4th message, this could have a big impact.
HTTP with Idempotent Methods
We should also be able to achieve reliability through idempotent methods. PUT and DELETE are idempotent which just means we can “attempt to transfer our state” (aka submit our data) as many times as we’d like – until we receive a response code. Any time we’re retrieving data, we can issue GET as many times as we’d like as GET does not change the server side state.
Right away its clear that if our application is only retrieving data, the RESTful HTTP approach does not have any impact. We simply issue GETs and don’t do any extra work. Of course, if you’re only retrieving data you probably wouldn’t enable WS-RM because it wouldn’t add muchh value there either, so this really isn’t an interesting case.
Lets say I want to submit an order for some widgets. This will become a two step process with HTTP. First, a POST to /widgets/order. This will return a URL to a place we can PUT our order – i.e /widgets/order/abc-123. The server will listen at that URL for new orders and only accept one order there. The client will submit as many times as it needs to.
Performance does degrade here as it involves an extra POST. The degradation is probably comprable to the one way small message case in WS-RM, but I don’t have any numbers handy to prove that. The nice part is that you only take this hit when you’re actually transferring state. If you’re application is 90% GETs then you probably won’t see a huge impact here regardless of your message sizes. On the other hand if your application is continually submitting data this approach will probably have an impact.
Conclusion
Each approach can be made to work I think. Which one you chose probably depends on your application and use cases. Are you sending lots of data? Are you only retriving data? Also, what about interoperability, ease of use, and integration with existing architectures? And we haven’t even touched the possibilities of using something like JMS or OpenWire here. It seems performance is just one question of many for service builders.
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!
Comments on the blog here have been re-enabled thanks to the lovely Askimet plugin that comes with WordPress 2.1. Discuss away!
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 need a blog. Who can I get to write it for me?”
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:
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 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.
I missed the goal for Platinum Elite of 75,000 miles on Northwest by 135 miles this year. Not because I didn’t fly enough miles. I couldn’t figure out how to book my trip to Belgium on Delta with my frequent flyer number (yes I’m stupid) so I have about 6000 miles uncredited to me. I might still have a chance at those priority first class upgrades though, but the airline isn’t making it easy. What does NWA want me to do to get that credit? Physically mail in all my ticket info to them and wait 6-8 weeks. Are you for cereal*? I hope manbearpig hunts them down.
* See definition #3
The iPhone revealed today certainly looks very cool. It is thin, seems to have decent battery life, looks good, and has an interesting touch screen interface.
Two thoughts after being a long time smartphone person:
The main lesson being here that tactile feedback is important. The iPhone looks good enough that I might be wrong though. I will have to reserve judgment for now.
Also, EDGE sucks. Can’t we have UMTS please?