Today is the first full day of summer vacation in the Marsh household.  Each of the kids have a few wonderfully empty days before our summer schedule kicks in, with travel, visitors, summer camp, and some fun summer school programs.  Of course, for us fully-employed parents it just seems the work schedule hits full on during the summer.

With today’s economy though, full employment and security in your profession is increasingly rare.  We know many people impacted by the downturn, looking for new opportunities both within their current position, and in far too many cases whole new professions.

We at WSO2 feel fortunate to be weathering the downturn well – although there’s nothing “cheap” about the way our software performs, the Open Source label has attracted many new customers that are looking for lower cost options.

WSO2 also has a strong tradition of community service within Sri Lanka, from regular fundraising for local charity groups to responding to the Tsunami and other disasters around the world with an open source disaster management system still going strong today.  We wanted to help people caught in today’s global economic disaster in whatever small way we could.

Introducing WSO2’s SOA Summer School.

WSO2 has put together an eight-week series of free online SOA training events, to help enterprise architects and developers acquire or hone their skills and become more valuable to their employers or prospective employers.  The curriculum covers SOA architectural patterns, deployment patterns, security, governance, mashups, business process management, and much more.  Check out the whole schedule and register at the WSO2 training site.

And the best part, is that the whole program is FREE.  Our gift back to the global SOA community.  So far the response has been fantastic!

This sure makes me proud to work at WSO2.

Check out this little rough (and rather noisy) video I put together of a conversation from ZendCon 2008.  Shankar observes the trend towards tying PHP applications together using Web Services, something for which the WSO2 Web Services Framework for PHP is ideally suited.  And we just announced the 2.0 release!

Keith has created a nice REST demo to show how WSDL 2.0 can be used to describe a RESTful interaction, and posted the resulting mashup here.  This is in response to an old post he found from Stefan Tilkov.

One of the area Stefan explores is the difference between the conceptual models of "operations" versus "resources":

It seems to me that the right thing would be to get rid of the operations (or map them to the HTTP verbs, which is essentially the same thing as getting rid of them).

Keith indeed mapped each combination of "verb", "uri template" into a WSDL operation.  So what Stefan describes as "GET on /customer/{id} - get customer details" Keith maps to a "getCustomerDetails" operation which takes an "id" parameter.  I think this is a very reasonable mapping, and one that looks a lot like the "getCustomerDetails(id)" construct which is present in some form in every programming language.

I don’t call this "getting rid of the operations" either, if by that is meant writing a WSDL that has only four operations (GET, PUT, POST, DELETE). I would instead say that an operation encapsulates the combination of the http method, the http location uri pattern or template, and the input and output types into a construct that maps well to familiar programming constructs and provides a level of abstraction that can prove valuable (e.g. the uri location can change, security can be applied, even the transport protocols can change without perturbing the development experience).

Having a WSDL 2.0 description of the service in terms of operations also had the beneficial effect of documenting which combinations of verb/uri template are supported, with the effect of also documenting which combinations aren’t supported.  Stefan had to notate these as "unused" in his diagram, important because some of the combinations aren’t obvious (why can’t a customer be deleted?)

It still baffles me why there isn’t more demand for WSDL 2.0 and its REST description features.  Hopefully Keith’s post helps demonstrate the value of this technology.

Can’t help but repeat a few choice bits from a recent article Enterprise Mashups Part II: Why SOA Architects Should Care by Chris Warner and John Crupi.  Too bad I didn’t see this before the Enterprise Capabilities of the WSO2 Mashup Server 1.5 webinar I gave this morning - I could have cribbed a few bits of wisdom! Like these:

Mashups bring a “user” into the SOA mix. … By having the business build mashups upon the foundation of your service-oriented architecture, they essentially become SOA champions without knowing it.

This is a point we tried to hit strongly in the WSO2 Mashup Server, which can help bring individuals, teams, or enterprises together into a community around services, and strengthen the concept of a "user" and help build a diverse set of user experiences tied to services.  Until the SOA platform gets connected to the business users, the promises of SOA (business agility) won’t be fully realized.

