Monthly Archives: May 2007

CMDBF update

My CMDBF colleague from BMC Van Wiles has a short update on the state of the CMDBF work. This is an occasion for me to point to his blog. I know that several of my readers are very interested in the CMDBF work, and they should probably monitor Van’s posts in addition to mine.

Like Van, I see the pace accelerating, which is good. More importantly, the quality of the discussion has really improved, not just the quantity. We’ve spent way too much time in UML-land (come on people, this is a protocol, get the key concepts and move on, no need to go in UML to the same level of detail that the XML contains), but the breakthrough was the move to pseudo-schema, and from there to example XML instance docs and finally to java code for the interop. I am having a lot of fun writing this code. I used this opportunity to take XOM on a road test and it’s been a very friendly companion.

Now that we’re getting close to the CMDBF interop, I feel a lot better about the effort than I did at the beginning of the year. It’s still going to be challenging to make the interop. Even if we succeed, the interop only covers a portion of what the spec needs to deliver. But it will be a very good milestone.

1 Comment

Filed under Everything, Implementation, Specs, Standards, Tech

XMLFrag SOAP header

This HTML document titled “XMLFrag header” describes a proposal I wrote for a header that would allow one to target a SOAP message to a subset of the resource to which the message is sent. This is useful in cases where messages are used to interact with systems that have a well-known model, as is often the case in the IT systems management world. If you’ve ever used or been intrigued by WS-Management’s “FragmentTransfer” header, or WS-ResourceProperties’s “QueryResourceProperties” message or WS-RessourceTransfer’s “Expression” element then you may be interested by a different approach that is operation-independent. Please read the example at the beginning of the proposal for an explanation of what XMLFrag does.

I think it’s nifty, but I am not sure how much need for this there is. Are the composition/mash-up scenarios that this allows important enough to replace well established alternatives, such as WS-Management’s “FragmentTransfer” header? I am not sure. Which is why I am putting this out, to see if there’s any interest.

One possible approach would be to generalize WS-Management’s current mechanism to support the features presented here. This could be done very easily and in a backward-compatible way by declaring that the response wrapper (wsman:XmlFragment) is not applied for all dialect but defined in a per-dialect fashion. The currently defined dialects would keep using the wsman:XmlFragment wrapper, but a new dialect could be defined that didn’t use a wrapper and would behave like the XMLFrag element defined in my proposal.

A few additional notes and comments:

This proposal has been called “WS-SubversiveAddressing” by some of my IBM friends who have very definite ideas about what belongs in SOAP headers, what belongs in the body and what headers are appropriate to use as reference properties in an EPR. And this proposal seems to break all these rules. But since the rules seem more inspired by lack of flexibility in the WebSphere message routing/processing capabilities than by true architectural constraints I am not too worried. I would even say that this proposal represents the only kind of header that really make sense to use as reference properties. Headers that sometimes are set by the sender explicitly and sometimes are hard-coded in the EPR used. Using reference properties for headers that only come from reference properties (and aren’t expected to ever be set explicitly by the sender) is a sign of lack of ability of the stack to route messages based on URL. A too-frequent limitation of Java SOAP stacks. But I am digressing…

I didn’t think there was anything worthy of a patent in this, but in these sad times you can’t be sure that someone is not going to try to get one for it, so just to be sure HP published this a year ago in Research Disclosure so that no-one can patent it. If you want to check, it starts on page 627 of the May 2006 Research Disclosure (not available on-line unless you have an account w/ them, but you can order it). So in reality, this document has already been public for a year, but in a pretty hidden form. This post just gives it a little bit more visibility.

This is not a spec. It is just a description of what a spec could do. It doesn’t have normative language, it doesn’t provide formal syntax (pseudo-schema, XSD and/or other) and it doesn’t address some of the details that would be needed for interoperability (e.g. what namespaces declarations are in context for the XPath evaluation).

Why use a car fleet as an example for illustration? For the same reason that the SML spec uses a university (class/student) example. To pick a domain that is different from the expected domain of application of the technology to not invite modeling discussions that are irrelevant to the proposal and to not biaise people’s view of what this could be used for.

Is there a relationship between this and federation efforts? Sort of. This could be very useful when exposed by a a federator, if the model is very hierachical. But it doesn’t work so well for graph-type models. Which is what CMDBF does and which is why CMDBF is coming up with a more graph-oriented approach. But that too is a different topic.

4 Comments

Filed under Everything, SOAP, SOAP header, Specs, Tech, XMLFrag

Omri on SOAP and WCF

Omri Gazitt presumably couldn’t find sleep last Friday night, so he wrote a well thought-out blog post instead. Well worth the read. His view on this is both broad and practical. There is enough in this post to, once again, take me within inches of trying WCF. But the fact that for all practical purposes the resulting code can only be deployed on Windows stops me from making this investment.

And since he still couldn’t sleep he penned another entry shortly after. That one is good but a bit less convincing. Frankly, I don’t think the technical differences between Java/C# and “dynamic languages” have much to do with the fact that stubs hurt you more often than not when developing code to process XML messages. With a sentence like “in a typed language, the conventional wisdom is that generating a proxy for me based on some kind of description of the service will make it easier for me to call that service using my familiar language semantics” Omri takes pain to avoid saying whether he agrees with this view. But if he doesn’t (and I don’t think he does), you’d think that he’d be in a pretty good position (at least on the .NET side) to change the fact that, as he says “the way WSDL and XSD are used in platforms like J2EE and .NET tends to push you towards RPC”…

