Opening the floodgates

Web-based communications have = superseded=20 client-server computing to become the dominant ‘third = wave’ of computing.=20 With the recent advent of open standards such as XML, SOAP, JMS, = and PGM,=20 the floodgates to the fourth wave – message-based computing = – have been=20 opened. Brian Whetten, chief scientist at Talarian, explains how = the=20 fourth wave of computing will affect the enterprise.=20

August 2001 marked the tenth anniversary of the start of the = web=20 revolution. In August 1991, Tim Berners-Lee, a British scientist = working=20 at the International Research Centre for Particle Physics (CERN), = released=20 the first publicly available software for building websites. Ten = years=20 later, standards-based web communications have transformed = worldwide=20 computing, replacing proprietary client-server computing as the = dominant=20 paradigm. In a single decade, the third wave of web computing has=20 displaced the second wave of client-server computing, which in = turn=20 replaced mainframes and dumb terminals. The enterprise is now = poised to=20 enter the fourth wave: message-based computing. Ten years from = now, we=20 will look back on the first decade of the new millennium as the = period=20 when web-based computing moved to the next level. But how will = this new=20 wave of computing effect the enterprise? What are the key = standards and=20 business drivers behind it?

Message-based computing necessitates that values afforded by = the web,=20 such as permanent accessibility and true openness, are upheld. = Vendors=20 must ‘open up’ their technology to offer customers = true freedom of=20 choice.

Transition to the web=20

Less than a decade ago, the predominant means of linking = computers=20 together was through proprietary client-server network protocols. = Each=20 corporation was linked together to form its own island of = connectivity,=20 unable to communicate with others without extensive specialist = integration=20 software. The advent of the web afforded the possibilities of = connectivity=20 and accessibility. New presentation standards – such as HTML = – changed the=20 balance, replacing islands of connectivity with ‘the = information=20 superhighway’ that ties hundreds of millions of computers = together.=20 Standard web communication protocols (such as TCP/IP, HTTP, and = SSL) have=20 replaced the old proprietary protocols (such as IPX/SPX, SNA, and = DECnet)=20 both inside and outside the enterprise. Today, standards are the = number=20 one concern when enterprises invest in communications = infrastructure.=20 Without standards, connectivity is jeopardised.

At a superficial level, client-servers looked much the same as=20 web-style working. People worked with a local machine, typically a = PC,=20 that provided a user interface, just as a web browser does today. = A=20 corporate network allowed employees’ computers to = communicate with a=20 server, just as the internet connects servers and browsers today. = The=20 differences lie beneath the surface. In the client-server world, = each=20 application used its own client software instead of sharing a = browser with=20 many other applications. Without HTML, there was no standard = system of=20 hyper-linking and no common presentation format. At the network = level, the=20 mechanisms used to transfer data from the client to the server = were also=20 proprietary, and not shared across organisations. While there were = some=20 interoperability standards, such as CORBA and DCE, proprietary = solutions=20 such as Microsoft’s DCOM system dominated the market. = Finally, connections=20 between one company and another were relatively rare, often made = for the=20 duration of a specific task via the telephone network.

This lack of standardisation and interconnection created = headaches for=20 IT departments and users alike. The wide range of user interfaces = caused=20 confusion for users, who were not able to readily transfer skills = from one=20 application to another. IT departments, meanwhile, found that=20 client-server systems were fragile: changing one part of the = software=20 often meant revising the whole, as boundaries between the = different parts=20 of the system were not clear cut. Also, because client-server = systems were=20 tightly coupled, typically pulling data from a single source at a = time=20 using a unique interface, the systems were inherently difficult to = maintain. Sending data from one company to another was usually = difficult,=20 time consuming and expensive. And finally, because clients were = having to=20 repeatedly poll servers to find out if data had changed, it was = difficult=20 to create real-time applications.

In 1994, influential analyst company Gartner spelled out what = most=20 companies already knew: that building and maintaining = client-server=20 applications was much more expensive than the raw software and = hardware=20 costs might suggest. Gartner’s calculations of the total = cost of ownership=20 of client-server applications led to a revolution in the way = companies=20 viewed the return on investment from IT and helped accelerate the = uptake=20 of web-style working based on simple, universal standards and = ubiquitous=20 connections. This helped solve part of the problem, yet something = was=20 still missing.

The fourth wave: message-based computing =

