The development of NDC applications is by definition a team sport, in which competing players theoretically agree to a set of rules. Standards arise from the realization that sound foundations, accepted and used by all agents within the fitscape, enable the competition to produce increasingly more valuable output. NDC frameworks provide an important layer of sediment in the common ground of interoperability shared by competing implementations, even as they attempt to solve the problems inherent in a constantly evolving milieu.
Bill Joy, one of the founders of Sun Microsystems, and until recently Chief Scientist for the firm, is credited with articulating Joy's law: Innovation occurs elsewhere. No matter who you are and regardless of your locale, financial well-being, intellectual property, or clarity of vision, innovation is going on all around you, out of your sight—innovation that affects the markets you serve and the work you do. Given the connected nature of a knowledge economy, any firm that denies the inevitability of innovation from outside is doomed to fail. For this reason, embracing standards and platforms based on standards is the only reasonable choice for developers, given at least rudimentary business constraints.
Since its inception, the Internet community has struggled to produce standards that can be leveraged to create applications that play well together in a common networked environment. With each layer of standardization, novel models of application design emerge, to either deliver value more effectively and efficiently than previous generations or to provide innovative business models, previously not possible, in lieu of heavy, proprietary investments. To the extent that players must adopt standards while competing, the business of standards itself is ripe with fitscape nuance. The “agree on standards, compete on implementation” approach, which oriented many early Internet collaboration efforts, is also subject to fitscape pressures as standards themselves become more significant to strategic business objectives. As such, the standards game has changed over the past decade, and it is useful to keep an eye on these changes as we examine NDC frameworks.
Recall our discussions of middleware in Chapter 1 and Chapter 3. Explored here are a few instantiations of what can reasonably be described as middleware, some history of the work that produced them, and some of their inherent drawbacks and promises. Comparing J2EE with the .NET framework from Microsoft is an inevitable segue to greener pastures, when organic frameworks begin to grow. But first, an examination of an earlier effort, which will provide a basis for comparison.
This story begins with CORBA, which is the acronym for Common Object Request Broker Architecture, from the Object Management Group (OMG). The OMG is an open industry consortium that keeps the flame for some specifications for interoperable enterprise applications. With about 800 members, including most large companies in the computer in dustry, the OMG is responsible for producing a number of NDC standards, including CORBA and the Universal Modeling Language (UML).
CORBA provides several useful facilities to NDC implementations, including its Interface Definition Language (IDL) specification. IDL allows developers to define interfaces to objects in a standard manner; IDL mappings bind the IDL definitions and types to languages such as C, C++, Smalltalk, and Java. As a result, CORBA provides a language transparency. Objects interact with one another through an Object Request Broker (ORB); using the language mappings, developers can create client-side “stubs” and server-side “skeletons” that their ORBs can understand and use in a cross-platform manner. As shown in Figure 8.1, stubs and skeletons serve as proxies for clients and servers, respectively. IDL defines interfaces quite strictly, so a given stub and a given skeleton should mesh fairly well, even if they are compiled into different languages or running on different ORBs from different vendors. Any CORBA-based program from one vendor should theoretically be able to interoperate with any CORBA-based program from any other vendor, transparent of operating system, programming language, or network—a powerful feature indeed.
An IDL interface establishes a set of client-accessible operations, exceptions, and typed attributes (values). Each operation has a signature that defines its name, parameters, result, and exceptions. IDL is straightforwardly object oriented, as shown in this simple IDL interface describing the classic “Hello World” program:
module HelloWorldIDLExample
{
interface HelloWorld
{
string sayHelloworld( );
};
};
The separation of interface from implementation, enabled by OMG IDL, is the essence of CORBA, by which it enables interoperability with all the transparencies cited above. The interface to each object is defined very strictly by IDL. The instance of an object—its running code and its data—is hidden from the rest of the system (that is, encapsulated). Clients access objects only through their advertised interfaces, invoking only those operations which that instantiation of the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation.
In CORBA, every object instance has its own unique object reference. Clients use these object references to direct their invocations, identifying to the ORB the exact instance to be invoked. The client acts as if it is invoking an operation on the object instance but is actually invoking it on the IDL stub. Passing through the stub on the client side, the invocation continues through the ORB and the skeleton to the object, where it is executed. CORBA uses Internet Inter-ORB Protocol (IIOP) for object communication.
To invoke any object instance, local or remote, a client first must obtain its object reference. Several easy approaches to do this have been explored by the OMG, constituting a finite set of services:
Collection Service
Concurrency Service
Enhanced View of Time
Event Service
Externalization Service
Naming Service
Licensing Service
Life-Cycle Service
Notification Service
Persistent Object Service
Property Service
Query Service
Relationship Service
Security Service
Time Service
Trading Object Service
Transaction Service
To make the remote invocation, the client uses the same code that it used in the local invocation, substituting the object reference for the remote instance. From the perspective of the client code, the invocation is the same, whether or not the object is local. When the ORB examines an object reference and discovers that the target object is remote, it routes the invocation over the network to the remote object's ORB. In this way, CORBA—in the effort to achieve a modicum of interoperability—was one of the first NDC platforms to address Deutsch's Eighth Fallacy (The network is homogenous), even if others were effectively ignored.
All forms of RPC, including CORBA, require a fairly explicit detailing of the messages to be exchanged; functions must be specified tightly, and both sides must agree. RPC encourages developers to design protocols in which the messages have a reasonably specific meaning. In contrast, messages in XML have a general meaning, leaving it to the application to interpret what is meant.
Any RPC-oriented protocol encourages developers to think of a message as a distributed method call. But in every widely used programming language, with the exception of Java platform extensions (like JAXM) in which a messaging provider is employed, a method call is synchronous; applications wait for the result of a method call before continuing. This leads to an erroneous view of RPC interfaces; rather than reification of messages sent and their inherently asynchronous nature, this approach views a message as a normal class interface, which generally leads to unnecessary network chatter at the very least.
CORBA advocates solve this problem by making heavy use of threading, which has its own inherent problems, including impacted resource utilization, application robustness, code gnarl, and lack of platform portability, which may still be of some interest in an age that will witness the proliferation of extremely small, mobile datacom processing capabilities disappearing into everything, perhaps implanted beneath our living skin.
CORBA and, by association, RPC both tend to give rise to a degree of coupling that cannot be characterized as loose. Use of asynchronous messaging, which may seem programmatically more difficult, is also mandatory if the applications we write are to become as dynamic and mobile as the instruments that carry them. While a general-purpose messaging service could possibly be envisioned by the OMG, most of the services they help define seem to be forms of messaging in any event. RPCs seem to permeate CORBA.
The great thing about CORBA is that it is heterogeneous. The major flaw in CORBA is that it is heterogeneous! Its loyal adherents continue to use it for a subset of NDC applications. Arguably, CORBA became moot the day XML-RPC was envisioned. But echoes from previous generations of NDC thinking remain; new legacies to be embraced, new interfaces to spawn. So shall it be with CORBA. Still, as a tool for comparison, CORBA provides a fine base.
Once XML-RPC was envisioned, SOAP wasn't far behind. The Simple Object Access Protocol, introduced by Microsoft, is not particularly simple, nor is it object-oriented. On first blush, SOAP may not seem like anything to get excited about; not actually new, it merely codified the existing practice of combining XML and HTTP to invoke methods in languages like the Java programming language. This practice was itself, to a certain extent, merely another way to do something that had been possible for some time with other approaches, such as CORBA IDL and IIOP.
If SOAP is significant, it is so because it represents a major step forward in the ability of applications (running on all types of devices) to utilize XML and the Internet as shown in Figure 8.2. To the extent that an XML-based Internet represents openness, extensibility, and true platform independence, SOAP can be viewed as an interoperability flag all concerns can salute.
Does XML provide all that? Despite all the investment in creating the underpinnings necessary to enable an XML-based Internet, many firms still rely on old-fashioned HTML, using tools that produce proprietary results offensive to at least one browser. Enabling business-to-business (b2b) with the productivity-enhancing network metaphor continues to lure bottom-line aficionados with the sweet promise of interoperability: if I don't like my current provider, I can just switch. Will interoperability too become competitively hygenic (i.e., expected value as with any commodity), more sediment forming the next newest layer of the Internet fitscape? Sedimentation plays a steady role in the unfolding drama of NDC.
Recall the concept of sedimentation and consolidation from Chapter 1: things that were once differentiators become fundamental expectations. Software plays in a dynamic, positive feedback system, ripe with the fitscape pressures, as the Zero Dollar Bill, which still drives software economics in the aggregate, further promotes sedimentation and consolidation toward an inevitable outcome; more and more functionality sinks to the standard platform layer. Microsoft, with the binding of its browser, multimedia interfaces and even digital identity to operating system interfaces, is emblematic of this trend. Sedimentation and consolidation are also clear in the service stack of the J2EE platform, which envisions a layer including and beyond Web Services called “Services on Demand,” as shown in Figure 8.3.
In a competitive sphere, that which was once a differentiator over time becomes a commodity. This is especially true with software. Propelled too by the open source software movement, the inevitability of functional consolidation within standard platforms is as apparent as it is disruptive to the fitscape from which those platforms arise. Sun Microsystems, as one of the top three major platform advocates, is not immune from these pressures; adaption in an oligopoly[1] of free offerings requires a vision based as much on Joy's law as on bottom-line issues. A win-win business model can side-step this apparent paradox, as long as the company, the partner, the vendor, and primarily the customer are satisfied.
The needs of all claimants, including NDC developers, are ostensibly met with the emergence of the J2EE platform. Sedimentation and consolidation are both addressed and even promoted, providing a strongly integrated NDC platform that appeals to a world of Sun customers. At the same time, the various sedimented layers in the platform, layers in which Sun competes with other vendors and partners, are based on published standards.
As the set of interfaces that enable interoperability continues to grow, seeded in XML and SOAP (which are putatively extensible), it follows that interoperability too is a candidate for sedimentation. In an oligopoly, interoperability should be a given. Witness the extent to which the airlines must cooperate in order to compete. Without an agreement on basic ground rules, your luggage would never arrive at all, much less when you do. Each airline would build and maintain its own airport; mechanics trained for one firm could never easily go to work for the next.
Interoperability at some level is an eventual given; despite concerns about small devices regarding XML bloat, that train has left the station. While XML, the message in this early Network Age, did nothing, in and of itself to guarantee interoperability, it was a good first step toward achieving it. SOAP was another step, as was XML-RPC, upon which SOAP is based. Java Message Service (JMS), found throughout the Sun Java System platform, is another good step.
Reliable delivery of a message has but one requirement: ensuring the successful transmission of the message from one node to another. XML-RPC can satisfy that requirement. But the inherently limiting synchronous primitive is overshadowed by JMS and platform technology that provides for reliable asynchronous messaging.
The JMS API specifies a common set of messaging concepts and facilities targeting Java programmers. The JMS provider implementation provides for a messaging service made of the following main components:
One or more brokers. A broker provides delivery services on behalf of the messaging system. Supporting components may include connection services, message routing and delivery, persistence, security, and logging. A messaging service may use single or multiple broker configurations.
Physical destinations. Delivery of a message is a two-phase process: first from a producing client to a physical destination maintained by a broker, then from that destination to one or more consuming clients.
Asynchronous messaging requires an intermediary of some kind; whether the service is running on my node or another is orthogonal to the discussion of reliable messaging. As such, the sedimentation and consolidation trend ensures that a messaging intermediary be present locally, on the network, and even offered as a service on the Internet. Indeed, email itself is nothing if not asynchronous messaging.
Platform services defined in the J2EE architecture for messaging service brokers include:
Connection Services—. Manage the physical connections between a broker and clients, providing transport for incoming and outgoing messages
Message Router—. Manages the routing and delivery of messages, which include JMS messages in addition to control messages used by the messaging system
Persistence Manager—. Manages the writing of data to persistent storage, ensuring reliable message delivery even in the event of system failures
Security Manager—. Provides authentication services for users requesting connections to a broker and authorization (access control) for authenticated sites
Logger—. Generates logs to file or console, enabling broker management
A multibroker messaging service allows clients to make connections among a number of distributed brokers. From a client perspective, each client connects to its individual home broker, sending and receiving all messages as if this broker were the only one in the cluster. But from a messaging service perspective, the home broker works in tandem with the others in the cluster to ensure delivery services to producers and consumers of messages.
While JMS is from the Java platform family of interfaces, XML is well represented in the J2EE platform mix, providing a bridge to high XML productivity for Java technology-trained developers. JMS is one of the Java XML Pack (described in Chapter 6), which together promise a baked-in interoperability framework that is also portable, a strong basis to which a growing number of developers are paying homage. “Services on Demand” stems from Sun's vision of the consolidation of business approaches to NDC, including the following:
Local applications: Applications that run on dedicated workstations or PCs.
Client-server applications: Applications that are split between presentation logic on a client and business logic on a server; N-tier applications are a derivative of the client-server model.
Web applications: Applications that run over the Internet, such as stock trading, email, shopping and management information services, generally based on client browsers and standard protocols like HTML/HTTP.
Web Services: Services that run over the Internet and can combine with other services to create more useful services; based on XML, this model provides loosely coupled integration (that is, interoperability) between applications, nodes, and platforms.
Web clients: Applications written in the Java programming language and delivered through the Internet to Java technology-enabled devices such as PCs, cell phones, and PDAs.
Thus, the trend toward sedimentation and consolidation also gives rise to and enables the trend of decomposition and the drive to components (also discussed in Chapter 1), as standardized interfaces embrace all current flavors of NDC applications, including Web Services. In addition, complementary frameworks like Project JXTA and Jini networking technology, and other interesting and new NDC applications can also be envisioned. Embracing the mobile PAN by wirelessly aggregating augmented information fields, for example, can also easily allow interfacing with a dynamic system like JavaSpaces or a variant thereof. A JMS provider could be the glue.
In late April 2002, along with several of my cohorts, I represented Sun in a debate with evangelists from Microsoft sponsored by the Tulsa, Oklahoma, Java User Group (JUG). The event was hosted with style and aplomb. The industry-wide J2EE versus .NET debate has been deemed “the soap opera of the decade for geeks to watch,”[2] and the contest in Tulsa was indeed one short episode in that unfolding drama. But the event afforded some useful information.
Sun, IBM, and Microsoft now form a platform oligopoly. Nearly all NDC applications find themselves interoperating with systems from at least one of these three vendors. With its embrace of Linux and endorsement of the Java platform, IBM has brought the open source software community, kicking and screaming, solidly into the corporate fold. This does not mean that other platforms are not available or will not emerge as standards going forward; indeed, wireless technologies all but guarantee competition in the mobile space. And the open source software movement has its fanatics. But the Internet, which has been a great equalizer, has also served as a platform sieve, allowing natural commodity platforms to benefit from the connection of LANs around the world. With interoperability heralded as the new nirvana, a winnowing of platforms as commodity offerings should be expected. Will the field shrink further? Perhaps, but given levels of investment in all three platform philosophies, it is unlikely that one of the three will become marginalized any time soon.
To the extent that IBM and Sun both tout a UNIX derivative as platform operating system and the Java platform for NDC application development and deployment, the two firms can be viewed as direct competitors, which indeed they are in the systems marketplace. IBM has a much greater focus on services when it comes to site installations, compared to Sun; that is the J2EE platform offers a greater degree of consolidation; more bells and whistles are sedimented into the platform, as opposed to the site-service-intensive installations coming from IBM. These comparisons between Sun and IBM are germane to business decisions, but given their similar investment in UNIX and the Java platform, the more interesting comparison seems to be between Sun and Microsoft.
During the Tulsa debate with Microsoft, a number of similarities and differences between the two companies' offerings were cited. Fundamentally, Microsoft's .NET enables code that runs exclusively on Microsoft operating system platforms. To the extent to which Microsoft is the monopoly desktop platform, its penchant for proprietary software platforms should be expected to continue, leaving it somewhat hampered in a world that now honors interoperability first and foremost. Hence, Microsoft's embrace of vanilla Web Services and the three basic ingredients thereof: WSDL, UDDI, and SOAP, which are based on XML and are known collectively as WUS.
Sun, too, honors the WUS set of interfaces, to the extent that those interfaces are a starting place. Important functionality, which would more easily enable WUS interfaces to be useful in a global business environment, has been championed by the United Nations (through OASIS) in the ebXML extensions. The ebXML work has been a bone of contention in the standards world because the extensions offered compete with a proprietary product, called BizTalk, from Microsoft. But ebXML appears to have traction and should emerge as a viable alternative to a proprietary product that ignores fundamentals of interoperability in a business sense.
A brief comparison of J2EE and .NET illustrates many of the differences and similarities between the two.
The J2EE platform enables NDC developers to simplify complex problems with the development, deployment, and management of N-tier enterprise applications. J2EE is an industry standard, the culmination of a large industry initiative led by Sun Microsystems and the Java Community.[3]
Note that J2EE is truly a standard, not a product. A developer cannot download J2EE. Rather, the specifications that describe agreements between applications and the containers in which they run form the basis for the standard. As long as both sides honor the J2EE contracts, applications can be deployed in a variety of container environments from a number of vendors, as shown in Figure 8.4.
The goal of J2EE is to give customers a choice of vendor products and tools, recognizing the impact that Joy's law has on industry evolution. As shown in Figure 8.4, a J2EE application is hosted within a container, which in turn provides the level of service necessary for enterprise applications, such as transactions, security, messaging, and persistence.
The business layer performs business processing. In larger J2EE applications, business logic is built with Enterprise JavaBeans (EJB) components. The business layer connects to databases using Java Database Connectivity (JDBC) or SQL/J, or to existing systems using the Java Connector Architecture (JCA). Business partners connect with J2EE applications through Web Services technologies (including ebXML). A servlet, which is a request/response-oriented Java object, accepts these Web Services requests, using Java XML Pack technologies to perform the operations. Traditional clients, like applets, connect directly to the EJB layer through IIOP. Web browsers and wireless devices connect to JavaServer Pages (JSPs) which render user interfaces in HTML, XHTML, WML, or whatever ?ML may emerge. Note that J2EE is written in the Java programming language for Java technology developers.
Microsoft's .NET platform[4] is a proprietary product suite that enables organizations to build Web Services. Note the important difference: .NET is a product strategy, whereas J2EE is a standard to which products are written.
The Microsoft .NET suite is, for the most part, a rewrite of Windows DNA (Microsoft's previous platform for developing enterprise applications), which includes many technologies produced by the Redmond giant. Incorporating Microsoft Transaction Server and COM+, Microsoft Message Queue, and the Microsoft SQL Server database, .NET is a fine example of the sedimentation and consolidation trend (see Figure 8.5). The .NET Framework replaces those technologies while adding a Web Services layer and some improved language support.
All .NET applications are also hosted within a container, an arrangement that provides levels of service similar to those of J2EE. As shown in Figure 8.5, the business layer of the .NET application is built with .NET managed components, which provide business processing, and connects to databases with Active Data Objects (ADO.NET). Legacy system interfaces use services provided by Microsoft Host Integration Server 2000, which can also connect to business partners by using the WUS interfaces.
Key to the Microsoft story is a perceived value proposition leveraged by the ability of the .NET framework to interleave threads from diverse programming languages into a single component. For example, a .NET component can be written partially in VB.NET (the .NET version of Visual Basic) and C#, Microsoft's new object-oriented programming language, which is similar to the Java programming language in many respects.
To facilitate this magic, source code from any language is translated into Microsoft Intermediate Language (IL). This IL code, which is language-neutral and analogous to Java bytecode, is then interpreted and translated into a native executable, by a just-in-time (JIT) compilation on the target node. The .NET framework includes the common language runtime (CLR), which is analogous to the Java runtime environment (JRE) and is Microsoft's intermediary between .NET source code and the underlying operating system and hardware. All .NET code ultimately runs within the CLR.
This CLR provides many features, such as automatic garbage collection and exception handling, not available in earlier versions of Windows DNA but long a part of the Java platform. Cross-language inheritance is also included. But the promise of multiple programming languages is not nearly as inviting as might otherwise be anticipated.
Consider the IL, for example, which has some bothersome barriers to broach before it can boast. Any language that would integrate with the component runtime must define a subset or superset of itself that maps cleanly into and out of the IL runtime and must also define constructs that provide the component metadata that the IL requires. Once that work is done, then to-IL and from-IL compilers must be written to compile language structures into IL component bytecodes. Language-specific interfaces to existing IL components must also be written.
As part of the preparation for the Tulsa debate with Microsoft, the Sun team researched the issue of multiple programming languages and the claims being made. Based on published specifications, Sun can also boast of its efforts in this direction, which have produced well over 100 bridges from non-Java languages to the Java Virtual Machine (JVM), such as JPython, PERCobol, the Tcl/Java project, an Eiffel-to-JavaVM system, and several variants of LISP. Indeed, the number of possible programming languages that can target a JVM far surpasses the Microsoft set of languages. While Sun has taken no active part in the creation of programming languages (other than the Java programming language) that target the JVM, numerous languages have emerged worldwide. Yet these tools, with the possible exception of JPython, have not enjoyed a wide degree of adoption, despite the fact that they offer the means to write code for the Java platform in another programming language.
If multiple language support is so vital, why haven't alternative programming languages targeting the JVM enjoyed more popularity? It may be that there is really no reason to use another language, given the flexibility and ease of programming that the Java platform offers. It may also be that the approach envisioned by James Gosling, which included bytecode and a JVM, is executed most naturally with the language that was designed to best serve that vision. In any event, Microsoft's promise of multiple language support in .NET is somewhat dubious, given the IL barriers to entry for an arbitrary programming language. That, coupled with the proprietary extensions offered by Microsoft in the BizTalk/ebXML drama, means that the J2EE versus .NET debate does indeed offer entertaining possibilities.
At the end of the day, Web services are simply XML-based interfaces to application, node, and network services, each of them old soldiers wearing new uniforms. The following general approaches have enjoyed the widest industry acceptance, and each represents only one of the possible ways to deliver Web Services:
An NDC developer creates, assembles, and deploys a Web Service using the programming language, middleware, and platform of choice.
The developer defines the Web Service in WSDL, which is an XML document that describes the service to others.
The developer registers the service in a registry.
A prospective client finds the service by searching the registry.
The client application binds to the Web Service and invokes its operations by using SOAP, which presents interfaces in XML format for parameter and return-value representations over HTTP.
The conceptual similarities with CORBA are numerous. As a matter of fact, almost all approaches to NDC frameworks utilize a basic conceptual model when it comes to the relationship between client, service, and service registration, as shown in Figure 8.6.
The same approach is conceptually valid whether we're discussing Web Services, CORBA, Jini network technology, and to some extent Project JXTA. That dynamic service invocation requires the client to discover services through an intermediary (the registry) is assumed in nearly all NDC existing frameworks that exist. The registry exposes attributes of a service very much like a directory in a conceptual sense; if we posit that a “directory” contains elements that certain attributes that can be wrapped in interoperable interfaces, the directory model is similar to that of a registry, as shown in Figure 8.7.
Note that very little in the way of dynamic assembly of components is overtly enabled by this simple approach. What happens “behind the curtain”—how the registry behaves, the underlying services that may be dynamically attached to a given service through its container to ensure a composable architecture—is left to the implementation and is therefore not standard. We say more about that later.
NDC frameworks have similar characteristics that can be represented by a Client-Registry-Service conceptual model. Differences are expressed in terms of language bindings and wrappers. Some subtle differences in synchrony, document transformation, and routing, which form the basis for NDC messaging infrastructure, do have bearing. Meaningful interoperability between NDC frameworks thus goes well beyond a descriptive XML wrapper and may be less probable in reality than vendors admit. But the real differences are more aptly described in terms of business models. As with much in NDC, Goff's axiom applies.
| 1. | In economics, an oligopoly is a market condition in which sellers are so few that the actions of any one of them must materially affect price or have some other measurable impact on competitors. |
| 2. | Chad Vawter and Ed Roman, “J2EE vs. Microsoft.NET—A comparison of building XML-based web services,” June 2001, www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET. |
| 3. | |
| 4. |