Friday June 16, 2006 Instant Messenger Byoms
Ok, I spend too much time reading and trying new stuff out. But I was recently reading an article in MIT's Technology Review about Instant Messanger Bots. There is a pretty interesting company called Kozoru that has a product called Byoms. You can create a IM Bot really easily. So of course I had to try it out and what better way to try it than to create one for a CNS project. Well the new Sun Knowledge Center requires authentication to get any data out of it and Byoms has no way to provide credentials to a site collection, so I went with the Sun Knowledge Center's predecessor SunSolve. I created a IM Bot using AOL Instant Messenger named "SKCByoms". Go ahead and try it! just add a new buddy to your IM with the SKCByoms screenname and then try asking it a question, something like "How do I create a Solaris zone?".You can also try clicking on this button and it should add this bot to your IM client.....
Sun Knowledge Connection and Google???
I was recently reading the blog of Mike Harding, the VP of Customer Network Services, and he had an entry on the Sun Knowledge Connection Early Access release. Since we had a recent "innovation day", I was playing around with some of the Google developer tools that they have and was able to pretty quickly create a Google gadget for the Sun Knowledge Connection search.
If you use the Google Personalized home page you are able to add little gadgets to the page to read news, check sports, check stocks, view weather, and now search the Sun Knowledge Connection! Anyhow, below is a screen shot of my the SKC gadget (I didn't integrate the login yet so you have to already be logged into SKC, minor quirk).
It's not as pretty as the real Sun Knowledge Connection, but I'm not quite the UI expert either. You can click here to just add this to your Personalized Google Page.
Consumer Driven Contracts for SOA
I work in Customer Network Services, a group in the Software organization at Sun. The team that I lead is tasked with developing "Common Components and Services" for the rest of our organization. One of the things that we have been struggling with (among many other struggles) is defining common, reusable services that are easily extensible without breaking all of the clients that are using them. Of course, in order to know if you are going to break the clients that are using the service, you first have to know who is using the service and how they are using it. We have a relatively large organization, and although we work closely with each team integrating with our common services, we have quickly lost track of all the ways that teams have integrated with our services. Short of digging through all of the code over the past 2 years, we have no way of finding out either. So, how do we fix this going forward for the new services that we are building? That's what I've been trying to figure out lately.
I was reading an interesting paper today by Ian Robinson titled "Consumer-Driven Contracts: A Service Evolution Pattern" that proposes something so simple, yet is a radical shift to how we develop services within our group now. "The underlying assumption here is that services, by themselves, are of no value to the business; their value is in being consumed. By specifying services closer to where they are being used - by consumers - we aim to exploit business value in a lean, just-in-time fashion." [Robinson]. Makes sense. The idea behind consumer driven contracts for a service oriented architecture is to let the consumer of a service define the contract for the service that the producer publishes. That seems like just basic common sense. But, not only in my current team, but in numerous projects across Sun and in my past, I see the service producer attempting to create this perfectly reusable service by abstracting everyone's requirements into something that isn't capable of evolving without even the most minor modifications breaking everyone. We keep coming up with service versioning strategies that never seem to work as well as we hope, and that is primarily because we are unable to clearly articulate the exact dependencies that are on a service so we are unable to determine what it means to be backward compatible.
In order to get us moving in the right direction, I am proposing that we begin to follow a consumer driven contract approach for our service definitions. As Ian notes in his paper, this won't solve our evolutionary problems, but it will allow us to understand how we can evolve our service. That is one better than we have now. Not only does this allow us to understand the dependencies on our services better, but it also helps us to better focus our services on providing business value. Instead of driving towards the ideal of Reuse Based Software Engineering we should be focusing our efforts on providing tangible value.
We currently have a reusable asset library which documents all of our services and components. I plan to add a section to each service for the consumer driven contract. This will document:
- the consumers of the service;
- what functions and elements (the schema use and interface use) that the consumer is using;
- specific conversational state expected by consumers;
- and finally policies and quality of service needs of each consumer.
Bibliography
- Robinson, Ian. Martin Fowler's Blog. 12 Jun. 2006. Thought Works. 16 Jun. 2006. http://martinfowler.com/articles/consumerDrivenContracts.html