I haven’t used .NET since writing C# code back when HP was selling the Bluestone J2EE server and I was in charge of Web services interoperability, so I have limited expertise there. But Java has the exact same problem with its traditional focus on RPC (just ask Steve). I am currently writing a prototype in Java for the CMDB Federation specification that is still at an early stage. All based on directly processing the XML (mostly through a bunch of XPath queries) and it makes it a breeze to evolve as the draft spec changes. Thank you XOM (and soon Nux).

I very much agree with the point Omri is making (that relying on metadata to add complexity in order to remove it) is an issue, but it’s not just for dynamic languages.

Comments Off on Omri on SOAP and WCF

Filed under Everything, Implementation, SOAP, Tech, XOM

All things (not very carefully) considered

Another off-topic entry to add to the CrazyStats category. Today’s NPR’s “All Things Considered” included a report called “States Fret at Easing of Border Security Plan” which talked about “Operation Jump Start”, so described:

“For about a year, National Guard troops have been rotating in and out of outposts along the [US-Mexico] border. Soldiers stayed visible under blue tents right on the border to deter illegal crossers while scanning the landscape, reporting anyone who did cross.”

It then goes on:

“The deterrent worked. The number of crossers apprehended by the Border Patrol since last October is down by about one-third, while drug seizures are up.”

The implication seems to be that would-be illegal immigrants were deterred by the presence of the troops and that drug traffickers were not deterred but were more often caught thanks to the help of the troops (who presumably either directly caught drug carriers or freed up Border Patrol resources to go after them). Success! But what if the result had been the exact opposite? More crossers apprehended and fewer drug seizures. Couldn’t that just as easily be interpreted to mean that the troops helped in catching more crossers while providing reinforcements that deterred drug traffickers? When opposite results can be interpreted to both mean success the test is suspicious.

1 Comment

Filed under CrazyStats, Off-topic

A new management catalog proposal

As part of the work around the convergence of WS-Management and WSDM, HP, IBM, Intel and Microsoft just published a first version of a specification called WS-ResourceCatalog. This specification provides a way to list management endpoints for resources. For example, the BMC on a server motherboard could host a catalog that lists the management endpoints for its different components (network card, CPU, disk, etc). This is an attempt to bring more consistency to discovery scenarios.

The spec has been submitted to the DMTF for its consideration as part of its Web services-based management protocol efforts. The submission includes a list of issues related to the spec, so it’s pretty clear that it’s nowhere near done. Rather than hammering things out even longer (trust me, it’s been too long already), we decided to hand it over as is to the DMTF and let its members decide how to handle the issues. And any other change they wish to make.

1 Comment

Filed under Specs, Standards, Tech, WS-ResourceCatalog

Want to play a minesweeper game?

Since I am on a roll with off-topic posts…

I accidentally ran into some Web pages and scripts I wrote between 1994 and 1996. Mostly experiments with Web technologies that were emerging at the time. Some have pretty much disappeared (VRML), some are still pretty useful but slowly on their way out (CGI) but many of them are very prominent now. I found a bunch of Python scripts I wrote back then, some Java apps and applets and even a Minesweeper game written in JavaScript. And the impressive thing is that even though those were all pretty early technologies at the time, these programs seem to run just fine today with the latest virtual machines and interpreters for their respective languages. Kuddos to the people who have been growing these technologies while maintaining backward compatibility. Speaking of technologies that were emerging at the time and have made it big since then, all these were served from a Linux server and the Python stuff was developed on a Linux desktop (Slackware was the distribution of choice).

1 Comment

Filed under Everything, Game, JavaScript, Minesweeper, Off-topic, Tech

We won’t get rid of SSN-based authentication anytime soon…

… because the issue has been mixed up with the whole terrorism/DHS hysteria. Game over. So now we have “Real ID” which won’t stop any terrorist but somehow is marketed as an anti-terrorist measure. I don’t like this law because it is too focused on physical identification (ID card) and not virtual identification. Trying to impersonate someone in person is difficult, dangerous (you risk being arrested on the spot or at least having your face captured by a security camera) and doesn’t scale. Doing it virtually is easy, safe and scales (you can even do it from anywhere in the world, including places where labor is cheap and the FBI doesn’t reach much). So this is where the focus should be. Also, this law is not respectful of privacy (the “unencrypted bar code” issue, even though if someone really wanted to systematically capture name and address from ID cards today they could take a picture of the ID and OCR it, the Real ID-mandated bar code would only make things a little easier).

On the other hand, I also can’t go along with the detractors of this law when they go beyond pointing out its shortcomings and start ranting about this creating a national ID card. While it’s true that this is what it effectively does, someone needs to explain to me why this is bad and why this would make the US a “police state”. If really such IDs are so damaging to liberties, why is it ok for every state to have them? What makes a national ID more dangerous than a state ID?

I agree that the Real ID effort is a bad cost/benefit trade off in terms of protection against terrorism. But leaving terrorism aside, we do need a robust (not necessarily perfect) way to authenticate people to access bank accounts and other similar transactions. In that respect, something like Real ID is needed. And in that context, the cost/benefit trade-off can be hugely positive if you think of how much impersonation costs and how much friction it creates in the country’s economy.

As long as we live in denial about what a Social Security number represents and as long as we can’t think sanely about terrorism, there can’t be an answer to the authentication problem.

Comments Off on We won’t get rid of SSN-based authentication anytime soon…

Filed under Everything, Identity theft, Off-topic, Security, SSN