In addition to SOA-friendly formats, such as RSS and Atom plus REST and SOAP, mashup creators can publish mashups to spreadsheets, as WSRP-compliant portlets, wiki- and blog-friendly widgets, or even into a mobile phone as a micro-application. Mashups can become the vehicle through which services become part of the everyday tools of the enterprise business user.

Which is why we’ve added on to the RSS, Atom, REST, and SOAP support in 1.0 the ability to interact with spreadsheets and databases (through Data Services), and are starting our foray into the world of portlets, widgets, and gadgets with support for Google gadgets.

Mashups can go well beyond leveraging an SOA by becoming part of that SOA, allowing developers to create customized “service skins” from core services. …

Because mashups can be exposed as REST-, WSDL- and JSON-based services, they look and feel like a real SOA-based service to developers who want to consume them. … The mashup, created by the developer, becomes the tailored service which is directly aligned with their particular need. Major enhancements to core services can be accommodated with a reformulated or updated mashup by the mashup creators themselves.

Yes, we’ve found our users (and ourselves) using the WSO2 Mashup Server for more than just combining services into a new one, but for rapid development of new services, or for customizing services to a particular scenario.  From the outside, these don’t just look like real services - they are real services - for example in the 1.5 release high levels of security can be applied to the services even though they are so easy to write.  A good example of a "skinned" service - the digit2image sample service that comes with the mashup server tailors a very general purpose and complicated service (Flickr) for a particular narrow purpose - to find a random image, with appropriate copyright, for a single numeric digit.  By providing a narrow API, this capability can be exposed more easily and efficiently (some caching is performed by the service to speed up returns).  And it allows innovation without touching the original Flickr service which we don’t have control over.  For instance, I could search beyond Flickr for appropriate images without breaking the service contract or rewriting the Flickr service.

Toward the end, the authors write:

At this point any SOA architect worth his WSDL should see that mashups can greatly enhance an SOA and don’t necessarily ignore or break the principles that made your SOA great. But governance, granularity and scope for mashups do require subtle tweaks and adjustments to your enterprise toolset.

Indeed, governance is important as your SOA grows and chaos theory has a chance to get a toehold.  The WSO2 Mashup Server is taking the first steps into governance by relying on the WSO2 Registry to store mashups in a versioned repository, manage ownership, users and roles, and facilitate communication and the building of trust in an Enterprise SOA community.  But we still have to to a better job of working with the Registry’s features for supporting multiple versions, product lifecycles, and dependency management.  For instance, while the Mashup Server stores all it’s mashups, comments, tags, ratings, etc. in the Registry, when you deploy a new mashup, it doesn’t automatically populate the registry with the WSDL.  We’re looking at much better integration with the Registry as a primary feature of our next Mashup Server release.

Kudos to the authors for clearly presenting not just the case for service mashups in an SOA architecture, but why any SOA architecture that doesn’t expand into the mashup space is missing out on huge opportunities.

Microsoft TechEd Online has posted a video taped in Orlando after our successful keynote appearance.  This video captures a panel discussion that I participated in - I’ll just quote the blurb:

This Panel discussion centers around the use of standards to facilitate interoperability between different technologies. The participants have all implemented their own version of a reference application and speak about any challenges they faced in implementing the application. The main discussion points of this Panel include: interoperability through SOAP; WS-* standards and how they facilitate interoperability; common problems with interoperability; identity and security in a distributed application; and future directions/remaining challenges in interoperability. With Raghu Thiagarajan, Gerald Beuchelt, Gregory Leake, Jonathan Marsh, and Chris Haddad.

Watch the video here, or go here, search for "Industry Interoperability" and choose your playback format.

Related news:  The video of our demo within the keynote has been extracted from the entire keynote and made available on youtube.  Here’s the link!