The third wave of computing included a major shift from = proprietary=20 network protocols to standard web protocols, but much of the rest = of the=20 client-server model remains. Browsers can query many hundreds of = different=20 servers, but they must still ‘pull’ information down = to the user at=20 regular intervals, by querying servers for data. Contrast this = with media=20 such as radio and television, where users select channels and have = the=20 information ‘pushed’ to them. In effect, a browser = client is like a phone=20 that does not ring – only servers are able to take the = equivalent of=20 incoming calls. While this simple arrangement has laid a powerful=20 foundation for the initial web revolution, it has come with a set = of=20 limitations. These limitations provide much of the inspiration = behind the=20 fourth wave: message-based computing.

There are many examples of message-based computing models = currently in=20 the media: the peer-to-peer model, the real-time interconnection = of=20 business systems within corporations, streaming and content = distribution=20 networks, to name a few. In all of these examples, the computers = in the=20 system can both initiate and receive communication ‘phone = calls’. This=20 facility is enabling a whole range of new applications and = business=20 opportunities, allowing applications to communicate in real time, = as well=20 as dramatically reducing the costs of integrating and maintaining=20 disparate applications.

While message-based computing has recently become publicly = visible,=20 over the past decade thousands of the world’s top = corporations have=20 deployed message-based distributed applications for many of their = most=20 revenue-critical applications. A class of communication software = called=20 message-oriented middleware (MOM) has supported these = applications. MOM=20 products have in the past been primarily deployed using = proprietary=20 interfaces, rather than standardised web protocols. However, more = recently=20 a number of new standards have been created to support = message-based=20 computing, including Java messaging service (JMS), XML, SOAP, and = PGM=20 reliable multicast. Just as client-to-server communication = exploded with=20 the advent of web standards, these standardised messaging = protocols mark=20 an inflection point in message-based computing. The fourth wave of = computing has arrived.

Defining and understanding the fourth = wave=20

Although the basic web model is suitable for some applications, = it is=20 still inadequate for others. When based on widely adopted = standards,=20 message-oriented middleware provides an extremely versatile = communications=20 system. As the name suggests, messaging systems allow separate=20 applications to communicate by passing messages backward and = forward,=20 rather than by being programmatically spliced. The first piece of = software=20 – either client or server – generates a request, wraps = it in a message,=20 and hands it over to the messaging middleware. The middleware is = then=20 responsible for delivering the message to a remote receiver. The = remote=20 system unwraps the message, answers the request, and creates a new = message=20 in which to send its answer.

There are two basic types of messaging software: message = queuing and=20 publish/subscribe. Both provide the same asynchronous, = ‘fire-and-forget’=20 model of communication. Message queuing provides reliable message = delivery=20 for transaction processing systems, and is used primarily for = non-real=20 time delivery of messages to a single receiver. It is typically = used where=20 messages have to be delivered to a single destination, as in = financial=20 transactions. Publish/subscribe software, by contrast, provides = delivery=20 to more than one receiver at a time. It is particularly useful = when many=20 receivers need the same data, where high performance is required, = or the=20 data has to be delivered in real time.

Messaging software is particularly important where groups of=20 applications need to be integrated together, such as in enterprise = application integration (EAI) and in business-to-business = exchanges. It is=20 widely acknowledged that up to 40 per cent of IT budgets are spent = on=20 application integration. In the client-server model, integrating = 100=20 different applications requires up to 20,000 different = point-to-point=20 connections. Worse, in a client-server world each call is likely = to be=20 unique, making maintenance of the system prohibitively complicated = and=20 expensive. With messaging software, however, each client needs = only a=20 single connection into the ‘messaging cloud’. And = instead of hard-wiring=20 applications together using a blocking procedure call (where the = client=20 must wait until the results are returned), the = ‘fire-and-forget’ nature of=20 messaging allows clients to continue processing while messages are = delivered by the middleware. Even more importantly, the messaging=20 infrastructure can provide delivery that is both real time and = fault=20 tolerant, in a process that is invisible to the communicating=20 applications.

Of course, messaging is not a panacea for all. Since a separate = messaging infrastructure must be deployed, message-based computing = increases complexity for small systems; however, for larger = deployments=20 this complexity is dramatically reduced.

