Process Meets Technology
Process Meets Technology
Could web services live up to their promise and spell the end of integration dramas forever? By David Braue.
It may be a bit premature to declare the end of good old-fashioned enterprise application integration, but anecdotal reports suggest that web services are indeed delivering very real productivity and cost benefits for companies that have taken the plunge.
Just ask Webjet (www.webjet.com.au), an online travel service that has built a presence in a highly competitive market based on its ability to bundle airfares, hotel prices and other information from different providers into coherent, discounted travel packages. The company had previously relied upon a third-party booking engine, but found the system did not scale and lacked the flexibility required to give customers a consistent interface into thousands of different prices and rate structures.
Webjet ultimately decided to build its own system from the ground up-a massive undertaking that would require a major investment to integrate data from many sources, each with its own way of presenting the information. Several competitors had tried and failed such ambitious projects, but Managing Director David Clarke swears the company's decision to build the system around Microsoft's .NET Framework was essential in delivering the $1.85 million project on time and on budget.
"It is a massively complex undertaking and the devil is literally in the detail," Clarke explains. "You cannot influence how the supplier presents their product, so you have to manipulate and manage it and work around all sorts of limitations. By welding together a .NET Framework and utilising encapsulated commands at the other end, we could bring together a very disparate product and put it into a form that made sense."
The decision to step into the .NET Web services-based technology was validated when booking service Galileo launched Galileo Web Services, a web service that provided a number of interfaces that let third parties such as the Webjet system search Galileo's massive database according to a range of business tools. "Had it not been for the .NET architecture and the web services at the Galileo end, I'm not sure we would have embarked on the project," says Clarke.
Webjet's chance on web services has already paid off: since the rewritten system's launch in January, Clarke says margins are up 15 percent because it's easier for customers to find and book additional products such as hotels. The company's book-to-look ratio has increased by a third; the "massively scalable" system is cheaper and easier to operate than its predecessor; and Clarke expects the new technology will double the company's gross profit in the next twelve months.
So many directions at once
Those are good results for a technological paradigm that critics lambasted several years ago as being overly complex and unnecessary. However, thanks to the concerted efforts of infrastructure providers Microsoft, IBM, Sun Microsystems and the massive development community that's sprung up around them, there is now a wealth of products allowing customers to build and exploit web services with relative ease.
In the main, web services architectures have coalesced around the collective capabilities of UDDI (Universal Des-cription, Discovery and Integration), WSDL (Web Services Description Language, recently launched in a version 2.0) and SOAP (Simple Object Access Protocol), which respectively catalogue, describe, and publish the various Web services offered by a particular service or company.
Yet fragmentation-the perhaps unintended result of feverish development around web services-has led to a proliferation of often unclear standards pertaining to the technology. Microsoft, for example, produced Disco, its own version of UDDI for companies to publish .NET Web services internally, while the IBM-backed WSFL (Web Services Flow Language) adds a layer of complexity for mirroring workflow structures.Web services standards have suffered from what has become a dual existence of sorts.
While the World Wide Web Consortium (www.w3c.org) manages the development of SOAP and other XML-based standards related to the nitty gritty of web services structure and interoperability, OASIS (www.oasis-open.org) has assumed management of a plethora of more specific web services standards including UDDI, Web Services Security (an evolution of the WS-Security standard published in 2002), ebXML (e-Business XML), BPEL4WS (Business Process Execution Language for Web Services), Web Services for Remote Portlets (WSRP), Service Provisioning Markup Language (SPML), Security Assertion Markup Language (SAML), Extensible Access Control Markup Language (XACML), and more.
OASIS also maintains working groups in web services-related areas like reliable messaging, distributed management and the construction of an open Composite Application Framework. The field gets even more crowded with the efforts of Web Services Interoperability (WSI, at www.ws-i.org), which is focused on getting all of these bits to talk with enterprise applications.
If it all sounds a bit overwhelming, you've hit onto one major problem confronting would-be web services adopters: the technology's continuing evolution can make it intimidating, particularly for smaller companies that don't have the development resources to sit down and work through the standards to figure out what they need.In many cases, this deficiency has produced web services applications that are overly complex or poorly suited to business requirements, concedes Brad Kasell, engagement manager for emerging technologies with IBM's Software Group.
"People by and large have concluded that web services is a viable alternative, but a lot of companies have put services out there without thinking about how they're actually going to be used," he explains. "Sometimes it's not to their advantage to expose everything, but they've been focused on getting it out there rather than on what effect doing this will have."
Completing the puzzle
Web services will need to put more runs on the board to become more widely adopted, but that will take time. For now, vendors are working to improve the functionality of their development environments in order to avoid scaring off customers who feel that Web services have to be immeasurably complex in order to work.
IBM, for example, is combining its core web services infrastructure tools with its expertise in workflow and service management to bridge the gap between design and development tools. Ultimately, this will allow business analysts and software developers to work from the same page, with changes on one side of the equation mirrored in the services that are being built on the other.
Microsoft is undergoing a similar effort through products such as its recently released BizTalk Server 2004 and the graphically oriented Visual Design Studio, which will build on the company's Visual Studio.NET development environment to allow developers to map business process flows in the context of the web services that support them. And Sun, for its part, is hoping to win converts to its Sun ONE web services vision by building far more graphic development tools that bring J2EE-based Web services development up to the bar set by competitors.
Development tools are only one part of the puzzle, however; equally important is the environment's back end, where increasingly intelligent application servers are being taught the Web services canon and tasked with the sort of scalability and availability features necessary to maintain performance in a Web services environment. It's one thing to publish a web service to let your business partners lodge invoices online, for example, but another thing entirely when heavy demand slows down performance to a crawl; tomorrow's server environments will detect the spike and automatically locate more web services-enabled resources to meet the demand.
Can technology alone save web services? Not necessarily.
Customers need to be actively trying and retrying their web services strategies, thinking through both the technical and business implications of the shift. And even as infrastructure technology continues to improve, commensurate improvements in the communication of business and technical staff will prove even more beneficial. By allowing team members to work together to define and deploy Web services, Kasell believes evolving development systems will allow those web services to hide the complexity of business processes and focus on getting data to flow as efficiently-and simply-as possible.
The key is to think small, not big. "Sometimes there's a situation where people over engineer web services because they feel they have to apply all of the standards in some way," says Kasell. "For example, [SOAP] is designed as a relatively simple, loosely coupled protocol but people tend to want to put a lot of extra processing layers on top of it because they're used to dealing that way with traditional integration. People tend to put in a lot of extra processing, but probably eight times out of ten you can get by with the basic profile and a little bit of common sense."
Related Article: