« Previous day (Jun 21, 2006) | Main | Next day (Jun 23, 2006) »
20060622 Thursday June 22, 2006

LinkedIn as a leading indicator

I've been using LinkedIn for a few years now to manage contacts of colleagues that I work with or have worked with. It's mainly a way to keep in contact with a network of people that might be able to help with a job search should the need arise. Recently (the past 3-4 months), a current colleague of mine (mon collègue français préféré) and I have noticed a significant increase in the LinkedIn activity of people at Sun. We see this by the number of people that ask us to join their network, or once you're in someone's network, you can see the number of new people that they add to their network on an ongoing basis. With the publicly announced layoffs at Sun the traffic on LinkedIn has hit a crescendo.

Not only do you see these upturns in traffic when layoffs are eminent, but when a group of people, say a particular organization is unhappy with how things are going and do not feel confident in the direction that things are headed. I believe that LinkedIn could sell this type of data! They could sell it to directors and VP's to be able to gauge the response to recent changes and directions that they are taking their organizations. They could sell it to wall street analysts who want to gauge the employee confidence in the company that they work for. They could sell the data to recruiters who want to know where new recruits or new position openings may be coming from. Wow, there are virtually unlimited possibilities of cool, but likely useless things you could do with that date.

Anyhow, join my LinkedIn Network to help throw the data off.

Posted by mikedav ( Jun 22 2006, 05:49:40 PM PDT ) [Listen] Permalink Comments [3]

Extension and Versioning for Service Oriented Architectures

As I mentioned in a previous post here, my team has been struggling with some issues around extending and versioning of services. The problem manifests itself in having very incomplete and short sighted requirements for one application that in no way meet the requirements of the next application and then trying to force a common service that both applications use as a blackbox. There are a few problems that, in my opinion, are the root cause of this struggle: the lack of a versioning strategy for WSDL's and document schemas; our inability to understand how our clients are utilizing our services; and the technology used by our clients to integrate with our services which causes them to be tightly coupled to the service.

So we have no versioning strategy! What this has caused is that changes we make to services are next to impossible to get to be backwards compatible, we're no where near thinking about forwards compatibility..... An old W3C draft document talks in depth about how to create versionable xml documents. Some of the most useful pieces of this article discuss the need to begin to implement Must-Understand and Must-Ignore constraints in the XML documents and to design these documents in a way so that they have clear points of extension which will not break clients when new elements are added at the extension points. Also discussed, is the need to version documents at different level, sometimes even down to the element level. All of that is a lot to bite off at one time, so to begin with I believe that introduing Must-Understand and Must-Ignore constraints into the documents will make a huge step forward. Must Understand is essentially a Big Bang approach, the client is forced to understand new elements, if they don't understand an element, abort and fail. This would be used in situations when a new required element is being used. Must Ignore differs in that if the client doesn't understand a new element then they are allowed to ignore it without failing. This would be used in cases where new elements are optional, which is what we should attempt to default all new elements to. This goes the other way as well, if we are removing an element, then instead of completely removing it we can begin by making it optional with a Must-Ignore constraint. This would be similar to the beginning of deprecating a Java element. Eventually, as clients move to newer versions (and we understand what they are using), we are able to completely remove the unused element.

What makes our lack of a versioning strategy so painful is that we have no idea how clients are actually using the services. What elements, port types, attributes, etc are really being used, and which are essentially sitting idle? We do not know this answer. This is really the core of what I blogged about recently here. Basically we need to move to a Consumer Driven Contract model which essentially just means that we will document the direct use of the services to the element, atteibute and port type level. This simply gives us insight into how clients are utilizing our services.

Even if we intimately understand how clients are integrating with our services and have the world's best versioning strategy in place and follow it to the letter, our hands will still be tied due to the way that clients are integrating with web services. The typical (anti-)pattern I see for web service integration using Java, is to download the Web Services Developer Pack, then start by getting the WSDL and running wscompile on that to generate the client stubs. What this essentially does is pretty tightly couple the client to the particular WSDL. There are few changes that we are now able to make that will not require that client to re-run wscompile and re-generate the entire set of client stubs and likely the entire set of transfer objects that were created. Even if we modify the WSDL and the schemas in a compatible way it is highly likely that it will force a recompile for the clients. This violates the whole tenant of SOA which strives to be a loosely coupled grouping of services which any client can integrate with and the service can be modified in a compatible way without the knowledge of the clients. So how do we fix this? We have to begin moving client integrations to a less coupled integration mechanism. Tools like Schematron can help to decouple clients from services by looking only for the specific elements and attributes that the client needs in a document as opposed to consuming the entire document even though only part may be needed. That allows the service to change more fluidly without worry of breaking all clients.

So, to wrap this up, ya we have some issues that we're dealing with, but there are solutions to solve them. We just need to take a methodical approach to this, first putting a basic verisoning strategy in place, then understanding how current and new clients are utilizing our service, then we can address how those clients are integrating with us so that they are not so tightly coupled to our services making themselves brittle and unable to handle even simple modifications. Once we get these seemingly simple things in place, we can begin to move forward with truly reusable services that are able to evolve over time to better meet the needs of more consumers.

Links referenced in this article or where info was used from:

Posted by mikedav ( Jun 22 2006, 04:16:20 PM PDT ) [Listen] Permalink

Strengthen and Protect the Magnuson-Stevens Act

Ok, so accuse me of being an environmentalist, but I care about the issues that impact the places and sports I enjoy the most. This particular topic is a care of mine because of my love for the ocean. How can that be since I live in Colorado you ask??? Well I grew up on Guam, in the middle of the nowhere ocean, and my wife and I spend a fair amount of time on Oahu each year. I love surfing, scuba diving, snorkeling and kayaking. So when Patagonia took on "Ocean's as Wilderness" as their latest environmental campaign, I was quite interested. I always look for the things that I can do to get involved in the causes that matter to me, and so here is one that I've been reading about recently.

------- Excerpt -------

The Magnuson-Stevens Fishery Conservation and Management Act (MSA) is the primary law governing management of our nation's ocean fisheries. Ocean fisheries have significant effects on ocean ecosystems and are integral to national and coastal economies. That's why these activities have to be carefully managed. In recent years, two national commissions have recommended strengthening the MSA. Instead, the U.S. House of Representatives is currently considering a bill that would dangerously weaken the conservation and management of our ocean fish.

Rather than building on the strengths of the current law, the proposed bill would weaken longstanding safeguards and increase serious environmental threats to ocean fish and marine ecosystems. The bill would also limit public involvement and access to information about the way the federal government manages ocean fish.

Congress needs to know that we care about the health of our oceans and want them to oppose efforts to rollback critical environmental protections.

------- Excerpt -------

Want to check it out or get more information? See http://www.democracyinaction.org.

Posted by mikedav ( Jun 22 2006, 02:51:09 PM PDT ) [Listen] Permalink