Message-based computing is crucial for real-time systems, such = as=20 financial exchanges or financial market data distribution. In a = financial=20 system, every time the data at the server changes (typically many = times=20 each second), this data needs to be selectively distributed to all = of the=20 computers that need that information. With a client-server system, = each=20 client would have to call each financial server every few seconds, = to see=20 what data has changed. This does not meet the real-time = requirements of=20 the financial trading community, and because of the redundancy of=20 transmission, it would also be very inefficient. Large-scale = content=20 distribution networks (CDNs) such as Akamai, and internal = enterprise CDNs,=20 provide further examples of where content needs to be pushed in = real time=20 to thousands or even millions of receivers, with managed = performance and=20 reliability. With publish/subscribe messaging, many receivers can=20 ‘subscribe’ to a ‘subject’. When a client = ‘publishes’ a message to a given=20 subject, the messaging infrastructure takes care of routing it in = real=20 time to all of the subscribers. With some publish/subscribe = systems the=20 messaging infrastructure provides very efficient one to many = distribution=20 – or multicasting – even where messages are destined = for tens of thousands=20 of receivers. When combined with the fault tolerance and = ‘fire-and-forget’=20 capabilities of messaging software, this provides a powerful = capability.=20 The rule of thumb in choosing communication software used to be=20 ‘real-time, reliable, or scalable…pick any two’. = With publish/subscribe=20 messaging, choosing all three becomes possible.

Messaging software has many other advantages. Since the = separate=20 messaging infrastructure is dedicated purely to carrying messages = backward=20 and forward, applications can be built without regard to the = details of=20 the messaging process. Many applications can thus share the same = messaging=20 infrastructure, which can be highly optimised. The messaging=20 infrastructure is inherently symmetrical: a server can easily send = a=20 message to a client and vice versa. By removing the direct = connection=20 between client and server, message-based systems also allow = workload=20 management. At busy times, messages can be put into a queue, and = dealt=20 with as soon as resources become available. As well as smoothing = out=20 bursts in traffic, this facility can allow software to cope with = an=20 intermittent connection, such as that which might be experienced = with a=20 wireless mobile device. The device and a remote wireless server = can queue=20 messages when the connection is lost, and deliver them when = contact is=20 resumed, greatly increasing the reliability of the service.=20

Standards and the role of the customer

Messaging has been very successful for high-end enterprise = applications=20 and application integration, but in the past has not seen the same = level=20 of awareness and uptake in the mainstream developer market. Prior = to 1997,=20 influential software providers such as Microsoft and Sun were = primarily=20 focused on extending existing remote procedure call mechanisms to = the web.=20 Sun created a technology known as remote method invocation (RMI) = for its=20 Java technology, while Microsoft extended its component object = model (COM)=20 to yield distributed COM (DCOM). However, the lack of open = standards for=20 messaging has been a major barrier to mainstream adoption. This = has now=20 been solved through a combination of the Java messaging service = (JMS), PGM=20 reliable multicast, simple object access protocol (SOAP) and = extensible=20 markup language (XML) standards.

The Java messaging service (JMS) is a standard API that is a = required=20 part of Sun’s widely adopted J2EE web computing = specification. JMS=20 provides a single standard API that covers both message queuing = and=20 publish/subscribe messaging products. It provides an application = standard=20 that removes dependencies on vendors, allowing buyers of JMS = applications=20 to avoid vendor lock-in and developers to build skills that are = applicable=20 across multiple vendors’ products. There are, of course, = wide differences=20 in the functionality, performance and scalability of JMS-compliant = products from different vendors. Nevertheless, the creation of JMS = is a=20 seminal event in the messaging marketplace, and deployments of JMS = products are proliferating at a rapid and accelerating pace.

JMS lays down rules about how messages are delivered, and the=20 interfaces used to pass messages from an application to a = messaging=20 system. In effect, it is like a standard address label that can be = filled=20 in and affixed to a parcel, as well as a set of business terms = that must=20 be satisfied by any parcel delivery service wishing to carry the = package.=20 With JMS, the messaging system is responsible for delivery and for = notifying the sending application of any failures that might = occur. The=20 biggest weakness of JMS is that, for now, it supports only Java=20 applications.

JMS is complemented by other standards, such as XML. XML was = created by=20 the web’s main standard setting body, the world wide web = consortium (W3C).=20 It has sought to meet a long standing need: a means to describe = data=20 arriving from one system so that it can be understood by another = system,=20 with the minimum of pre-agreement. XML has proven a phenomenal = success.=20 Many organisations are now involved in efforts to use XML to = create the=20 minimum pre-agreed formats that will let whole communities of = companies=20 and individuals exchange messages on a completely ad hoc basis. =

While JMS provides a way of writing standard labels for = packages, XML=20 provides a standard way of representing the actual contents of the = package. XML is often called the ‘lingua franca’ of = the web. Since XML is=20 a standard in its own right, XML objects can be delivered over = modern=20 message-based infrastructures or between client-server = applications. Older=20 application integration systems, like CORBA or DCOM, created = needless=20 complexity and scalability issues because separate applications = had to be=20 tightly coupled together.

