The Java portion of this conference has apparently begun. This should be good -- Tedis one of DevelopMentor's resident Java geeks

Side thought while I'm waiting for the presentation to start: OneNote would be a verygood blog editor. What I'm doing right now is blogging into OneNote and then pastingit into w.bloggar to put it out on the web. Along the way, I lose a lot of thingslike formatting, bulleted lists, and fontification. I'd really like to see an IBlogThisimplementation for OneNote.

Anyway, Ted's talking about the support for Web Services in EJB 2.1. He did a quickpoll at the beginning of his presentation as to how many people wrote java code. Fora MS-sponsored conference, there were a surprising number of Java coders. However,when he asked if anyone actually liked writing EJB (Enterprise Java Bean) code, noone raised their hands. Which is not surprising at all.

Quick background on EJB: EJB's are objects that contain some form of transactionalmiddleware logic in a J2EE solution. It's important to note that Enterprise JavaBeans!= JavaBeans. Old-school JavaBeans are very much like ActiveX controls. EJB look muchmore like objects that operate under MTS/COM+/Enterprise Services.

One of the more interesting things about EJB's are their support for Entity Beans,which are a really cool idea that nobody likes because the implementation sucks. Entitybeans are how J2EE implements container-managed persistance. Entity bean's try todelegate persistance logic off to the EJB container, basically pushing ORM logic offto the application container. The reason that nobody likes container-managed persistanceis because it doesn't scale at all and requires too much futzing in the data tierto be of any real use in a non-trivial situation. Basically, all container-managedpersistance in Java proved is that ORM is a really hard problem and it's almost impossiblyto do this both transparently and effectively.

So anyway, Java's been playing around with message-driven beans for a long time. But,these guys were playing around with RMI, which is a proprietary Java-Java technology.In the meantime, Microsoft was off trying to figure out how XML could be used to connectsoftware services and came out with SOAP 1.0. Sun ignored this spec because it wasdeveloped primarily by Microsoft and therefore Not For Java. Java basically ignoredthe whole XML messaging thing until about January of 2001, when the figured out thatXML was going to be a pretty big thing and hacked in XML support into J2EE 1.4.

Java got SOAPy with J2EE 1.4 support for the JAXM spec. Basically, this was a reallylow-level SOAP implementation. All it did was specifiy how SOAP message should bepicked up off the wire -- it exposed SOAP messages directly for processing, leavingSOAP consumers up to the own devices as to how to map those SOAP messages to realfunctionality.

JAXRPC is a spec that tries to impose an RMI-like face on web services. There's stillWSDL and schema and SOAP, but JAXRPC sweeps all that under the covers and bends overbackwards to make this whole process look like regular old Java RPC. This can be agood things for Java programmers, but potentially a bad thing for interoperability.

EJB 2.1 interfaces requires a "remote" interface to be defined. This remote interfaceis then implemented on a concrete session bean. Hack up a deployment descriptor documentto expose the service to the application container and you're done. The WSDL for theendpoint is generated by the EJB container, but how this actually happens is not reallyclear in the spec. Thus, how you actually get the service's WSDL varies from one containervendor another.

What's interesting is that all of the WSDL generated by EJB containers are rpc/encoded(not document/literal). Sun has really bought into the idea that web services arejust "Corba.NEXT." This makes native interop with doc/literal web services very different,because each container supports doc/literal through a variety of very vendor-specificincantations. In order to make interop happen, you pretty much have to lock yourselfinto a specific J2EE container vendor.


Tim Ewald just interjected a point...The push for 100% transparency (making the XMLmessage format solely a consequence of the transport mechanism and having the restof the system ignore the angle brackets) is a mistake. In order to achieve transparency,we need a tool to map XML into our language of choice (like the XML Serializer!).The best we can do is achieve translucency and hope that we can peer into the plumbingwhen we need to figure out where it broke.

The more I think about it, the more I'm thinking that the XML Serializer is a bad,bad, thing when it comes to developing web services. Not so much because it does badthings, but it promotes the illusion of type fidelity and causes developers to builda mental model about the system that they're building. XML Serialization makes systemdesigners think in an object-centric mindset. I put in a question about this; hopefullywe'll talk about this at the Q/A session later.


Someone raised the question: "Why is the development community forced to choose betweenimplementations done by evil people and implementations done by brain damaged people?"