sca sdo dcom
Wed, Jan 31, 2007
As part of the ASK project I’m federating web services. What this means is basically “shibbing” web services but without, well, Shibboleth. Shibboleth is a browser based SAML profile so can’t be used for web services but if you say to someone who’s scratching their head, “I’m going to shibb web services”, a light comes on!
What’s really involved is WS-Security and it’s SAML token profile. However the main work at the moment is working out how to federate the services once the messages have been agreed upon.
I came up with the SLooP SAML profile a while ago and now I have a chance to refine and implement it in the real world, of ASK anyway.
But while I was thinking about this, I was also thinking about the JISC eFramework and it’s Content Management brick. Should I develop a web services facade in front of the ASK repository and offer a domain level object model for consumers? Or should I just web service the CollectionMananger and ContentManager and let consumers store their own data in their own format in the ASK repository, via the web services?
The domain model would be easier to implement but more restrictive on consumers. They could only store and retrieve ASK defined objects. That’s ok if the model was adopted as an eFramework domain object model but that’s a tall order, considering there is no eFramework yet.
However, while I was mulling this over I started reading about Service Component Architecture (SCA) and Service Domain Objects (SDO). I suddenly realised that I had been considering a type of SDO all along and this awakened an old memory from my COM/DCOM days. The VARIANT.
It seems that I’ve stumbled on something that might lead me down an interesting path. When three things come together like that, I must sit up and take notice.