Yes, you heard right.  A few minutes ago in Orlando at TechEd IT 2008, Bob Muglia’s keynote included a demo of StockTrader 2.0, an SOA sample application consisting of a client application, a business process service layer, and an order processing service in order to place sample stock trades.  Gregory Leake of Microsoft showed the application, with each of the three components built in .NET 3.5, and then I came on stage, representing WSO2, and we swapped out the WPF smart client for a PHP application based on the WSO2 Web Services Framework for PHP.  Then we swapped out the back end order processing service for a Java version hosted in the WSO2 Web Services Application Server.  After each swap we placed a successful trade.

Watch the keynote here.

The demo featured the cross-platform interoperability between .NET, Java-based solutions, and unmanaged code solutions such as the PHP application.  The Web Services used were completely secured with message-level security (WS-Security), and everything of course worked quite seamlessly.

You can download the WSO2 StockTrader 2.0 application as well, including PHP versions of the business service and the order processing service.

The good news in putting this demo together is that the wire-level interop worked pretty spectacularly out-of-the-box, just as the demo promotes.  The actual interop between the three major development platforms in use today (CLR-based languages, JVM-based languages, and unmanaged code based at some level in C) is impressive, and while there is more work to do to complete and verify interop deeply across Security, Reliability, Transactions, and Policies, it really seems like the goal of making this stuff both universal and "just plumbing" is approaching pretty rapidly.

On another note - yesterday we were speculating backstage whether a keynote at a major Microsoft event had ever featured an Open Source partner on stage.  None of us could think of any off the top of our heads.  Can you?  Were we the first?

Update: 10PM.  Here’s the press release.  And a news article, with a nice (and accurate!) quote from me.

Paul Downey poses some interesting considerations for what a mashup consists of.  I think I’d list a pretty different set of criteria, but for now I’ll just start by comparing a mashup hosted by the WSO2 Mashup Server against his list to see how we stack up:

• Zero touch: +1.  Each mashup is accessible, documented, try-able, and so forth right out of the box.  The admin console makes them discoverable, and if you have a user account (email-validated guests are supported too) you can tag, rate, comment a mashup to build a community around them to make any touch beyond "zero" positive and reciprocal.
• Safe: +.5.  The Mashup Server supports and encourages safe interactions, but it does not prevent users from hanging themselves if they so choose.  That is, I can have an operation exposed through GET, explicitly marked as safe by the author even, that has seriously detrimental side effects.
• Cool URIs: +1.  Each mashup has neat URIs for the endpoints, for the metadata and tooling associated with it, for the admin capabilities associated with it, and even for accessing the operations over HTTP.
• Open data formats: +1.  We’re partial to XML and use Web Services under the hood, but also provide bridges to HTML, JSON, Feeds, etc.
• Eschew RIA: +1.  By default we don’t provide any rich interface.
• HTML form access: +1.  By default we do provide an HTML try-it form, and stubs to quickly build your own HTML pages.
• Accessible URIs: +1.  All endpoints are available through both http and https by default.  Mashups can be easily migrated outside local contexts so their visibility is greater.  E.g. mooshup.com.
• SOAP/WSDL: -1.  Everything we do has rich metadata and SOAP 1.1 and SOAP 1.2 bindings along with the REST/POX binding, and we also make it easy to consume web services in these formats.  However, you don’t have to know anything about these formats to write a successful mashup - they’re just valuable parts of the plumbing.  So maybe a -1 is too stingy.
• Authentication: +0.  We support username/password and Infocard to access the Mashup admin site, but there isn’t a drop-dead simple way to restrict access to the service based on these controls.  Not too hard to provision higher levels of security using WS-Security, but I’m not sure Paul would agree that’s sufficient.
• Scratch your itch: +1.  Subjective, but the whole product is designed to serve the needs of individual developers to hack up services as easy as they can hack up a simple web page.
• Fun: +2!!  As long as you’re willing to hack a bit of Javascript.

So I think the Mashup Server stacks up pretty well using Paul’s criteria, which I think can be summed up as "has a nice web interface" and "fun and easy".  But some of Paul’s criteria don’t fit with that summary and those are unsurprisingly the ones I take some issue with:

