netzooid

I was driving along today, thinking (yes thinking) that I have a love-hate relationship with Steve Loughran’s blog. Sometimes its like a mini bile blog for all the little things that go wrong or how things should be with the software he uses or attempts to use. The thing I like is that I supsect the reason for all these posts is that he still expects software to work right (however rare that is). This realization gets me thinking even more.

Being quite young, I don’t have a lot of perspective on the last 30 years regarding how our expectations for “buginess” have changed. I would like to harken back to olden times when everything “just worked,” but I doubt things were ever like that. I actually think we’ve gotten better at managing complexity. There are are still a lot of issues though. Take Java for instance. First we have the VM. Then we have libraries. Then we have libraries which use other libraries. And if we’re lucky, finally an application. Oh and don’t forget about knowledge in Servlets, JEE, XML, HTML, and database programming. I tried to bring a PHP programmer into the world of Java recently, but it was all a bit overwhelming. To create a simple webapp he had to master Servlets, Hibernate, Webwork, Velocity/Freemarker/JSP, and Java. No small task. Maybe tools like Maven can help manage this and help people get started a bit easier, yet you still need to know every underlying layer.

<rant>
AND when will CS departments get their acts together. I skipped out of CS because I looked at the course schedule and found it basically worthless. How many schools even cover beyond the basics of Java or writing a webapp or, god forbid, web services. I recently hired an 18 year old fresh out of high school. He knew more about writing enterprise software then most freshly graduated computer science grads I’ve met.
</rant>

Lets not forget about SOA. If you subscribe to the web service point of view there is WSDL, SOAP, WS-*, BPEL, and all the XML intracies. Writing a good WSDL is no easy task for the average programmer. Maybe it doesn’t need to be though, maybe it just needs to work Good Enough like all the VB apps that are laying around.

This all leaves me with a lot of questions:

• Are we ever going to be able to work at a higher level of abstraction?
• Will domain specific languages play a part?
• What other tools might help us get there?
• How can we educate people better?

(For all of you who don’t know the answers to the above questions, it is of course Ruby)

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.

In the spirit of “5ives”:http://5ives.com - 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);

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!

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.