netzooid

ApacheCon Meetup

I’m headed off to ApacheCon tomorrow morning (much to my chagrin – I thought I was leaving Sunday until about 15 minutes ago). If you are around and want to meet up (and don’t already know that you’ll see me there) send me an email: dan at netzooid dot com. Looking forward to seeing you there.

Add comment December 9th, 2005

5 Cool XFire Hacks

In the spirit of 5ives – I’ve decided to put together 5 XFire hacks.

1. Inject the MessageContext

Sometimes you’ll want to get ahold of data in the MessageContext like Headers or the SOAPAction or any number of other things. Doing so is as simple as can be. Just declare the MessageContext as part of your operation’s method signature. XFire will then inject it for you to use.

public String echo(String text, MessageContext context) {
   // do something with the MessageContext
   return text;
}

2. Create a Source endpoint

JAX-WS has the Provider interface which lets you implement a service which just works with the XML. Its quite easy to create this in XFire too. First write your class:

public class Provider {
  public Source invoke(Source source) {
    // do something with the xml
  }
}

Then create a service from it:

ObjectServiceFactory osf = new ObjectServiceFactory();
// the ServiceFactory defaults to a wrapped style, and we don't
// want our operation name showing up in our soap:Body -
// so switch to a "document" style.
osf.setStyle("document");

Service service = osf.create(Provider.class);
xfire.getServiceRegistry().register(service);

3. Dynamic Client

Invoking unknown services at runtime? This is pretty easy with our dynamic client:

Client client = new Client(new URL("http://localhost:8080/Echo?wsdl"));
Object[] response = client.invoke("echo", new Object[] {"hello"});
String echo = (String) response[0];

4. On the fly transformation

Lets say you’re writing a handler, but need to load up the request into an XML document. Since XFire just works with streams this can be a little bit tricky. But luckily there is an efficient and neat way to do this:

public class TransformationHandler extends AbstractHandler {
  public void invoke(MessageContext context) {
    XMLStreamReader reader = context.getInMessage().getXMLStreamReader();

    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    DocumentBuilder builder = factory.newDocumentBuilder();

    Document doc = STAXUtils.read(builder, reader);

    // do something with the doc

    context.getInMessage().setXMLStreamReader(new W3CDOMStreamReader(doc.getDocumentElement()));
  }
}

5. Grab the XMLStreamReader directly

This is quite like #2, but quite a bit more efficient because you’re just working with the XMLStreamReader

public class MyService {
  public XMLStreamReader doFoo(XMLStreamReader source) {
    // do something with the xml

   return readerForOutput;
  }
}

You’ll need to use the MessageBinding when creating the service for it to be able to understand the XMLStreamReader:

ObjectServiceFactory osf = new ObjectServiceFactory();
osf.setStyle("message");

Service service = osf.create(MyService.class);
xfire.getServiceRegistry().register(service);

Add comment December 9th, 2005

Mindreef Coral: Wow

Just read about what Tim Ewald has been up to at Mindreef: their new product called Coral. If you thought SOAPScope was cool, check out Coral. It adds in a whole new collaborative aspect that appears to be pure genius. And once again with a beautiful interface!

Add comment December 8th, 2005

Shoutout

I just found out that several of my friends at GE read my blog. Hi guys!

You know why I like GE? GE’s CEO, John F. Welch, Jr., is a Chemical Engineer. Little known fact about me: I’m a chemical engineer. Two peas in a pod, yup.

Add comment December 8th, 2005

XOM 1.1 Released

XOM 1.1 has been released! Its now even faster and has XPath support. Congrats to Elliotte and everyone else who participated. If you are working with DOM there is no better way than XOM. Now if only we could get something like this into the JDK…

Add comment November 30th, 2005

Re: To SOAP or not to SOAP

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.

Add comment November 27th, 2005

Tim’s XFire Stats

In case you missed it on the XFire blog, Tim Pokorny has posted some numbers on XFire’s SOAP performance. He is showing 80+ transactions per second with 4K messages and notes that the bottleneck is probably the Axis client. All reports seem to be coincinding very well and with very positive results. If you’re are having high latencies or low transactions per second, I think you could realize real gains by switching to XFire.

Since we’ve started to get a lot of performance reports recently, I’ve started a performance page on our website to collect them all. If you’re using XFire we’d love to hear from you as well.

Add comment November 21st, 2005

The cons of the Apache Software Foundation

Susie over at the Apache Marketing Blog (is this official???) writes some thoughts on why your project should be at the ASF.. While I like the ASF and I work on some projects there, I feel like the article is both horribly idealistic and one sided.

My main gripe is the idea that community results in a better product. Susie tries to convince the ActiveGrid project that Apache is the place to be.

Why not foster the kind of community that could create the kind of momentum you’d want to spread a message of this magnitude? A well marshalled community usually trumps one single voice (no matter how articulate it is) in beating the drum.

I don’t agree with this at all. One only needs to look at Apache to find this is not the case. Cosinder the Avalon project. Too many voices couldn’t create a coherent vision. As Eliotte Harold from XOM has demonstrated cathedral development can result in a much cleaner API and much better software.

This isn’t to say I don’t like Apache. I use software from Apache all the time and am a committer there. It just isn’t for everyone and doesn’t necessarily result in better software.

2 comments November 19th, 2005

More Notes on SOAP and XFire Performance

I ran across this entry on XFire performance from Tim Pokorny by accident yesterday. While I feel my numbers speak for themselves, its always good to hear it from a user:

...I decided to run only one client for 60 seconds and only on the AMD. It was able to get 3919 iterations completed in those 60 seconds. That is more than 65 updates per second. Perhaps the most amazing thing about this is the actual performance of web services (XFire in this case). These were not small updates either; two entities, each with something like eight attributes were being serialised into XML, sent over the wire and de-serialised into Java objects 65 times per second! That is HUGE. To put this in perspective, when previously asked by people about the real performance of web services (in the simulation context) I estimated that I could consistently get about 8 updates a second. Needless to say, 65 is almost an order of magnitude faster than that.

Eat that Axis!

(NOTE: I like the Axis guys and even recommend Axis in certain scenarios, I just like to jab them about their performance. )

Add comment November 3rd, 2005

Shrinking a Physical Volume on Linux

Here is a quick guide on how to shrink/reduce a physical volume on linux:

First backup the configuration so we can edit and restore it.

# vgcfgbackup

Now you need to edit the backup config file. Go to the physical volume you want to resize (in my case pv0) and change the block size to what you want it to be. In my case I changed it from 4708 to 2874. Also take note of the ID.

# vi /etc/lvm/backup/VolGroup00

Next you need to commit the changes to the partition: The UUID is the id from the step above. You’ll also want to use the correct hard drive – which is most likely not /dev/hdd2. Run the “pvdisplay” command to figure out which one it is.

# pvcreate --restorefile ./VolGroup00 --uuid "l4wJi3-JDQb-7sjZ-B3oH-Va0D-v2Sp-FX2s3q" /dev/hdd2 -ff

Last, you need to restore your edited backup file:

# vgcfgrestore

And presto, your volume should be smaller now.

Add comment November 1st, 2005