Friday, July 20, 2007

Direction

Life got crazy (moved to a new house), and I haven't been able to spend as much time on this as I would like. So, here's a dump of where I'm thinking for this project.

As I get into this more and more, it seems like the SOAP1.2 part of this project is pretty ambitious. Given the NaHi (the main developer of SOAP4R) hasn't touched SOAP 1.2 yet, I'm skeptical that I'll be able to integrate anything nicely into his library that will handle the new spec. That said, for my project, I've been able to generate stub code from the SOAP4R library, which means that we aren't doing anything that is technically new in SOAP1.2. Additionally, I'm really only interested in the MTOM attachment mechanism (now that DIME is officially DOA), not the down and dirty details of SOAP. This all leads me to think that the value added here would be to create a wrapper for the SOAP4R library that runs a transform on the incoming and outgoing messages and:
  1. Changes the namespaces to indicate SOAP1.2 messages and trigger the correct parser on the receiving end.
  2. Makes any other changes to a SOAP 1.1 message to make it semantically acceptable to a SOAP 1.2 parser.
  3. Extracts the Base64Encoded message parts, optimizes them and creates the correct envelope structure (the actual implementation of the MTOM specification).

Again, from the specification, I'm not sure what the functional relationship between MTOM and SOAP1.2 is, other than they were both released at the same time. Given that MTOM and XOP operate outside of the SOAP message spec, and don't alter the non Base64Encoded parts in any appreciable way, making a message completely compliant with the SOAP1.2 spec may not be necessary at all (which would reduce the amount of work on my end by an order of magnitude.)

Stay tuned: next up is creating the wrapper class and trying to clean this up so that it might be useful to someone on another project.

No comments: