Web Services Overview
 |
 |
Featuring:
A Cautionary Look at Web Services
Credit: Imagenation
| Caution on Web Services What is a C-level executive to do these days ? If they pick up any business publication there is some breathless story about the next Web Thing, Web Services. But there is also another story how the excesses of the dot.com "new business model" have called into question major chunks of Internet strategy and technology fixes. Surprisingly, the best path may be to take the advice of the Federal government's April 2002 GAO-Government Account Office Report on XML - proceed, but very carefully. This bureaucratic caution is getting serious seconds from the private sector ISVs, VARs and IT shops that are actually out there doing Web Services and/or building the tools to implement them. For example the feedback of VARs and ISVs at the recent Borland Conference (henceforth, BorCon, the rather puckish name for Borland's annual developer conference ) roundtable discussion of Web Services was decidedly mixed in their evaluations even with preliminary forays into this arena . Likewise, presentations at this Spring's Java One conference also cited similar cautionary notes echoing the GAO's XML Report. Specifically critical warnings on Web Services collect around the following four issues: 1)The standards are not baked yet. Yes, the important base standards HTTP, XML, URI, XML-RPC, XML-SOAP, WSDL, and UDDI are approved and do provide a base for doing Web Services. But as we shall see in detail below(see Table 1), important secondary standards regarding security, authentication, and transactions among others are still in various stages of approval. As one BorCon roudtabler said - "how can we really do Web Services when, among other things, there is no standard way of doing simple things like checking the status of a Web Service message". 2)The tools are just emerging. Yes, major new and improved tools like BEA Weblogic Workshop, IBM WebSphere Studio, Microsoft Visual Studio.NET, Oracle JDeveloper, Rational XDE and others have just hit the streets. And more tools are set to arrive. But many of these tools are brand new or major revisions; some with substantial learning curves. Beyond these teething issues associated with new software, all of the tool vendors have had to make some sort of decisions on how to fill in the gaps where standards are not available. Be assured there is a lot of proprietary jockeying going on in these "non-standard" areas. One Java One presenter referred to the latest software as "proprietary traps". 3)The legal implications are not settled. Think of Web Services as little ASP-lets, Application Service Provisions available for automatic hookup on the Net. However, the whole problem with the ASP model of doing business has been what happens when the service fails to deliver. First, many shops have had to go back and renegotiate their service level agreements with ASPs. What happens in the automated world when the Web Service fails to deliver or worse, delivers erroneous information that does great harm to your organization and/or its clients ? 4)The dark side of Web Services has to be considered. Ziff Davis columnist Peter Coffee has raised this issue before and did so again at the BorCon roundtable. What happens inside the Web Services black box? What prevents the provider from collecting information on your pattern of requests for service in order to act against you based on that info? Or trade it with others? Or shunts your request onto a b-list under the guise of having to do extra security and validity checks with a resulting delay in response or service? Or passes the message onto another 3rd party's Web Service innocently (or knowingly) who happens to be a serious competitor to your company? With enormous and rapid computing power at their disposal - the opportunity for low-level gamesmanship (or is that gainsmanship ?) through Web Services has to be seriously reviewed. And of course it is a perfect setup for business malfeasance - do this because we can amply reward you with "results based compensation" but if you get caught we will disown you as being "irrationally exuberant", low level hackers beyond our knowledge and direct purview. And besides this type of white collar crime is legally hazy if not very hard to prove and gets kid glove treatment if it ever hits the courts. So for a variety of reasons Web Services get a distinctly yellow, proceed-with-caution signal from a variety of sources. Yet Web Services are too important to ignore and delay any implementation on. Web Services derive from an accumulated set of technologies extending from the earliest days of EDI-Electronic Data Interchange. Already businesses are extending ever more wider aspects of their systems outside the corporate firewall. SCM-Supply Chain Management and CRM-Customer Relationship Management systems are one of the fastest growing arenas of business to business computing. But now organizations need to integrate these systems into more effective whole so they can deliver on the 7A's of IT - Access to Any information by Anyone Authorized Anytime, Anyplace on Any device. This is the so called Enterprise Application Integration -EAI problem and Web Services are a key enabler. The balance of this article looks at how to do a feasible and fairly safe entry into Web Services. The Web Services - What Are They ? Web Services are often called endpoints. This developer prefers to think of them as smart nodes or synapses. The idea is that Web Services are smart endpoints for translating request-for-services messages among IT systems and servers in a language, XML, mutually intelligible among the systems. But remember the main business Web Services are in is providing for much more robust remote procedure calls or request for services between two or more distributed systems. In order to accomplish this formidable task, Web Services provide at least 4 things at these smart nodes or endpoints: 1)standard methods for transmitting those requests/messages including HTTP, SMTP, and other Internet protocols; 2)packaging for the data/parameters of the request/message in XML including provision for translation bindings between different system encodings (Unicode, Hexadecimal, ASCII, etc); 3)provision for a programming language and OS platform neutral description in XML for the specific type of processing/service requested; 3)provision through XML's extensibility for additional metadata about the terms and conditions of the message/service request. In short Web Services provides a standard way to call on data and processing anywhere over the Web using XML. One side is the consumer/requester and the other side is the supplier/provider and XML is the common language between the two. Of course, depending on the terms and conditions of the request, this process may be repeated many times to finally complete the request for service. It is important to underline again that the actual processing steps on either side of the basic interchange process may be done in any XML-aware language or software. In sum, Web Services are simply a way to link or hookup systems anywhere on a network in a standard way Web Standards Given the complexity of distributed processing, many IT shops are moving on standards. Rather than be early adopters who have to bear the brunt of beta-flaky code or have to retrench due to evolving technology and standards; these shops wait until a set of standards that covers their task set emerges and then they make their final decisions on what processes and tools to use. So there are are some attractions to Web Services. First, the base standards are in place such as XML, SOAP-RPC, WSDL, and UDDI (though see the caution below). Second, other distributed development standards have progressed well. For example, J2EE-Java 2 Enterprise Edition have also developed a standardized way to to do sophisticated suite of messaging and transaction processing anywhere and on just about any OS platform. In fact there is a very rigorous suite of over 5000 tests which vendors must pass to receive J2EE certification. Second, all of the Web Services standards to date have been developed in non-proprietary, non-patented, open XML which any vendor can link up to. This means very proprietary platforms such as Apple Macs using OS/X and Web Objects, IBM AS400 using OS400 and WebSphere, plus a Compaq Proliant using Microsoft Windows 2000 Server and .NET Framework - all can interact together through Web Service links to do large scale system tasks. And so Application Developers, especially those using J2EE tools, have rushed in and developed a wide array of tools (see Table 2 below) that link together different systems helping to solve the so called EAI-Enterprise Application Integration problem - no more islands of information! This is why Web Services are so compelling. |
||||||||||||||||||||||||||||||||||||||||||||||||
| But there is a catch. The current difficulty of XML based Web Services is that there is a set of base standards
but not yet a set of complete standards (see table 1 and standards discussion below). Note what is missing. There
is no standard provisions for authentication, encryption and security, backup and recovery, and as previously noted
even status checking is missing. But because the interchange mechanism is primarily XML, some vendors are already
recommending system designs such that just about any transaction can be programmatically formulated between requester
and a duly authorized and authenticated 3rd party supplier. The first contradiction is that only under benign or
very trusted circumstances do individuals or organizations currently want business to business transactions to
be carried on for them by computer proxies making up "dynamic contracts". We have already raised some
of the legal and malfeasance issues raised by Web Services. There is also a strong issue of individual privacy. For example, in the case of software agenting, the last thing I want my machine to do is to start dickering over price with a dozen or more web software shops for my next OS copy. First, this is |
|
|||||||||||||||||||||||||||||||||||||||||||||||
| likely to unleash a deluge of spam e-mail solicitations no thank you. Second. I do not want some retailers building
up a profile of my computing preferences and price sensitivity. Finally, I simply may not want any knowledge of
my computing preferences available to any publics. But most significantly those second tier of standards have yet to be baked . For example, Gartner Group's Darryl Plummer sees that "the illusion of Web services unity cultivated by IBM and Microsoft is about to be shattered ... prepare for a flurry of Web Services disagreements among vendors." His colleague, Ray Valdes, sees as a consequence "most Web Service projects won't deliver significant business value until more flexible protocols arrive." While Michael Barnes at META Group sees "widespread adoption of Web Services for external application integration (B2B) will take 2-3 years, as support for security and collaboration are yet to stabilize". Echoing the concerns raised at major developer conferences, many leading analysts are issuing cautionary reports on developing with Web Services with unfinished standards being one of the key problems. Tooling Around Web Services It is somewhat paradoxical that simple Web Services are relatively easy to do. Eric Newcomer's very recent book Understanding Web Services does an admirable job of explaining their foundation and usage. Or try the exercises in Ethan Cerami's book Web Services Essentials. All users need are a PC and dial-up Internet connection. The software is totally open source. Following instructions not programming skills are all that is really required. Yet astonishingly quickly, Web Service transactions can become quite complicated. As previously noted there are a surprising number of elementary operations which are not yet standardized . So developers have had to fill in the blanks themselves - and in the arena of security and transaction processing these tasks are non-trivial. Finally, just as the Web forced IT shops into 3 tier architectures - where a program no longer resides on one machine but is smeared over several different servers; Web Services not only invokes this multi-tier architecture but often does so by adding a new level of programming sophistication - asynchronous processing. Most programs run synchronously, one requested operation sequentially after another. If a requested operation does not run to completion, an error message or exception condition is raised and the program can be redirected to other activities or terminated. In asynchronous processing as used in many Web Service enabled apps, several requested operations are also done but in parallel. The program does not wait for a reply but continues on doing (often requesting Web Services) all the tasks requested of it while awaiting return messages and queuing them up for final reconciliation. The advantage is, if all things go well, much quicker processing because portions of many operations are done in parallel. The disadvantage is a more complicated programming model. In addition, there is a sticky wicket when a message or transaction breaks down. For example, what happens when a request for service can't complete due to an outage ? Or maybe it can complete but not on the terms and conditions requested. Or maybe it can complete and on acceptable terms and conditions but so can three other matching service providers. How does your program break the tie ? First come, first accepted ? And if required, how do you break off a long transaction which may have already incurred intermediate steps, costs and commitments? True, Web based processing has already given companies experience in these long duration transactions - but that does not make them any easier to do. |
||||||||||||||||||||||||||||||||||||||||||||||||
| Another paradox is the continuing diversity and change in distributed processing that surrounds Web Services. One
would think that after 50 years of computing, twenty five involving distributed processing, all of the techniques
and methods of Web Services + distributed development would be well known. Software vendors would be doing engineering - that is plying their trade from a well understood set of tools and technologies. And to an extent this is true. One of the development advantages of Java (and presumably the .NET Framework, too) is the huge base libraries available to developers. And even asynchronous processing has its middleware like IBM's MQSeries or Tibco's Rendezvous which have at least ten years of development work each. However, the reality is that Web Services enabled tasks raise some new and tough distributed processing problems like federated joins among heterogeneous databases and complex long duration transactions with special rollback conditions. In fact, Borland saw fit at its recent conference to announce not just its Delphi product geared up for new levels of Web Services; but also a new scripting language dubbed "Charlotte" designed specifically to expedite Web Service-enabled distributed development. Borland has a well justified reputation for turning |
|
|||||||||||||||||||||||||||||||||||||||||||||||
| out high quality development tools, and by going with a scripting language in addition to Delphi and JBuilder enhancements;
Borland is moving Web Services + distributed programming up a notch in abstraction for the benefits of quicker,
easier development. This up-abstraction corresponds with a new class of integration workbench tools from Asera, Bowstreet, Kinzan and SilverStream among others. These tools integrate Web Services at a higher component or portlet level of service. This allows fast integration to CRM, ERP, SCM and other enterprise applications. Most are based on a Java/J2EE framework; but some have crosslinks to .NET and legacy enterprise applications. As well these workbenches address the problem of standards by adopting frameworks from firms such as Entrust or Netegrity who already have a position in the final Web Services standards as they emerge. Finally, some of the workbench and classic IDE-Integrated Development Environ vendors are starting to develop special designers for workflow and asynchronous processing. The key is to design and refactor at the framework and higher levels of granularity - supplying easily customized portals, web interfaces, and report profiles as asynchronous processing waystations. In contrast, developers like BEA with Weblogic Workshop and Rational with XDE are taking a combination GUI + Wizards route to improve their Web Services development tools. The idea is to make the process of "gluing" together services as easy and as transparent as possible. But at the BorCon roundtable on Web Services, when the delicate question of runtime performance came up for these "glue" tools, the only thing participants could agree on was that there were no widely recognized benchmarks for Web Services like TPC.ORG's suite of database benchmarks. So as might be expected Oracle, Microsoft, IBM and others are engaged in Pet Shop benchmark wars. Also there is no small amount of controversy over whether some forms of Web Services using WSDL and SOAP are over engineered with performance and ease of development taking a big hit. (see Paul Prescod's Google's Gaffe in the references below). And as for methodologies for Web Services development - processes ranging from Agile Development through Extreme Programming to Rational's Unified Process were bandied about as being well suited for Web Service projects. The problem is no one can agree on the criteria by which a specific methodology can be chosen for a particular development task and environ. In sum, Web Services is still on the bleeding edge of development, especially with so many second and third generation tools reaching the market (see Table 2); so be prepared to have bandages and a contingency strategy ready. Finally, there is the contradiction in standards. In a Software Development Conference discussion group, an attendee a)praised the existing standards as being vital to Web Services because standards eliminated redundant development while ensuring high interoperability; b)chastised the current standards groups such as IETF, OASIS, W3C and others as being too slow to promulgate robust second level Web Service standards and 3)embraced new standards consortia such as WS-I. And of course, this is the conundrum facing Web Services standards makers - "hurry up but get it right". Now its not clear what role the new WS-I Web Services Interoperability organization with well over 100 new corporate members will play in standards development. However, WSI founding member Microsoft have distinctive views on what role WSI should play as voiced by VP of Developer Tools Tom Button in his interview (see references below). These and other views have tripped off some distinctly dissenting opinions such as Edd Dunhill's Kicking Out the Cuckoo piece (again, see references below) where he called upon W3C to cease and desist trying to set Web Services standards as IBM and Microsoft had set up a consortia to manage that task. So with so much standards turbulence emerging just before and after the release of the GAO XML Report - the report's cautions on Web Service standards are looking remarkably prescient. Approaches to Web Services If you told any software expert from Gartner, Giga or Meta 10 years ago that dynamic code generation, virtual machines and plain text markup languages would dominate distributed processing, they would have chanted DCE, IDL, RPC, CORBA and GOon/GetLost. Yet dynamic code generation through ASP, JSP, or PHP; virtual machines like Sun's JVM or Microsoft's CLR; and text-based markup languages like HTML and XML dominate the current distributed processing scene. An IT shop simply cannot afford to take a 2-4 year hiatus from development. Fortunately, here are a number of successful approaches to Web Services. culled from recommendations at 4-5 major conferences. The approaches concentrate on risk reduction by controlling for one or more of the four factors that are most unsettled in current Web Service offerings: a)the standards; b) the complex, competing technologies; c)the legal ramifications; and d)hackers and business malfeasance.These are projects that do Web Services that are: 1)inside the firewall concentrating on meeting internal customers/users needs- control legal and hacker risks; 2)based on trusted partners outside the firewall with no/low transaction requirements-control complexity, legal and hacker risks; 3)informational only - no asynchronous processing, no updates-control complexity risks; 4)simple with short time span and known technology - control standards and complexity risks; 5)based on service level agreements and standardized methods - control standards and legal risks; 6)simple and internal first when using asynchronous processing - control complexity and hacker risks; 7)internal and without asynchronous processing when first trying complex update transactions - control hacker and complexity risks; 8)based on trusted third parties who have web services experience - control legal and hacker risks; 9)innovative in trading skills in one area of Web Services for others you are skilled in with development partners; 10)employing standards compliant software including those allowing for future directions in standards. Ask vendors how compliant they are on working standards and/or recommendations; These approaches have been adopted by some large organizations. For example, Intel has become a major information and service support provider both internally and externally through Web Services. Ditto for Cisco and WalMart with particular emphasis also on SCM-Supply Change Management. Consultants from Giga and Gartner are recommending that companies apply Web Services on internal EAI-Enterprise Application Integration projects. This approach nullifies legal and darkside Web Services issues while allowing companies to try some of the emerging standards such as ebXML or Rosetta Net in controlled environs. A number of VARs at the BorCon roundtable recommended a hybrid of this approach, using trusted business partners with experience in EDI as candidates for Web Services projects. Here potential Web Service developers can afford to be both consumers and providers of Web Services because that mimics their roles in the EDI framework. Another fruitful area for application of Web Services internally is in Grid Computing. Grids help companies tap underutilized computing resources in more efficient ways.Leading Grid vendors such as Sun with its Grid Engine and Platform Computing's LSF are already utilizing Web Services, again in a trusted and internally secure setting perfect for taking advantage of Web Services safely. However, an ongoing issue for Web Services is establishing what the current state of the standards are and what technology can do to help solve IT requirements reliably and safely. Summary Web Services have been misnamed. A better tag would be Web Service Calls. Web Services really enable and extend remote procedure calls in 3 significant ways. First, through the use of XML throughout, a vendor neutral set of standards have emerged so far. This is important because EDI and other distributed processing arenas have been plagued by proprietary systems stifling free interchanges. Also this helps to make a MacOSx desktop as accessible to a Palm OS PDA as a big-iron IBM mainframe. Next , use of XML provides two added benefits: Web Service Calls can be easily extended and automated. Extensibility is taken advantage of by SOAP, XACL, WSDL and other Web Services methods which allow for simplifying complex transactions while delineating added business contractual rules. These business conditions and rules are expressed in a mutually understood and beneficial manner. Thus Web Service Calls can include authentication, non-repudiation, auto-reconciliation of parameter bindings, service level condition checks and a variety of other user-defined conditions. The relative ease at which business rules can be incorporated into Web Service exchanges go well beyond the domain of nuts and bolts RPC-Remote Procedure Calls. Finally, many Web Service Calls can be dynamically created by trusted system linking together in adhoc interchanges - no special IDL pre-compiles required. In fact this automated or programmatic capability of Web Services is both a strength and a source of risk because without strong, consistently enforced security and authorization measures, IT systems can be vulnerable to serious hacker attacks. So the fundamental attraction of Web Service Calls is the opportunities they open in application development. Isolated islands of information should be a thing of the past within organizations as ever more sophisticated EAI-Enterprise Application Integration emerges using Web Services . Between organizations, as Web Service standards get ratified, there should also be a growing richness of B2B interchanges. Already booming are peer to peer, software agenting and grid computing as they start to take advantage of Web Services. As well B2C-Business to Consumer and C2C-Consumer to Consumer computing will also start to develop as Web Service's second tier of stanadrds start to click into place. Thus there are a wealth of new application development tools and approaches emerging using a variety of Web Service Calls; as always, the trick is to balance risk with rewards- and this survey agrees with the GMen, for the next 9-18 months exercise caution and control in deploying Web Services. References: Challanges to Effective Adoption of XML, GAO Report 02-327 - April 5, 2002 Kicking out the Cuckoo by Edd Dunhill, www.xml.com - argues that WS-I is intent on usurping the W3C from Web Services standards making Google's Gaffe by Paul Prescod, www.xml.xom - looks at the complexity and overhead of SOAP/WSDL over much simpler Web Service methods .NET Solves Today's Problems by Patrick Meader, www.fawcette.com/reports/tech-ed/041002/button2/ - Where goes Microsoft and standards Understanding Web Services by Eric Newcomer, Addison Wesley - comprehensive overview from a transaction processing expert Web Services Essentials by Ethan Cerami, O'Reilly - excellent overview plus real, do-it-yourself program examples Web Services Acronyms Demystified by Pavel Kulchenko - www.xml.com/pub/a/2002/01/09/soap.html XQuery:Reinventing the Wheel ? by Evan Lenz, www.xmlportfolio.com - argues that XQuery and XSLT largely overlap |
||||||||||||||||||||||||||||||||||||||||||||||||
| Jacques Surveyer is a consultant and writer; he can be reached at jbsurv@thephotofinishes.com | ||||||||||||||||||||||||||||||||||||||||||||||||
Top of Page Tutorials Home