RIA: I don’t see any reason why a rich interface to a mashup is always bad.  Only when it locks up the data in a way that’s impractical to reuse.  In our model, we support the separation of content and presentation in order to lift the limits on the kinds of presentation environments the user prefers.  A single mashup can (and ideally should) support as many presentation media as are appropriate, including simple web pages, RIAs, feeds, notifications and messages, portlets, widgets, whatever.  If an RIA "scratches my itch" then what’s wrong with it?

For example, my iPod Touch comes with a YouTube app, which is an RIA for the YouTube site optimized to the screen limitations of the product.  I can also point Safari right at YouTube, but the optimized version actually is easier for simple access.  Is this bad?  It really depends on what the consumer wants.  I agree dead ending in an RIA may be inappropriate for some users of that service, but providing an RIA front end to a clean and well-documented interface that can be repurposed in other ways seems like a good user-centered feature that even Paul would support. I think he probably meant this item to mean "Does the site rely solely on so-called ‘rich user experience’ technologies in a way that precludes data from being accessed though a nice web interface?"

SOAP/WSDL: I understand why Paul would add this to the list.  Up until the Mashup Server Web Services were just too hard to consume to allow them to stand on a list with "scratch your itch" and "fun".  However I think we’ve turned the corner on that.  A Mashup Server author rarely has to even consider whether SOAP is involved in delivering a Web Service - we can take care of that for them.  Right now it’s simply an alternative to the REST interface.

As for WSDL, in the Mashup Server it strongly supports the other goals of zero touch, cool URIs, and open data formats.  I’m pretty tired of doing one-off hand coding to access REST sites or sucking up their hand-crafted and varying-quality stubs.  WSDL has a big role to play in simplifying these interactions for the developer, in a way that I think Paul would appreciate.  It’s a primary artifact in providing the "nice web interface" that we all agree is invaluable.

Anyway, thanks Paul for a provocative post!

This morning I had an interview with Kurt Mackie from Application Development Trends Magazine, and discussed the implications of the completion of WSDL 2.0. 

In retrospect I realized I’m used to long-winded deliberations from years in Working Groups, rather than sound bites that are easy for the press to grab on to.  I guess Kurt Mackie had the same impression, since he decided to transcribe large parts of our conversation ;-).  I’m not too disappointed with the result though.  Even managed to get in an unexpected plug for the WSO2 Mashup Server.  Take a look at the article and see if you agree…

While you’re holding your breath for the anticipated WSDL 2.0 Recommendation, check out Eran’s podcast on the WSO2 Oxygen Tank, talking about WSDL 2.0 and how it’s supported in the WSO2 Web Service Application Server.

I’ve been working on a WSDL 2.0 description of the Flickr API.  My first attempt is here. Follows are some thoughts on this process:

Why a WSDL?

There are two reasons motivating me to want a WSDL for Flickr.  First of all, the WSDL 2.0 WG needs to prove that the HTTP binding has utility in describing existing REST or POX services.  Flickr seemed like a good stress test.  Secondly, once I have a WSDL I can automatically generate stubs for dynamic languages (a part of the Web Services Mashup Server I’m working on).  That should (ideally) simplify the interactions with Flickr and I wanted to see how much progress could be made.

Google failed to uncover any Flickr WSDL (1.1), just a number of people bemoaning the lack of one.  So I had to set forth on my own.

Flickr SOAP and WSDL

A quick look at the Flickr SOAP interface (the one you’d expect to be reasonably describable by WSDL 1.1) shows that they use a wrapped technique that make it very difficult to write a clean XML Schema, and therefore WSDL, for the service.  Traditionally, each operation in a SOAP-based Web service (e.g. flickr.photos.search) accepts and returns blocks of XML, which is described by XML Schema.  Since XML Schema associates an element name with a single structure, different operations, at least those requiring different structure, choose different names for the XML payload.  Flickr however wraps the parameters which comprise each request in a single element:

<x:FlickrRequest xmlns:x="urn:flickr">
  <method>flickr.test.echo</method>
  <someparameter>value</someparameter>
</x:FlickrRequest>

