"One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them."
Tolkein’s catchy line from
XML is the standard for publishing the services, UDDI (universal description, discovery, integration) is the directory where services are registered so they’re easy to find, SOAP (simple object access protocol) is the transport mechanism and the key to binding and WSDL (web services description language) is the interface between services and applications.
The web services of major players like Sun, IBM and Borland are written in Java while Microsoft’s can be written in a number of languages. They all have an XML wrapper and use SOAP to move from one system to another.
The new platform standards for delivering these services comes down to two choices, J2EE or Microsoft's .Net, but in reality it will be a mixture of both, says Barnes. In the case of IBM, Sun and Borland you build the applications on top of J2EE application servers.
The term web services is also used to describe the overall approach to stitching software programmes together and building new systems over the internet, or it can refer to the specific software that links two or more systems.
SolNet e-business manager Mike Lowe describes a web service as a piece of processing logic with attributes that enable it to be described and registered, and which can discover and be discovered by other web services.
Microsoft’s Terry Allen says people building applications want some consistency in core services they use such as libraries in software development, authentication, calendaring and identity.
“Web services are a series of services that sit on the intranet and deliver core capabilities that anyone can use," says Allen. "Some will be provided by Microsoft and others by other vendors. Many will be provided by third-party developers. All those services will be written and exposed by XML.”
Enthusiasts also talk about the day when companies will be able to “rent” ready-made web services from other companies and when consumers will be able to subscribe to web services.
Hailstorm, which is due later this year, will be a series of Microsoft services that people who are writing web services can call on -- for example a wallet, calendar, document, inbox or address book. This could be handled automatically. Rather than you trawling around looking for such services, your own web service software could find what it needs. The resulting application would be deliverable to any type of device – PDA, phone, terminal or computer.
Business before technology
But that vision is way off in the future. What web services technology can you use now, and how can you get ready to use web services further on?
The advice of IBM’s Ian Brackenbury is to start with a business need.
“The nice thing is that the tools and the development environment are better than we’ve ever known before. I was involved in various CORBA stuff [an earlier inter-application architecture] which was done on the assumption that it would be good for business rather than putting the business problem first. CORBA was so monolithic that you couldn’t build fast enough to meet a business need.
Web services provides a standardised way of saying what you have and how to get it, says Brackenbury, who is a former president of the IBM Academy of Technology and helped develop Big Blue's Java technology. "Until we had web services, trying to discover what services might be available was very hard. With UDDI you can automatically find out what’s available to you.
“However carefully you design interfaces it’s very difficult to seal interfaces off so none of the system behind bleeds though and becomes part of the interface ‘contract’. Web service protocols such as SOAP and WSDL make very carefully define interface contracts. They’re so defined that vendors, without knowing about others' work, have a really good chance having their stuff work together.”
Brackenbury says once you’ve identified a business need, you need education from more than one of the major vendors about what this architecture will do for you. “The other thing is to start now. There is enough technology around to get some projects going. If you’re risk averse do it inside the company. Build new applications from existing applications and legacy systems. There is still [web services] learning going on around security, so to begin with, build behind the firewall.”
Working outward
Barnes agrees that initial web services development will be done internally. “Although having said that, the only case studies I’ve found are where they’re going outside the firewall.”
He says right now web services technology doesn’t give enough support for security or guaranteed delivery. Nor are there any standards for the creation and management of business processes when tying systems together. Enterprise application integration (EAI) software, such as IBM MQ Series Integrator or Microsoft BizTalk Server, offers a packaged way to stitch together different corporate systems and applications. However vendors, approach automation of business processes in different ways so using web services for B2B or extending the supply chain is not compelling, says Barnes.
“Where we do expect to see web services is as a fundamental part of internal application development delivery and application integration behind the firewall.”
For example, Lion Nathan IS staff have used Visual Studio.Net, Microsoft's latest development suite, to write web services that pull information from different legacy applications and present it on an internal portal so staff can check HR information online.
There are 10 different web services, all interfacing to different systems. In the past they would have had to hand-code a script for each one.
“We recommend a phased approach,” says Lowe. “An architecture that is ready for web services leaves the data where it resides -- in a database or legacy system -- and uses only the business rules for different applications. This integration is starting to be incorporated into application servers themselves.”
ACC, for example, is building back-end systems in J2EE in order to achieve this.
Caveat integrator
Of course, there’s always a downside. Although XML may well become the lingua franca of simple web applications, critics argue that when you get past very easy tasks its verboseness cripples any attempts at producing anything very complex. Besides that, many higher level XML protocols have yet to be defined.
Web services aim to steer a middle road through the complexity of Java and the verboseness of XML. Workflow and management is also important, especially as web services proliferate. As Borland New Zealand manager Annie Larsen points out, “You’ll often see developers building something and then the operations people, who weren’t even aware of it, are told to manage it.” You have to ask yourself – how will you manage all these services and what effect will they have on your network?
Meta Group says companies will have to create some sort of middleware control layer to manage web services as the technology proliferates.
Even when it comes to application integration, web services aren’t always a good idea. Let’s say a company wants to link two software offerings developed by the same vendor. There may not be any reason to use web services.
Or if a company is able to dictate key parameters that software on both ends of the transaction will use.
As Barnes says, ‘Don’t look at web services as something revolutionary. Focus on existing tools, platforms, applications and use ‘support for web services’ as an evaluation criteria for the future. Do vendors -- including database, CRM, ERP -- have web services as part of their road map?”
Sidebars
NZI: ready for web services
Embrace and extend