October 27, 2004

OOPSLA 2004

My blog is experiencing some difficulties since my hosting provider seems to have misplaced my MySQL database (hmm). This probably won't show in the RSS feed. Anyway, here's Greg Peres & I at OOPSLA 2004.

Posted by stu at 01:05 PM | Comments (0)

October 04, 2004

interop vs. portability

A couple entries from Tim Ewald and Michi Henning.

This old discussion between Don Box and Michi from 1999 is particularly telling, as well. In hindsight, I think they were both right. Protocol-oriented interoperability is the right way to go, but code portability is nice, as the success of J2EE has shown. But in a market-based software development world you really can only focus on interoperability or portability -- not both, or else you'll get the two confused. Plus, QoS & productivity is all that vendors have to compete on! One could forsee an open source solution that gets both right, perhaps...

My experience in complex environment has made me realize the ineffectiveness of portability in many circumstances. For exampe, JDBC, ODBC, etc. all claim "database SQL portability", but in practise the differences between concurrency models, performance, and features between DBMS vendors is so large that "SQL portability" is quite useless for most interesting applications. Packaged software applications like SAP or Siebel are crappy database users for this reason -- they wrote generic SQL instead of tuned, specific SQL.

Secondly, I would say the whole reason Microsoft has jumped behind XML is that they've bit the interop bug -- they'll be a good citizen of IT from now on, but they'll be damned if they'll reduce your switching costs -- once you go .NET, you're stuck with .NET.

Thirdly: J2EE seems to have hit an interesting sweet-spot here. It's almost like it's gone down the path of SQL. You get decent (not perfect) portability, proprietary features are reasonably isolatable, and it richly supports the interoperability of XML. Now of course, vendors are adding features to the software stack that are non-standard, such as BPM, Portals, etc. But even there are JSRs awaiting these features, promising code-portability.

So for those people that care primarily about portability (BTW -- Do such people really exist? Can people really claim they care more about switching costs than functionality and productivity?), 90% vanilla J2EE will have to suffice. For those that care primarily about productivity, either LAMP, modern Java frameworks (i.e. BEA Workshop, Struts, JSF, PicoContainer, AspectJ, etc.) or .NET will suffice.

Posted by stu at 01:12 PM | Comments (0)

on WS-* standards proliferation

About a week or two ago, a blog wave was started regarding the increasing difficulty of keeping up with the web services standards process. Most blogphiles have probably read all this stuff, but since I don't post all that often, I'll make note of the highlights here: The release of WS-Transfer and WS-Enumeration, the initial salvos: Tim Bray #1, Mike Gunderloy, Simon St. Laurent, the rebuttals: Sean McGrath, Phil Wainwright, and Tim Bray #2.

Oh, and if you want to understand how all the WS-* specs fit together, Cabrera, Kurt, and Box have put together a whitepaper on it (very useful).

I'm still letting this digest. I've been pretty happy with the WS-* process -- some of these specs solve real problems, while some of them replicate solutions that already exist but in a transport-independent manner.

I'm struck by three observations, and opinions:

1. The dissenters mainly think that XML+HTTP (aka. REST) is enough. Let's be fair: add SSL to that for encryption / signature. And we don't have really interoperable authorization, just HTTP authentication here. Nor do we have any messaging semantics other than synchronous request/response. Granted, a lot can be done with this, but does this really make for good interop when we get into tougher situations? Let a thousand XSLT pages bloom to translate between different security, message correlation, and other plumbing issues?

2. Related to the above is that these specs haven't been fully baked -- some get deprecated before implemented, and we're not likely to see widespread (aka. Microsoft + 2 other vendors) support for these specs for months. It's dangerous to add complexity en masse, piecemeal is better.

I agree in general with this statement, but I'm not sure we're in a dangerous situation yet. I actually see the WS space undergoing piecemeal growth. We have the SOAP/WSDL/HTTP/SSL/XSD kernel today. Some use Relax-NG instead of XSD. That's pretty doable. Now, we're starting to seriously add WS-Security. Tomorrow, WS-ReliableMessaging will come. And then the others. I'm not sure how this isn't piecemeal. Perhaps because the specs are so widely viewable that it's confusing people. I always thought the specs were for specific audiences: leading-edge implementors and vendors -- not mainstream developers. If you're developing with XML+HTTP or SOAP today, and you're happy, what's the fuss? If you're not happy... well, is it a tool or protocol problem?

3. When I look at the specification page count that Tim and others put together, I'm struck by how FEW pages there are. At first glance 569 pages for XML, XSD, and base security specs seems a lot -- though out of this 409 pages are XSD, so perhaps the problem continues to be XSD vs. RNG & other simpler contract definition languages. Then there's 230 pages for the WS-Security family, which doesn't strike me as overly large considering how wide ranging the specs are.

Now then:
Only 21 pages for Reliable Messaging! 39 pages for transactions! This seems rather consise. For core plumbing, there's 111 pages for SOAP messaging from the W3C (which includes the primer and adjuncts, some of which cover miscellaneous / legacy techniques), and another 100 pages for things like events, REST-like transfer verbs, addressing, binary support, and UDP support. Again, not too bad.