Note that the name of the operation (flickr.test.echo) is buried inside the payload.  There is a co-constraint between the value of the <method> element and the other parameters in the body.  This co-constraint is not expressible in XML Schema, which associates the <x:FlickrRequest> element with a single structural type.  Responses are similarly wrapped in an <x:FlickrResponse> element.  Because each operation returns the same element, a straightforward WSDL can’t do much better than an xs:anyType when describing the messages.

Note that WSDL 1.1 had a hack that helped here - you could describe the type of the body, rather than pointing to an element declaration that represented it.  WSDL 2.0 removed this hack in the name of simplification - a good choice in general but Flickr really could use the hack.

Flickr SOAP and HTTP

The WSDL 2.0 HTTP Binding actually does a better job than the SOAP binding here.  Since the XML structure of the operation is mapped into parameters, a wrapper element declaration doesn’t appear on the wire, so one can make up a different element name (as I’ve done) for each operation.  The return types from the Flickr REST API are still a single type of element (even worse than the SOAP case since the same wrapper element appears around both successful responses and faults).  But formulating the request has the highest value-add from the stub-generation point of view.

Flickr Authentication

The Flickr authentication scheme seems likely to make the WSDL description less than useful.  Most of the operations (the "write" ones) require authentication, yet the mechanism for authentication and signing seems pretty unique to Flickr - and therefore is likely to interact badly with general-purpose tooling.  I’ll have to play with this more to see whether this will require so much hand-coding that having WSDL at all is irrelevant.

Random Thoughts

One thing that an official WSDL would force, is a little more rigor in versioning the Flickr API.  It appears from the mailing list that changes to the API happen occasionally, but I wasn’t able to find a clean identifier for the various versions of the API as it evolves.  Having metadata that could be associated with stable (dated) identifiers would help customers of the API have a consistent experience over time.

An interesting anomaly is that the SOAP API and the REST API really must be considered different APIs at this point from the WSDL perspective.  That is, the XML Payload you get back is different depending on whether you access it through the SOAP or REST API.  WSDL separates the payload structure from how the XML is transmitted on the wire, but would require some XML transformation capability in the bindings to expose a single abstract set of messages through alternate transports (like SOAP vs. raw HTTP).  That means, if you change the way you get the payload delivered to you, you also have to change the way you access the contents of the payload - a Flickr poorly separates these concerns IMO (predicated on the definition of "payload" being the child of the <soap:Body> or the HTTP envelope).

Also I need to think a little more on whether Flickr’s design is optimal as a REST API and just hard to describe within the constraints of WSDL and XML Schema, or whether it’s generally suboptimal and that’s what is making it hard to describe.  Right now it seems neutral to me - the API would be just as easy to use if it were designed in a little more WSDL-friendly way but I can’t yet see compelling rationale for changing it other than to make it more WSDL-friendly.

Anyway, please send me any feedback you have on the WSDL.

Good to see the father of RelaxNG taking another look at schema languages in the context of data binding.  Some interesting propositions!  Subscribe.

(Still throwing off random sparks ignited at the W3C Enterprise Workshop.)

Technology, like religion, eventually begins to accrete dogma.  In the case of the Web there seems to be a growing trend of thinking that if something has proven to be "good", alternatives to that thing must be alternatives to "good", and we all know the only alternative to "good" is "bad," right?  If Mohammed is the true prophet, Jesus can’t be.  If REST is good, WS-* can’t be.

A case in point:  The fact that a URI can be communicated in plain text and thus in a wide variety of contexts is viewed as a great strength of the web.  The fact that one can write a URI in an email message, in a print publication, or even on the side of a bus is often touted as a virtue of URI identifiers.  The ability to write a URI on the side of a bus is undoubtedly good.  An identifier that can’t easily be transcribed onto a rolling billboard thus must be bad, right?  Paul’s hilarious graphic of an EPR on the side of a bus is an example, with the implicit message that because URIs are good, EPRs must be bad.

