More and more large companies are making big bets on Web Services. To read the Gartners, Forresters, Metas, and even Zaps – the contest is between the two rival Web Service architecturing frameworks and toolkits: Java J2EE and Microsofts .NET Framework. InfoWorld has a special report (June 28, 2004 – page 34) on how SAP is betting the business on its new Net Weaver web service component engine. There are two excellent books, David Chappell ESB-Enterprise Service Bus and Thomas Erls SOA-Service Oriented Architectures, which describe the latest thinking on how Web Services should evolve and be delivered. According to Hoyle, Gartner, Meta, and Erl – Web Services is the name of the game in n-tier distributed architectures.
We are not so sanguine.
Here is our top 10 reasons we think that calling a bet on Web Services “a sure thing” is calling it way too soon:
1)The sales & analysts hype machines are in full gear. You know, the expert houses selling their services as knowing “what the next great thing is” which they are on top of and you need to buy from them. Lets face it as the PC desktop and LAN and large portions of enterprise processing become settled and less of frontiers (the action is in embedded and realtime devices and systems), the tendency and need to sell the Next Great Thing becomes almost irrepressible. And Web Services were and are still being oversold. Example, when the GAO gets it right a year and a half ago advising goverment agencies to go slow with Web Service implementations because of security and reliability concerns – smack in the face of Web Services Gung Ho – one knows the massiveness of the Web Services hurricane of hype.
2)Security still remains as the number one concern. Jon Udell and Ephraim Schwartz at InfoWorld have raised questions about the trade-offs between one-stop convenience versus more comprehensive security checks and procedures versus the mixed bag curently available for Web Services. For example, ACL-Access Control Lists have convenience- manageability-security effectiveness trade-offs. And the XACL standard is not completely baked, tested, amended and re-ratified. Ditto for SAML-Security Assertion Markup Language, WS-Security, XML Encryption, XKMS- XML Key Management Specification, and other Web Service standards that simply have not been either approved or stressed tested in widespread major systems. If in the face of the great Spam and Spyware onslaughts, the IT community has not been able to implement PKI and other messaging/info exchange standards to curb and control these plagues, what does this say about the same communitys ability to implement the very complex, long-duration and/or transactional Web Services safely ?
3)Reliability is also a concern. WS-ReliableMessaging, HTTP-R , WS-Eventing, WS-AtomicTransaction plus other reliability and performance instruments for Web Services are even less baked than many Web Services security standards. When encountering long duration transactions, huge variances in demand putting sudden stresses on scalability, and many black boxes of Web Service performers with different hardware, software and operational preparedness – these pose serious questions about an overall distributed systems reliability. Its no longer a case of one cluster of your own servers whose availability/performance you can guarantee that determines overall Web Service reliability and performance.
4)XML, the backbone of SOAP/WSDL and Web Services can be performance challenged. The whole trade-off of Web services is to take simplicity-of-development, readability, and verbose size of XML-based Web services and sacrifice the binary efficiency, trimness, and runtime pep of CORBA, EDI, DCOM, and other RPC mechanisms. Its still too early to say when and where those trade-offs exact too great a price in the case of Web Services. But there are certainly performance trade-offs to take into account. And given the relative infancy of long duration Web Service based transaction processing, performance tuning is obviously yet to be done.
5)Web Services and XML still lacks a full, cross platform scripting language.This is a serious drawback. BPEL, XPath and XSLT are simply not close to being the real deal. Neither are Java nor C#,Xen/JScript or any of the dynamically compiled languages. There is a clear need for an XML, SQL, SOAP/WSDL savvy interpreted scripting language. A macro as well as glue language that can serve not only temporarily in the pinch but for long durations as well. There are many pretenders- JavaScript, Ruby, PHP, NetRexx, Groovy, etc, etc – but no universally embraced Web Services savvy scripting language.
6)Orchestration like performance tuning is just emerging. Orchestration is about asynchronous tasks that wait in queues for processing while systems continue to work on. The processing operations are more efficient and cost effective but the co-operative queues raise serious synchronization and integrity (commit versus rollback to where?) issues. This is one of the redder bleeding edges of Web Services.
7)Alternatives have been sold short. Just as the rush to full bitmap GUI left character mode displays in the lurch – yet they still persist with a rather large niche; likewise CORBA, EDI, DCOM, and other RPC and distributed processing approaches have been subject to a rip and replace mentality. Yet these technologies offer sound solutions to some of the above problems .
8)Dirty tricks have barely been discussed. Opportunities for nearly undetectable spying, cheating, and sabotage are inherent in distributed Web Services- especially across organizational boundaries as envisioned in SOA and ESB architectures. Peter Coffee at eWeek has raised this issue a number of times where, for instance, a 3rd party transporter keeps tabs on all transactions and occasionally sells that info very discreetly to the highest bidder. Or unknowingly a 3rd party in a Web Service chain becomes infected and then delivers damaged information goods – whose responsible if you cant pin the blame in a complex messaging chain ?
9)Manageability and contractual finepoints are issues. This is not just about long duration and mostly-automated transactions but also those same transactions almost infinite variations. First managing a network of Web Servers with varying demands is just being tackled. Administering the whole of Web Services and then its widely varying commit and rollback infrastructure will go well beyond current administrative software capabilities.
10)The major software firm, Microsoft, is as much a part of the problem as it is a supplier of Web Services solutions. This might seem to be a contradiction since Microsoft has committed itself to Web Services, has relied upon them as the bulwark of many of their development tools (but this is also out necessity as Redmond has rejected all other open distributed standards such as DME, DCE, CORBA, OpenDOC, Java, J2EE, XML-RPC, etc) and is a member and contributor to many of the Web Services committees and standards. But the harsh reality is that Microsoft is at best ambiguous and too often duplicitous player when it comes to standards, integration and interoperability. Unfortunately, these issues are at the heart of Web Services and their successful adoption.
In Philosophy, Everythings Must Run Best in Windows
Over the years Microsoft product managers and designers have made no bones about their Windows only applications. Redmond sees it as a competitive advantage – they only have to develop for one platform, Windows unlike Adobe, IBM, Oracle, Macromedia, and others which support multi-platform. They support a monoculture And despite that advantage they have delivered a decidely shaky “everything runs best in Windows”. Witness the continuing waves of reliability, availability, scalability, security problems of theWindows-One Best-Way. IT shops are going on a dozen years of “adolescent maturing pains” from blue screens of death through the constant Windows NT reboots to the onslaught of Windows-fostered virus , denial of service, spyware and other security breeches.
So in the process , on the Server side at least, Unix and now Linux plus Java have prevailed. More than 2/3rds of Web servers are Linux Apache. The Web API and browser connection continues to prosper with DHTML including JavaScript estimated by ECMA to be used in 70% of Web pages worldwide. Oracle, DB2, Sybase, MySQL and others have 70%++ database market share.
Even if you are a totally Microsoft desktop and server shop – you must directly interconnect with SCM, EDI, CRM, government reporting and countless other systems with shops which, 2 times out of 3, are going to be running non-Microsoft software. Yet in this heterogeneous and iinterconnected world, Microsoft is still selling application and server software that works best only with the latest Windows 2003 server and its associated Windows Server software add ons. So here is the kicker – in order to get the best out of your “open” Web Service connections to Windows desktops and servers you will need to run an ever widening array of Microsoft Server and Microsoft desktop applications. Sure users can use other databases, content management systems, application servers, messaging middleware and other applications on Windows – but … But be sure to make sure that the vendor provide adequate interconnections to Microsoft software applications and servers because increasingly Redmond will not provide such integrating features. In sum, Microsoft is decidely ambivalent about the IT industrys current drive to integration and interoperability.
Redmonds Wreckord on Interoperability
Consider the fact that Web Services are about open standards, partnerships, sharing components and code services, and trust that all players will be treated fairly and equitably as well as technically efficiently and effectively. Suspend for the moment any judgements about the technical efficiency and effectiveness of Microsoft enterprise code. Rather consider Redmonds record on adopting, supporting and upholding open standards and interoperability. It is decidely mixed:
i)Microsoft has taken a raincheck on quite a number of major defacto and de jure industry standards – you have seen the list: CORBA, JVM, J2EE, OpenGL, SWF, PDF, XML-RPC are just a smattering of Redmond jilted standards;
ii)On the standards it does support, Microsoft does “the proprietary runahead”. It runs way ahead of most other vendors in developing the technology and basis for a standard. Its $2B++ research budget allows it to do so. And nothing wrong here. But those runaheads that are rejected as standards Redmond retains often as proprietary extensions to the adopted standards. Just take a look at JScript, DOM, HTML, and what it attempted to do with Java for examples. Again, nothing untoward here as long as the proprietary extensions do not substantially duplicate and therefore displace the new and/or soon to be emerging standards (where “soon” means well less than a year). Microsoft could seal the deal by deprecating and retiring duplicate functionality code when the standards emerge – they do not do so. Even better Redmond could become a leader iin standards support by including a toggle or software switch in all its development and code generation tools that can be easily turned off and on by developers and end users. With the toggle on, developers would be guaranteed that Microsoft tools and code generators would only emit standards compliant programs and components. Turn the switch off and any proprietary extensions are allowed. Redmond does not do so despite Microsofts competitors like Adobe, Macromedia, and Sybase providing just such switches , primarily in their development tools.
iii)Microsoft from time to time suffers what might be charitably called “selective attention deficit disorder in standard technologies”. basically Redmond reserves the right to change their minds about standards and at anytime. For example, having pledged to adopt HTML, DOM, JavaScript/ECMAScript standards – Microsoft just stopped cold in its tracks in its IE Browser, Front Page developer, Visual Studio and other web development and delivery tools. Right now the IE Browser is the one farthest off standards and Microsoft has said no updates will occur to the IE browser until the new Longhorn comes out. Worse despite supplying copious materials about Avalon, Indigo, and just about anything Longhorn – Microsoft is completely mum about what the new browser will do and how standards compliant it will be. Not too good news for an IT World heavily committed to the Web API.
But DHTML is not the only standards revionism from Redmond. At the PDC rollout of the .NET Framework, Microsofties bragged about how they were sticking to XML and XML-based Web Services standards. But now Redmond is having second thoughts. Currently Microsoft is saying they will not adopt XPath 2 , XSLT 2 while completely bypassing SVG, XForms, SMIL and other XML standards. In addition, contrary to W3C plea for keeping XML patent free, they are taking out patents on XML technology.
iv)Microsoft as monopolist on the desktop expects special consideration for its standard proposals – or else risk suffering a “proprietary runahead” or “attention deficit disorder” attack as a consequence. Microsoft has said as much about XAML, its runalong technology. XAML is certainly not runahead as Mozillas XUL, Laszlos LZX and Macromedias MXML technologies for XML definition of GUI resources are prior or simultaneous with XAML. Yet despite not being a clear leader, Redmond has said that it will accept nothing less than XAML as the XML GUI Resource definition standard that it uses for Avalon and Longhorn.
In sum, Microsoft has a decidely poor record on standards support and interoperability. Ask any Windows ISV who wants to establish interoperaility with Windows appliactions or servers – the barriers and demands from Redmond are like the rule for the declension of German nouns: sometimes, always, never, never. But even more serious in the Web Services world of partnerships and co-operation is the simple question of trusting Microsoft.
In Microsoft We Trust ???
More serious is the problem of Microsoft and partnerships and fairness and trust. The whole world of Web Services is built upon trust and fair partners. CEO Steve Ballmer has proclaimed that Microsoft is more cognizant of its leadership role in the software industry and its need to be more circumspect and respectful of other players. Ballmer is famous for proclaiming Microsofts dedication to the welfare of its developers, developers, developers, developers. But Ballmer has just unleashed a BI Blitzkrieg that attacks Microsoft-primarly BI developers such as Actuate, Cognos, Hyperion, ProClarity, SAS and the whole BI marketplace. Microsoft now gives away free with SQL Server, Office 2003 and/or Visual Studio an OLAP engine and designer, a Data Mining engine and designer, a Reportwriting engine and developer add on, an expanded DTS-Data transfer Service, a broad set of templates for Financial Scoreboards and Portal creator code plus a host of other BI freebies. Microsoft knows that Cognos, ProClarity and most other BI players cannot respond to this freebie giveway because the BI players dont have a Windows Server 2003, SQL Server 2000, Office 2003 complimentary or tie-in sale. This is a replay of “cutting off the oxygen to Netscape” but in the BI field. And its being done in the name of protecting SQL Server and Office 2003 market shares and stimulating conversion to Windows 2003 and other Microsoft Enterprise Servers.
Now the problem with these hardball, zero-sum, “I win means you must lose ” tactics is they fly in the face of trust and fairness in partnerships that is fundamental to Web Services. So when Bill Gates says he is going to solve the SPAM or Spyware problem or open up new opportunities in Web Service vertical markets – prospective partners such as IBM(OS2/Windows), HP(New Wave), Sun(Java), Sybase(SQL Server) and others should have good reason for pause – what Microsoft Jekyll or Hyde partner am I getting this time? Or better still – how can I control the risks and somehow guarantee that TwoFace wont flip the coin and turn against me at anytime down the road ?
Now lets be realistic, IBM, Oracle, CA and other ISVs are hardly busines or standards angels – just look how the latter 3 “supported” the ANSI SQL standard. But the simple fact of the matter is “Trust Microsoft” is a risky business proposition.
Summary
ESB, SOA and Web Services by their tendency to complexity are risky ventures. We have outlined ten specific problem areas which can be condensed down to three major risks. First, Web Services are, after 4 years and still counting, maturing. The necessary and sufficient set of standards, especially for transactional and workflow Web services are yet to baked and/or adequately stress tested. Yes, n-tier distributed computing is the end game – it is the rocket science of computing. Be wary of hasty or untried/unproven solutions. Watch Wall Street, the Retailers and the Telephone companies ventures into Web Services – they respectively have the security, workflow reliability and data volume problems that will challenge such solutions.
Second it seems in these tight IT budget times analysts and vendors are even more prone to hype and sales enthusiasm. Organizations need to demand better analysis and more commitment for development mentoring and ongoing deployment support. It is interesting – that is how Open Source vendors aim to make their pay. But also organizations need better options and development alternatives – not rip & replace but how to utilize existing assets and legacy systems to act as robust Web Service suppliers. Reuse of legacy assets is the selling point of Web Services. Yet vendors are not always selling these alternatives. Neither are they empasizing a graduated approach to Web Services. Lower risk Informational (primarily read only) and Compositional (pulling together diverse info resources into a portal application) get the same priority as high risk cross enterprise workflow and long duration transactional SOA and ESB systems. Existing applications may be marked for substantial change and/or replacement before considering the operational, performance, scalability and other “hidden virtues” of pre-existing applications and workflows. After all, the major selling point of Web Services is reuse such thatbig chunks of existing proceses/workflows and their underlying systems can be quickly engineered as a whole to make any process a Web Service consumer and/or provider.
Finally Microsoft is as much a part of the problem as being a Web Services solution. The ongoing problem is how do you deal with a sometimes decidely bad major player like Microsoft. First, demand that Microsoft deliver the option in its development tools for open and standards based code development switches. Likewise in Web Services, if you use Microsoft insist that an exit or quick switch-over strategy to CORBA, J2EE or other app solution is available – Web Services are built for just such flexibility, design it in regardless of the vendor for critical portions of the system. Finally, apply the reversal of fortunes rule when bargaining with Microsoft – would they agree to such conditions and contractual constraints if the roles were reversed? Then act accordingly.
But also consider that using alternatives to Microsoft is more viable than ever before. Given the flood of Open Source software in every category, Microsoft is no longer the lowest cost producer and often is the highest cost in its monopoly share markets. Java is improving rapidly in its ease of developemnt while still setting the stanadrd for availability, reliability, security, and iinteroperability. Desktop applications are rapidly becoming anywhere applications using a browser or Flash-based interface which are ever smarter, more capable and easy to use. Finally, Web Services themselves provide avaenues for fast workarounds. In short, it safer than ever to demand better of Microsoft including being prepared to switch and be pleasantly surprised.
In sum, placing your Web Services bets requires astuteness as much as fabled agility. Go Slow is as bad as Gung Ho. Place your bets on planning ahead and measured responses that allow for real alternative systems and options – fall back strategies that have resilience. Interestingly enough, Web Services themselves should help in providing just those fallbacks.
.
References:
Myths about Web Services – good grounding in Web Services thinking
Five Missing Pieces in SOA – Infoworld special report on SOA
WebServices.org good news and white paper resource
Brent Sleeper on Web Services – a number of good papers and ideas on Web Services
(c)JBSurveyer
Mid this month I listed the top ten reasons why to go slow on the new SOA/ESB architectures. Well I have just found two more Web Servic […]