I don't know what the fuss is. How big are these vs. the CORBA specs? How hard was this to understand in DCOM? How about any EAI vendor's reference manuals?

Once again, there are different audiences here. Most dissenters have probably never touched CORBA or EAI (though certainly some have and have lost hair from the experience :) and suggest no one should have to ever do that -- the internet proved everything can be done with HTTP! They may have a point, though I haven't been convinced it's applicable to ALL scenarios. The other audience wants web services as a better (more traceable, debuggable, maintainable) enterprise distributed system standard. To these people, there ARE legitimate reasons for these specifcations: some applications really do need standard eventing, some really do need asynchronous support (and hence addressing), reliablity, and a more sophisticated form of transactions than 1-phase "yay or nay". In my experience, anyway.

Perhaps these specs aren't actually going to solve these problems, and we should implement a widely adopted ad-hoc solution first before we trumpet out the spec. This is a good point and a reason why WS-* should be adopted with caution. But -- what else can one do? Use the older frameworks and have HTTP+XML or SOAP gateways for client-based interop. Server-to-server orchestration needs a one-vendor solution, whether Biztalk, WLI, or MQ Workflow. This seems to be the answer, for now.

Posted by stu at 06:55 AM | Comments (0)

October 02, 2004

Microsoft, services, and patents

Microsoft is amassing a patent portfolio, and while they haven't used it yet, they most definitely will at some point.

I've seen concern in two areas here:

a) they will trounce on web services competitors
b) they will trounce on Linux

While it's certainly possible, I think are a lot of problems with these scenarios. This entry was adapted from a Slashdot post ... read on for more...

Firstly, we have Indigo - the next generation distributed computing platform from Microsoft. According to the blogs and what I saw at the PDC, it will be one of the richest and most thought-through approaches to distributed computing by a mainstream vendor, ever. But please note I said "distributed computing". Contrary to the hype, services orientation is not the new programming paradigm, and it is not a sucessor to OO. It certainly is the disruptive successor to OO-like distributed computing technologies such as CORBA, RMI, EJB, etc. And there is a chance that the paradigm shift will occur where everything will be distributed and nothing will be local. But distributed computing is hard, and I don't know if Indigo will truly crack that nut. In any case, it doesn't kill OO "inside" the services (F# notwithstanding).

There are two schools of thought here:
a) Microsoft wants big in the enterprise. They finally understand they need to interoperate and play well with others to do so. So they've embraced SOA , XML, etc. They will compete on being the bringing tools, performance, productivity, etc. to developers and businesses.

b) Microsoft's conducting a massive ruse and will crush BEA and IBM with patents -- especially if strategy (a) doesn't work.

We know from the Wall Street Journal article this summer that Microsoft is quietly starting to go after its own customers in dissuading them to use Linux because of their finger on the patent-trigger.

If Microsoft does start to use its patents to threaten both clients and other web services vendors, we're going to be in a very interesting time. Microsoft will have to pull off one of the biggest PR coups of all time in order to not ACCELERATE adoption of Linux and other non-Microsoft technologies. Given their recent PR debacles and marketing failures (the .NET brand-name-every-single-fucking-product-in-existence being one failure, being slow to truly react to security problems the other), I'm not confident they can pull this off.

IT departments like Microsoft because they brought costs down in the past and standardized skills. Today, they're becoming more of a liability -- they cost more, they're arrogant, and there are other standardized skills out there, like Linux. And remember -- most IT departments aren't ballsy enough to run their mission critical databases and applications on Windows. z/OS, UNIX and Linux are still key here, and I don't forsee a mass adoption of Mono over J2EE or proprietary suites in those areas.

Secondly, IBM will not take this lying down. If Microsoft has a big patent portfolio, the USPTO probably have entire warehouses dedicated to IBM patents. IBM can bring 10 lawsuits against any 1 Microsoft lawsuit. So anything MS does will have to be in line with IBM.

So the only realistic scenario I could see happening is that they outsell and outmarket BEA and IBM, or at least BEA. IBM's already doing a good job at PR-slamming BEA. BEA is the marketshare leader on UNIX and Windows, but IBM's combination of sales, createive branding tactics ("everything is WebSphere!") and mainframe share have made it seem to many that they're clobbering BEA in revenue and wins, when they're reallly not.

Since BEA is the upstart here, it's quite possible we'll wind up with two major SOA stacks -- .NET and IBM J2EE -- though BEA would probably just be acquired if it starts to falter. Sun isn't out of the game yet either, but they're certainly sidelined. Oracle still has a loyal following, and are doing really cool things with XML & the database. And how HP rises to this arena is anybody's guess. BEA has the ability to win big here, but they don't seem to have the marketing will to become as household a name as Oracle. They need new senior leadership.

But let's also recognize that technical merit doesn't win market battles. Even if Indigo is the all singing, all dancing thing that Microsoft hopes it will be, it doesn't mean people will adopt it en masse and quickly. Firstly, it's a Windows-only technology. That's a big limit to start with. Second, it's very new and rich. There's a learning curve. Third, other vendors are not sitting still. They can and will compete.

Posted by stu at 12:52 PM | Comments (0)