Microsoft has nibbled around the edges of true enterprise middleware for quite some time. Remember that stretch of years, not so long ago, when we were all about standardizing? Getting the company onto a single platform and developing continuity among our applications was top priority.
Standardization may still be desirable, but in the business world today, it simply is no longer possible. Our technological picture of commerce is no longer about what goes on within our company’s walls, it’s more about how easily we can interact with all the technology beyond them.
It’s about keeping information consistent throughout inter-organizational processes; it’s about sending documents to partner companies across the internet, from one format to another; it’s about utilizing Web services that may not be consistently available without compromising the processes that use them.
Then along comes Microsoft with an answer, and it is time to give that answer some serious consideration. Microsoft’s Enterprise Services purports to address our interoperability worries with a transaction management suite that is long on promise if short on pedigree.
Sparing you the nuts and bolts, Enterprise Services enables continuity across distributed transactions, coordinating application-level activity across multiple databases and even multiple servers. Services working across diverse terrains can be managed to enable bullet-proof business processes that won’t get out of sync, bottleneck into unavailability, or — worst of all — lose data.
In the midst of these promises, Enterprise Services has buried a few gems: more transaction processing automation tools and built-in “distributed” security features. But one of the most interesting is the bring-your-own-transaction feature, which allows business process components a kind of “inheritance” of transaction properties.
Enterprise Services’ greatest strength is also its greatest weakness: it leverages its predecessor Microsoft technologies. Built on the .NET framework and bristling with COM+ service features, it suffers from the same phage that has stricken BizTalk and other brilliant MS innovations: a design philosophy that is fundamentally incompatible with its creator’s product philosophy.
The .NET framework delivers most of what we need in a heterogeneous, asynchronous world but requires the most devastatingly homogeneous of platforms. Still, any suite that promises to update an Oracle database and a SQL Server database as a transparent single transaction is going to turn heads, even as we sigh over the cost of the golden handcuffs.
The folks in Redmond still don’t get what the folks at Sun Microsystems figured out long ago: we need less dependency on proprietary protocols, not more, to really move the world forward.
Dishing out delectable interoperability products as you demand greater allegiance to the Windows platform doesn’t exactly engender much of our trust. Still, don’t we concede that it’s the same with SAP and the other enterprise giants?
Enterprise Services may not yet be all that it’s meant to be — the next release will address slowness in XML serialization and should include improvement in dataset streaming, for example — but it’s the right idea, in buckets.
The word on the street is that it requires lots of TLC, and you’d better count the cost. But we’ve wondered for years if Microsoft could ever get into the enterprise game for real. Can Enterprise Services move them in the right direction?
Scott Robinson is an enterprise systems consultant with Quantumetrics, Inc., a consultant’s collaborative. Robinson is presently working in distributed healthcare information systems with HCHB/Allegro IT, and has worked with such well known organizations as the Dept. of Defense (DOD), Dept. of Energy (DOE), Wal-Mart, and Roche Pharmaceuticals. He is also a regular contributor to TechRepublic and can be reached at (812) 989-8173, or by email at [email protected].