All About: Web Services

2005-05-25

Distributed applications are nothing new – parts of software applications, each running in the most appropriate place and on the most appropriate hardware. In general, distributed applications separate application functionality (say, the database engine, the security functionality, the transaction engine and the number crunching) onto different servers. Now, imagine if these application elements employed the Internet as their communications mechanism – they could be situated anywhere on the globe. Imagine still further – if different third parties managed such elements, we could access them as services over the Web. There we have it – Web services. Here we consider the essential elements of Web services, particularly the platform technologies UDDI, SOAP and XML, and we look at the efforts of software vendors such as Sun and Microsoft to provide suitable frameworks for Web services. We consider the potential benefits of Web services and examine whether such applications are deployable today. We look at the issues facing Web services, particularly the fact that much is still vendor hype, and look at how Web services will evolve in the future. What are Web Services? Defining Web services is about as tricky as defining terms like “application” and “infrastructure” – we all use them, nobody knows exactly what they mean, but somehow we muddle along. Consider the following. Point one – a software application can be thought of as a set of software elements, each dealing with one part of the functionality. Point two – these software elements can communicate using defined protocols and mechanisms. Point three – the elements do not need to reside on the same machine. Point four – in fact, they can be situated anywhere in the world and they can be managed by any third party. Whoa! Hang on there. Things were going OK until the last point, right? But why not separate components across the Internet – it is a good enough basis for human communications, so why not use it for programs (or even parts of programs) to communicate? The more that this is thought about, the more two points become clear: • There needs to be an Internet-friendly set of mechanisms to enable the communications to take place. • This is an appropriate basis for some, but not all applications. On the basis of these points (which we shall come back to), there exists the potential to construct applications from piece parts that are accessed over the Internet from different providers. These piece parts are called Web Services. Clearly, mechanisms to support Web Services need to have been accepted as a standard by the major players in the industry – in this case, Sun, Microsoft and IBM. Successfully agreed, accepted and adopted are: • The eXtensible Markup Language (XML) is text-based formatting language appropriate for defining and transmitting data between application elements across the Internet. XML has been accepted and adopted by all the major industry players – well, all the ones that matter. • The Simple Object Access Protocol (SOAP) is a standard for sending messages between objects – just think that any application element can be considered as an “object” and you won’t go far wrong. • The Universal Directory Description Interface (UDDI) provides a globally accessible registry of service providers and what services they provide. It is with application support frameworks where things get tricky. A number of major IT companies are positioning themselves as framework providers – indeed, this is where they see that there is money to be made. In particular, Sun, Microsoft, HP and IBM have frameworks of their own namely Sun ONE, Microsoft .Net, HP NetAction and the IBM framework for e-business . The final piece in the Web services puzzle is the provision of a communications mechanism, which enables application elements to communicate via the Internet. Here we have “open” versus “proprietary,” with the UN- (and Sun)-sponsored ebXML (“XML for electronic business”) in competition with Microsoft’s BizTalk. The other mechanism worthy of mention is RosettaNet. The Business Benefits of Web Services In the past, applications (distributed and otherwise) have been used by single organizations and accessed over the corporate network. The arrival of the Internet has enabled companies’ systems – and their applications – to talk to each other directly, for example in the form of a supply chain or a marketplace. Business benefits are summarised by the various vendors of Web services – Sun has a good overview of the current and future benefits here (it’s marketing but so, for the moment , are Web services). We think that the benefits are a combination of the benefits of ASPs (of which Web services are a logical evolution) and good development practice. Maybe, with Web services, the Shangri-la of software reuse will finally be achieved! Deploying Web Services For developing applications, there is quite a lot of material out there on vendors’ specific Web services offerings (particularly Microsoft), however there is notably less cross-vendor information. As with other areas of application development, patterns provide a means to familiarise yourself with how to solve specific problems. Issues with Web Services Web services are still new and hence the issues are still to be fleshed out. For the moment they can be summarised as: • Complexity – building web-services applications is not easier than building traditional applications, for two reasons. First, it relies on an understanding of how to build component-based applications. This is the masterclass of object-oriented development – while many can write in Java or VB, few understand the key principles of good design for component-based applications. Secondly, building an application on Web services could be likened to building a house on shifting sands. There will be many out there that claim to be delivering Web services, and few that eventually turn out to be reliable. • Security – it’s that old applications-on-the-Internet thing. The Internet is an insecure environment and, at the moment, there is a lack of will to implement the necessary mechanisms (such as PKIs) to build a layer of security. One security issue is with publishing service interfaces, in that they are by nature exposing doorways into the systems that provide the services concerned. The Future of Web Services Er – hang on, Web services are the future, right? Certainly as far as computer companies are concerned. There are many articles in the press describing the gambles that the vendors are be making to be part of this brave, new Web services world. Are they right? Well, we think so. It fits with the trends – towards outsourcing, commoditisation and component-based development to name a few.