Yesterday I was chatting with my friend Marty about WS-Transfer and the fact that we weren’t aware of any implementations out there. So, I challenged myself to write one in 30 mins using WSE. Well… it didn’t take 30 mins but a couple of hours because of a stupid bug related to WSE attributes… I had associated the same string for two SoapMethod attributes and I couldn’t see it in front of my eyes 🙁 Anyway…
So, when I finished the implementation (it’s such a simple spec so this is not a major task) I sent it to Marty. The implementation was using an in-memory hashtable to maintain the state representations of the resources. Of course that’s not a good idea because there is no persistence and no way to farm the service. Since I got back to coding, even for a while, I thought of refactoring what I already had and then give the code to PlumbworkOrange. John was kind enough to agree to make the code part of the project (pending some code-review I guess). I just sent John the code; if there are no serious problems, it may soon appear in the PlumbworkOrange repository so the real testing can start.
The current version of the code is based on resource providers; the code comes with two: an in-memory and a file-based provider. A resource provider implements the store of resource states. The next step is for someone to write a provider for a database. I’ll write some documentation about how to interact with the service and how to implement a resource provider.
As a final note I must note that although the WS-Transfer spec is fully implemented, there is a versioning problem which relates to WS-Addressing. WS-Transfer uses a newer version of WS-Addressing than the one supported by WSE 2.0 so this implementation won’t be interoperable with other, proper implementations of the spec. This is not because there is an explicit dependence on a WS-Addressing version in the code; it’s just the underlying pluming that deals with WS-Addressing-related XML. With all the WS-* specifications being moving targets at the moment (see standardisation process), this is to be expected.
Please try this and the rest of the spec implementations provided by PlumbworkOrange and let me know of the problems you encounter.
See "BrainExpanded - Introduction" for context on this post. Notes and links Over the years,…
This is the first post, in what I think is going to be a series,…
Back in February, I shared the results of some initial experimentation with a digital twin.…
I am embarking on a side project that involves memory and multimodal understanding for an…
I was in Toronto, Canada. I'm on the flight back home now. The trip was…