Although Paul was partly making a different point, taking this incipient dogma too seriously is misguided.  Very few of the URLs pointing to interesting resources on the web are actually simple enough to write on the side of the bus and survive human transcription.  Paul unfairly compares an EPR of horrible complexity to a simple URL.  Only a small percentage of the URLs in use today are simple enough to be placed on that bus with a reasonable chance of success.  And even the simple ones rely on years of forced adaptation to make such finger- and tongue-twisters as "haytch-tee-tee-pee-colon-whack-whack" even nominally acceptable.  Just because human transcription is good for some identifiers, should one conclude that it must be a quality desirable for all identifiers?  Are long and complicated URIs "bad"?  I argue that they simply aren’t appropriate for use in the context of human transcription.  EPRs are specifically designed for use in the context of Web services - i.e. machine-to-machine communication on the web.  I seriously doubt that machines are going to be reading sides of busses.  And if they do, verbosity is still unlikely to be one of the primary problems.  The goodness of a URI on the side of a bus doesn’t imply the overall badness of EPRs.

In the context of machine-to-machine communication, often more structure is better.  A structured identifier can indicate the split between metadata and data.  It can have definite rules about where the identifier starts and ends - wouldn’t it be nice if plain-text email readers could detect the start and end of multi-line URLs?  It can have a uniform syntax for describing the "parts" of the identifier - URIs embed a pretty complicated microsyntax.  It can have simpler, more uniform rules for encoding special characters.  It can put the information necessary to access a particular resource within the identifier instead of hiding it in cookies and session state as is common in HTTP resources.  I’m not claiming that EPRs are all good, just pointing out that within a given context perhaps they aren’t all bad.

Another example of a bit of good advice turned into dogma and used to bludgeon the innocent was evident in Nick Gall’s W3C Enterprise Workshop paper claiming:

Nowhere in the vast multitude of WS-* specifications or the articles or papers describing them is there any imperative or even any emphasis that a Web Service should return an XML document that is populated references to other Web resources, ie URIs.  But it is a fundamental principle of the Web that good Web resources don’t "dead end" the Web; instead, they return representations filled with URIs that link to other Web resources.

First of all, I’m wary of even dignifying this so-called "principle" with that label.  For human interaction, for searching and cataloging based on simulating human navigation patterns, pages full of links are good.  Especially when the content of that page isn’t terribly useful it’s nice to be able to click virtually at random and escape into the soothing world of advertising pitches.  But for a particular user, the majority of links in a page never get used.  What is a machine going to do with a bunch of random links?  In machine-to-machine communication, links are undoubtedly going to be much fewer in quantity, but much higher in quality.  And if the service is doing something useful on behalf of a user that doesn’t require the transmission of lots of links, is that therefore a bad service?  A service should return precisely the number of links necessary for it to do useful work.  No more, and no less.

The danger of dogma is that it takes something that is right and useful in context, and applies it to contexts where it often is neither right, nor useful.  Apply Cold War politics to the so-called War on Terror and you get Iraq.  Apply Jesus’ celibacy to much less spiritual theocrats and you get sex abuse.  Apply something like the carefully constrained Web Architecture out of context and the consequences aren’t nearly so disastrous - but you will look kind of silly.  Best to keep it to a minimum.  Ideally, no larger than will fit comfortably on the side of a bus.

The WSO2 Oxygen Tank, hosting our open-source code, documentation, articles, mail forums, and so forth, also now hosts a series of podcasts, now including one by me.  I spoke with Hasmin Abdulcader about the W3C Workshop on Web of Services for Enterprise Computing, reiterating some of the points in my previous blog post.

Also check out Jon Udell speaking with Steve Vinosky prior to the workshop - that’s much more insightful about the REST versus WS-* debate about which I don’t have a whole lot new to say at this point.

Photocredit - me trying to give the mic away at the Workshop by Paul Downey.

At long last, the tiny but valuable WS-MTOM Policy assertion spec has been acknowledged as a W3C Submission.  90% of the spec is boilerplate, so rather than wade through that, here’s a summary:

The spec defines the following element as a WS-Policy assertion:

<OptimizedMimeSerialization xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization"/>