Since standards like JMS cover only the programming interface = for=20 messaging systems, another problem remains. How can two different=20 messaging systems inter-communicate? For example, if one = enterprise uses=20 Talarian’s JMS product, and another uses IBM’s, how = can they understand=20 each other? The simple object access protocol (SOAP) is a new = standard=20 that is helping to solve this issue. In its current form, it = provides a=20 standard means for any two pieces of software to pass messages = between=20 them. It was created primarily with client-server-style computing = in mind,=20 and so some issues remain for using it with messaging systems. = Even so, it=20 appears likely to become the standard way that JMS products will = be able=20 to exchange messages between each other, or between JMS and other=20 messaging systems. It can also provide a standard way to connect = non-Java=20 or non-JMS applications to a messaging system. While both could be = used to=20 connect an application to a messaging system, JMS provides = standards for=20 end-to-end delivery, while SOAP only provides the way to hand the = messages=20 off to a neighbouring system. By analogy, SOAP standardises a way = in which=20 DHL might deliver packages to a FedEx pickup point, but it does = not yet=20 standardise the labelling and business terms. This is a gap that = will=20 likely be filled in the next one to two years.

One remaining question is how to standardise what happens = inside a=20 messaging system. While standardising the entire system is = impractical,=20 key network components are being standardised. The most important = is the=20 PGM de-facto standard for reliable multicasting. Just as TCP/IP=20 (transmission control protocol over the internet protocol) = provides the=20 core networking system for data delivery on the internet, so there = is a=20 need for corresponding standards for data delivery to many = receivers at=20 once. IP multicast is a standard protocol that provides the = ability to=20 deliver information to many receivers, in a very efficient = fashion.=20 However, like IP, it is inherently unreliable. Just as TCP adds=20 reliability and ‘congestion control’ to IP – the = magic that allows=20 everyone to share the internet fairly even when a piece of it is = vastly=20 overloaded – so PGM is the equivalent of TCP for multicast. =

For publish/subscribe messaging systems, PGM provides a = building block=20 for the messaging system itself, allowing it to offer much higher=20 performance and scalability for messages that need to go to many=20 destinations. This is useful in systems such as financial market = data=20 distribution, content distribution networks, database replication, = and=20 many others. Not all networks are yet multicast-enabled however, = and so it=20 is important that messaging systems do not depend on multicast. As = an=20 example, Talarian has pioneered the use of ‘adaptive = multicast’, which=20 takes advantage of native IP multicast where it is available, and = emulates=20 it in its messaging infrastructure software where it is=20 not.

Selecting a messaging vendor=20

Together, JMS, XML, SOAP and PGM provide the catalyst for the=20 message-based-computing revolution. There are now many vendors = supporting=20 these standards, giving IT managers and developers confidence that = their=20 applications will be portable between vendors. However, there are=20 tremendous differences in the capabilities of different = vendors’ messaging=20 products, particularly in the areas of performance, scalability, = fault=20 tolerance, management, and robustness. In addition, while this = will likely=20 change as the standard evolves, there are many important advanced = features=20 that are not yet part of JMS, such as security, access control, = firewall=20 tunnelling, support for other languages, and load balancing. It is = important for IT managers and developers to realise this, and to=20 understand the important questions that they must ask their = vendors. It is=20 vital for organisations to establish the requirements for their = projects,=20 and then to evaluate and benchmark the products of the top vendors = that=20 appear to meet these requirements. One of the most important = questions to=20 ask is whether the vendor is actually certified as JMS-compliant: = many are=20 not. However, where selected vendors are certified, buyers can be=20 confident that they can swap that vendor’s products for = others with=20 minimal effort, if they prove inadequate at deployment time.

Standard messaging communication systems will become an = essential=20 feature as the fourth wave of computing takes hold. As with any = invention,=20 the creation of the web cannot be undone. Where the web underpins = software=20 it demands open standards and interoperability. Any vendor that = creates=20 software that cannot readily integrate with other packages will = not find=20 success in the long term. Software vendors must therefore = collaborate to=20 survive. Any vendor that refuses to acknowledge the need to work = with=20 partners and rivals when creating new software is doomed to fail.=20 VB

Brian Whetten is chief scientist at Talarian. For more = information,=20 visit www.talarian.com/fourthwave

=	=20