Beyond Java - Bruce Tate [44]
Still, structured data and a language to describe it are important. If you're dealing with structured data on the Internet, you're probably dealing with XML. The next successful language should let you deal with XML productively, and with good performance. In Java, we've dealt with that problem using parsing schemes, query languages, and binding frameworks. A parser cracks open XML and lets you break it into its constituent parts. A binding framework lets you take an object model and convert it directly to XML, or deal with XML as if it were a native object model. XML query languages like XQuery can reach into a complex XML document to retrieve one named piece of data. It's reasonable to expect an emerging language to support all three XML technologies, and most of them do, to various degrees.
Service-oriented architecture (SOA)
A common structured data format is not enough to bridge two languages. You also need a communications mechanism. One trend in languages like Java is to build loosely coupled services, available on the network, and let them communicate with simple messages, with an XML payload. It's a good strategy for interop, for many reasons:
SOA works best with coarse-grained architectures, or calling big chunks of code. Interop between languages is a coarse-grained problem.
SOA is hot. Since it's politically popular, support and mindshare will likely remain high.
SOA uses Internet standards. That means you can leverage existing infrastructure, like security and existing message protocols.
I'm not sure that web services, as defined by IBM or Microsoft, has staying power. I do believe that a lighter form of web services, called REST, may last. REST stands for Representational State Transfer, and it promotes using services the way Internet sites have used them for years. Like the Internet, REST views the network as a collection of resources rather than a collection of methods (like CORBA or traditional web services.)
A REST-based resource returns a representation of itself, usually in XML form. REST allows and even encourages links. REST-based services are based on well-understood, mature APIs, so unlike the fragile traditional web services stacks, they integrate well with other technologies. They can also rely on existing infrastructure to cache content, build links, or secure communication. It's a powerful paradigm shift.
So, Java provides the first set of rules, shown in Table 5-1. If you want to run this river, you'll need to meet the improved standards set by Java. To do anything less means death.
Table 5-1. Java's legacy requirements
Rule
Description
JVM and/or Microsoft Common Language Runtime (CLR)
Run in the JVM, or at a bare minimum, run in its own virtual machine.
Internet focus
Enable Internet applications.
Internet user interfaces
Allow richer Internet user interfaces.
Service layer
Provide an SOA-style integration with Java.
Web services
Allow some type of web service, whether it's the full web services stack or REST-based web services.
XML
Provide a rich, productive XML API.
Enterprise Integration
In some ways, C redefined enterprise integration, by allowing strong database connectivity across an open API (ODBC for Microsoft applications) and providing transaction monitors like Tuxedo and Encina. C was disruptive—it introduced enterprise programming beyond mainframes. Java continued this legacy with frameworks for transactions, rich database integration, messaging, and many other forms of plumbing code called middleware.
I don't think the next major applications language will initially have to have the full enterprise capabilities of C or Java to succeed. Visual Basic certainly achieved tremendous success without these capabilities by leveraging the services provided by other frameworks written in lower-level languages like C. We've already determined that the next language should interoperate with other Java programs, hopefully within the same virtual machine. It should also interoperate through a coarse-grained service