When this policy assertion is used, all messages to and from a Web Service MUST be MTOM encoded; thus they will all have the application/xop+xml mime type.  The assertion can be used on, and thus applies uniformly to, a wsdl:binding or wsdl:port.  Although the spec doesn’t mention WSDL 2.0, there is an obvious implication that it will work just fine on a wsdl2:binding, or a wsdl2:endpoint.  That’s the spec in a nutshell.

This spec is bare-bones and thus avoids a number of nasty issues.  A few things the spec doesn’t define:

• It does not constrain which parts of a message, if any, should or must be optimized.  Most messages sent and received from an endpoint will have the application/xop+xml mime type even though they only have a single message part (and thus no optimization).
• It does not provide for operation-level granularity of describing MTOM encoding.  That is, all operations in the interface have to be optimized, or not.
• It does not provide for message-level granularity of describing MTOM encoding.  That is, you should not expect to be able to send XOP and get back plain old SOAP, or vice versa.
• wsp:Optional="true" is allowed on the assertion, so that you can still interoperate with the service without MTOM engaged.  However, this doesn’t mean you can mix and match MTOM and plain old SOAP at will.  Specifically, if you send a regular SOAP message to such an endpoint, it can infer that you have chosen the policy alternative that doesn’t include MTOM engagement, and so you won’t get an optimized message in response.  I have a feeling wsp:Optional will be an interop problem in practice, and don’t expect Microsoft to be emitting it in their WSDLs.

P.S. you might chuckle to note me as the editor - 3 months after leaving Microsoft.  And it was on my project list for, maybe, a year?  So you can see I wasn’t the only bottleneck ;-).

Yes, that’s where I’m landing.  I’ve known and admired Sanjiva since early in the XSL Working Group, and his year-old startup WSO2 is sure to be a rewarding place to work.  WSO2 is developing products around the Axis2 open-source Web Service Stack, and while Axis2 itself is open source, WSO2 plans to provide support and service to corporations making Axis2 a critical part of their infrastructure.  It’s a model that has worked well for MySQL and Red Hat.

My title is Director of Architecture, Mashup Technologies, and I’ll be working on ways to make the consumption of Web Services as trivial as possible, and the deployment of Web Services just as simple.  This is a perfect overlap for me - I’ve been working on Web Services, especially the Enterprise-level, back-office, strongly-typed variety for a long time, but my background and affinities are with the script-friendly, quick-and-easy, dynamically-typed web hackers.  If I’m successful, Web Services will become a more important part of the grass-roots Web toolbox.

Working at WSO2 will in some ways be completely different than working at Microsoft:

• Open Source Software versus Commercial Software (I know commercial isn’t quite right, as there is commerce in Open Source, but calling it Closed Source or Proprietary Software has a negative connotation that I don’t think is justified.  Neither model is inherently bad, they are just different.  In any case I’m looking forward to understanding the Open Source business and development models better.)
• Diplomacy versus Design (While I’ll continue to work on standards, the majority of my time will be devoted to designing new ways to make Web Services accessible to the grass-roots of Web developers.)
• Unstructured versus Bureaucratic (An organization the size of Microsoft requires a level of rigor, process, fixed roles, and yes even bureaucracy that I won’t miss all that much.  You can often get more done faster flying by the seat of your pants.  And you can have more fun doing it.)
• Time zones (I’ll continue to work at home in Auburn, but I’ll no longer be in the same time zone as the main office.  In fact, I’ll be 11 1/2 hours off.  That’s the only part of the new job that scares me!)

And in other ways it’ll be just the same:

• Web Services (I’ll be building on my recent experience rather than taking up something completely new like lion taming.)
• WS Description Working Group (I’ll continue to co-chair the WG, and in fact hope to be even more involved in proving implementation experience to move the specs out of Candidate Recommendation stage.)
• International travel (While I hope to reduce my travel somewhat, I still look forward to meeting my colleagues in exotic locations.  Now Sri Lanka will be on my repeat destination list!)

I’m very excited about this move, and it feels like it’s happening at just the right time for me.  Well, a few weeks later than I’d hoped, but now at last I’ve cleared the road and am ready to hit the gas.  Starting on Monday when I leave for the Apache conference in Austin.  If you’re in the area, let’s do tea!