Philip Brittan's Blog

Web Services and XML Archives

Open Standards Definitions

What do we mean by open standards anyhow?

My last entry evoked a certain amount of name-calling in the arena of open standards. Today I'd like to explore just what "Open Standards" might mean. This will seem very simplistic to many of you, but I hope it’s helpful to sort things out in a simplistic way.

I’d like to start with some definitions:

Open - Open for third parties to support and create products to (opposite is Closed)

Proprietary - Legally owned by a company, individual, or private group (opposite is Public Domain)

Community - Administered by a group, not just a single company (opposite is Sole-Stewardship)

One minor note that some people seem to miss is that open and proprietary are not opposites. A standard may be both open and proprietary at the same time. A "closed standard" is an oxymoron. You can have "closed systems" which do not allow third-party integration, but you cannot have a meaningful closed standard.

A standard that is not legally owned by any company or person is said to be in the public domain. Examples of this include: HTML, SNMP, etc.

A proprietary standard is owned by a single company and may be administered solely by that company, as Windows and Solaris APIs are, or it may be administered by a community, as Java is. Some communities are have their own bodies for collaboration (JCP), and some rely on standards bodies, such as the W3C, OASIS, ECMA, and so on, to handle community collaboration and be the official keepers of the spec.

An "open source" standard is one in which the source code as well as the APIs are included in the specification of the standard, meaning that third-parties can extend the product at the source code level, not solely by working through an API. Open source is considered by many to be the purest form of open standard. But again, that doesn't mean it can’t be proprietary. Linux, a favorite open source example, is not in the public domain. The Linux GPL license does not require a monetary fee, but it does make other requirements which it imposes with a copyright. For instance, all source code for modifications made to Linux must also be freely available. Linus Torvalds explicitly owns the registered trademark "Linux". FreeBSD, as a counter-example, is also free of charge and open source, but does not impose the requirement of sharing enhancements with anyone else.

Whether software costs money, and what it costs, are economic/strategic decisions made by the owners of the software / standard. 0 is a price, just like 5 or 745. 0 just carries more psychological weight than other numbers. The underlying license and source code for Linux are free, but distributions of Linux do not have to be free. Companies can charge whatever they want for them.

The relative advantages of these are not moral. They are rooted in various benefits they give to the owners and users of the standards. One of the benefits of using open community standards is vendor-independence: multiple vendors can create competing products that implement the same standard, thus giving customers more choices. Cost, ability to extend, and ability to debug are common reasons that customers choose open source software, but keep in mind that many “closed-source” solutions do provide source code to their paying customers for debugging purposes. One might say that a sole-stewardship standard carries the risk to users that the single company administering the standard can potentially change that standard to suit only its own needs, thus causing damage to third-party users of the standard. Conversely, since a community-administered standard must reflect the interests of a group of different constituencies, it is unlikely to change capriciously or quickly. This distinction is the heart of the Microsoft / Java war of words.

The flip side of that is, of course, that since community standards are slow to change, single-stewardship standards can be much more nimble and capture the changing realities of the marketplace in a more time-sensitive way. When a standard is too slow to change, then vendors supporting the standard are sorely tempted to add one-off extensions for functionality that is not yet standardized, which erodes the value of the standard.

Customers make choices about their adherence to standards based on what they need to achieve and the risks they perceive.

Open Standards: Apps and Infrastructure

One valuable capability of open standards is to let customers decouple application decisions from infrastructure choices.

I recently spoke at a technology conference as a part of a panel, and one question from the audience was about which open standards were most important. My response was that there are many important open standards, but that one crucial capability that customers are looking for from open standards is the ability to make application decisions independently from infrastructure decisions.

The reason it’s valuable to be able to decouple those two decisions is that they are typically made by different groups within the enterprise and they are made for different reasons. Infrastructure decisions are made by the IT organization and are based ideally on price / performance. Application selection is typically made by line of business users, and functionality is the primary driver.

If a company cannot treat each of those layers independently then an application decision becomes simultaneously an infrastructure decision, which means that all the factors of functionality, price, and performance need to be considered together and the decision needs to be made by a combination of business people and IT folks, which complicates the process and potentially ends back up in “silo” structures that companies today are trying hard to escape.

Microsoft and Web Services

Web Services are a way for Microsoft to leverage the existing base of J2EE without having to do anything to support Java explicitly.

In his article, "Why Microsoft needs IBM this time around", Mike Ricciuti argues that "Microsoft needs IBM to legitimize .Net and its entire development plan as a truly cross-platform strategy." While I think that both IBM and Microsoft sincerely want to make a case for the power of Web Services and to demonstrate that it is a cross-vendor effort, I think that neither does Microsoft needs IBM to help drive sales of .NET nor does IBM have any interest in legitimizing .NET.

Web Services and .NET are two very distinct things. Web Services is an open standard for programs to exchange data over a network. .NET is Microsoft's proprietary application development and deployment framework that happens to use Web Services as part of its approach. IBM can support the former without supporting the latter.

Web Services are in fact starting to take off. A number of customers that I work with have started to adopt Web Services as both an internal IT transport layer and even also as a way to make content available to business partners (in very contained ways so far). The fact that Web Services have not yet completely transformed the world by seamlessly interconnecting all supply chains and other business partner relationships is simply a result of:

1. the fact that it take a long time to adopt any new technology, and Web Services is still very young in the grand scheme of things.



2. there are still a lot of issues with Web Services that need to be worked out to make them practicable in the large. Specifically, Web Services need more management, orchestration, transactional efficiency, and security support. These are exactly the areas in which IBM and Microsoft made a commitment last week.

.NET is also being adopted, even without companies necessarily buying into the grand plan for Web Services. So far .NET’s success has primarily been a tools success -- Visual Studio developers are upgrading to Visual Studio .NET. However, I have come across several large Java-oriented enterprises that are now planning on building .NET Smart Clients to their J2EE back-ends because they feel that Java has not given them a viable alternative on the front end.

I suspect that Microsoft's peculiar interest in Web Services is a way to leverage the existing base of J2EE installations in the market without having to do anything specific to support J2EE (which would be anathema to MS). I have argued in an earlier entry that Microsoft plans to use its domination of the desktop to push the client side of .NET and then to use the domination of client-side .NET to push server-side .NET. The challenge that Microsoft faces is that many large corporations currently have big investments in J2EE -- if Microsoft forced them to turn their backs on those investments in order to adopt .NET, then client-side .NET would face a lot of extra friction in its adoption. Microsoft can erase that friction with Web Services and then tackle the server-side (i.e. head-to-head competition with J2EE) as Phase 2 of its strategy.

Java vs. .NET, part 5 - Rich thin clients

Let Java play to its strengths and co-opt Microsoft’s advantages

In the previous parts of this series on Java vs. Microsoft .NET, I lay out the threat that .NET poses to the Java ecosystem and the advantages on which Microsoft is relying to carry out that threat.

So…what is the response to this threat? Those of you who know me already know what I’m going to say: rich thin clients. In fact, a month ago java.net readers byronsebastian and d_bleyl forshadowed this entry.

The concept of rich thin client technology is to deliver the user experience of native locally-installed desktop software (co-opting Microsoft’s strength) from server-based applications (playing to Java’s strength). With this approach, Java gives developers a cross-platform method for delivering applications that feature the desktop benefits that users want with the deployment and administration benefits that CIOs are looking for.

I’m not talking about Java Applets, Flash, or other disguised fat-clients. In order to deliver on the full benefits of the server-based model, and to avoid walking into a Microsoft trap, rich thin client technologies must leave 100% of application code on the server. Putting code on the client means putting it in hostile territory where it can be attacked and thwarted by Microsoft. Additionally, rich thin clients need to be browser deliverable, but must also be able to operate independently of the browser.

It may, in fact, be necessary to use Microsoft’s own technology to implement the generic client-side piece of a successful rich thin client framework on Windows PCs/devices. I know that there is a feeling in the purist Java community that applications must be 100% pure Java to be acceptable, but I believe that the most important piece of the chain is that the applications themselves are written in Java -- that’s the part that builds a developer community. If those applications are then displayed by Microsoft technology on the desktop so that they can take advantage of all the desktop benefits, so be it. If Microsoft really does banish Java from the PC, it just won’t matter to rich thin client Java apps running safely on the server. On non-Windows desktops and devices, J2SE, J2ME, or even native technology can be used for the generic client. The desktop technology doesn’t matter -- in the rich thin client world, it’s invisible to the application.

I am also not talking about terminal server technology, like Citrix or X-Windows. Today’s rich thin clients can offer an immediate, responsive native desktop user experience, with no lagging “remote mouse” and with very high server scalability and super low bandwidth usage. They can offer the user experience that Microsoft promises with Smart Clients.

The Java platform must offer compelling benefits beyond simply matching Microsoft. Rich thin clients can do this:

• Write Once, Run Anywhere: I just read this article titled “Java Everywhere”, which stated “To get Java working properly on all devices, we must compromise one of Java's most recognized principles: Write Once, Run Anywhere (WORA).” How sad, and unnecessary. With rich thin client technology, a single Java code base can run on the server and project its UI onto a very wide variety of client platforms. WORA can be preserved.
  
  
• Open Standards: Move the entire balance of power to the server. Then open standards have some teeth.
  
  
• Security: Keeping all your code on the server means that your application cannot be a vector for viruses and destructive bugs to client PCs.
  
  
• Developer Productivity. Writing software that has 100% of its code on the server is easier to architect, debug, and manage than either client/server or multi-layer Web apps. Rich thin clients let developers architect their systems into as many layers as they want, not as many as the technology dictates. And it’s easy to bring standard, best-of-breed tools -- Java IDEs, debuggers, profilers, optimizers, etc., -- to bear on the entire code base.
  
  
• Resource-leveling: Utility computing promises to help companies save costs by virtualizing processor load and other resources across a managed grid. Keeping all the code on the server means all the code can benefit from this.

Rich thin client frameworks are also architecturally amenable to supporting a variety of languages. As I argued in the last part of this series, the Java platform needs to recognize the huge investment companies have in legacy systems and provide a way forward for those companies without requiring that they rewrite their apps in Java. Rich thin clients bring that legacy code into a server-based, network-centric environment and then give developers a way to add new features to those legacy apps in Java. Since all the code is on the server, it’s architecturally easy to deal with big piles of spaghetti (without having to disentangle them) and to mix and match languages and technologies, all under the covers and away from users and hard-to-manage desktop computers.

If rich thin client technology takes off, then it has the effect of marginalizing the desktop PC, a big strategic win for the Java camp. Rich thin client apps don’t generally care what kind of client hardware is displaying them. Customers can go with whatever is cheap and convenient, not with the platform that happens to support their favorite apps. This paves the way for non-Windows desktop proliferation.

I believe that our industry is shaping up for an epic battle between the Microsoft ecosystem, wielding .NET, and the non-Microsoft vendors, championing Java. The battle will be very hard fought and Microsoft will give no quarter. Already they have put Java into a difficult position. The best way out of the trap is not to fight them on their terms, but to redefine the battlefield. This opportunity is available because the world is moving towards being always connected. Microsoft realizes this and is trying to use our increasing connectedness as a way to drive their platform from the desktop to the server room. The Java world needs to head them off at the pass and make real the fear that Bill Gates had of the Internet in 1995.

Java vs. .NET, part 4 - Java is a language, .NET is not

Java takes a language-specific approach to solving problems, .NET takes a platform-specific one

One of the striking differences between Java and .NET is that Java is, fundamentally, a programming language and .NET is not. .NET is a framework that supports many languages. There has been a lot of identification of C# with .NET, but C# does not equal .NET, and you don’t need to use C# in order to build .NET applications. You can use one of the 20+ other programming languages currently supported by .NET. .NET’s view of the world is from the platform. It is designed from the ground up to leverage specific aspects of the Windows platform to its advantage.

Java, on the other hand, has a language-centric view of the world. Yes, with J2EE, Java has started to create a framework around itself, and extension technologies like Jini and JXTA certainly strengthen Java’s platform, but the way in which Java attacks problems is from a language point of view.

One immediate result of this difference is that it leaves Microsoft with the opportunity to surround Java with other languages. Not only does Microsoft already control the enormously popular Visual Basic and have the ability to make C# very popular, but it can appeal to companies that already have large code-bases in COBOL, C++, Smalltalk, Fortran, and other legacy languages. Java’s answer to those folks is: port your legacy apps to Java or use some kind of awkward connector bridge between the legacy code and Java. It is not natively tolerant of legacy code.

There have been attempts in the past to support other languages with the JVM. Eiffel can compile to Java bytecode. But those efforts have not gained any real support in the Java community. Bertrand Meyer, the creator of Eiffel, writes this in a paper describing his successful efforts to connect Eiffel to .NET:

This ability to mix languages offers great promise for the future of programming languages, as the practical advance of new language designs has been hindered by the library issue: Though you may have conceived the best language in the world, implemented an optimal compiler and provided brilliant tools, you still might not get the users you deserve because you can't match the wealth of reusable components that other languages are able to provide, merely because they've been around longer. Building bridges to these languages helps, but it's an endless effort if you have to do it separately for each one. In recent years, this library compatibility issue may have been the major impediment to the spread of new language ideas, regardless of their intrinsic value. Language interoperability can overturn this obstacle.
….
The language openness of .NET is a welcome relief after the years of incessant Java attempts at language hegemony. For far too long, the Sun camp has preached the One Language doctrine. The field of programming language design has a long, rich history, and there is no credible argument that the alpha and omega of programming, closing off any future evolution, was uttered in Silicon Valley in 1995. Microsoft's .NET breaks this lock.

Everyone will benefit, even the Java community: Now that there's competition again, new constructs are—surprise!—again being considered for Java; one hears noises, for example, about Sun finally introducing genericity sometime in the current millennium. Such are the virtues of openness and competition.

In summary, .NETs multi-language support is another threat to Java. Java needs to blunt this threat. Specifically:

• .NET will surround Java with alternative and legacy-compatible languages. The Java platform needs to become more language neutral while continuing to make Java the best language possible by dynamically incorporating new ideas such as Aspects and built-in support for Web Services.
  
  
• Java's language-specific solutions will isolate it. Make sure technologies mesh with no language assumptions (object layout, data types, calling conventions, runtime context, etc.)
  
  
• .NET as a platform has more hooks into the OS. Java needs to support desktop integration (icons, file linking), which is stuff that happens before any Java code gets run. This is client side, but it's all about what you can deliver end-to-end with Java application code.
  
  
• Deploying server-side J2EE applications is a bear. Java needs platform capabilities to make this much easier. The approach of offering wizards helps, but because they are glued on, they are brittle (hard to change after you’ve gone through the process once) and not compatible between different compilers.

(To be continued. And yes, I am about to offer some hope…)

Java vs. .NET, part 3 - Open Standards

Java’s traditional weapon of choice

The concept of open standards has been the primary weapon of the non-Microsoft camp (which includes the Java community) against Microsoft. And it is a reasonable weapon. Open standards are meant to ensure interoperability between products from different vendors so that customers have the flexibility to put together best of breed solutions and, at least in theory, can swap out one vendor’s products for another’s if they become disenchanted with the first vendor on product quality or price. This means that all vendors are competing on a flatter playing field, and therefore customers and smaller vendors get the benefit of a more efficient market. Cliff Schmidt offers a very nice overview of the why, what, where, who, when, and how of standards.

Major vendors in the non-Microsoft camp push hard on the idea that Microsoft is proprietary and closed, meaning that Microsoft technology interoperates only with other Microsoft technology. A customer who goes down the Microsoft route is “locked in” and can’t choose to swap in non-Microsoft products.

The ideas behind the open standards movement are laudable, and I believe in them. Product standardization -- of electric outlets, of audio equipment connections, of bolt sizes, of fuel types, etc. -- has greatly benefited customers in general. It should certainly do the same in the world of software.

However, as a weapon against Microsoft, it has several weaknesses:

1. It only matters on the server. At this point in time, at least, Microsoft is the unrivalled king of the desktop. They set the standards there, and there are no major movements to challenge Microsoft as the standards-setter within that domain. This means that the concept of open standards in software really only has value in the server/network environment.



2. Microsoft developers don’t care. Microsoft shops are unswayed by the idea of open standards. For them, the standards that Microsoft sets are as legitimate as standards set by any official standards organization. It is a misrepresentation to say that Microsoft software only works with other Microsoft software. Microsoft has fostered a huge ecosystem of ISVs who conform to the standards that it sets. There is a belief in the Microsoft camp, justified or not, that software from vendors who conform to the Microsoft Standard interoperates at least as well, if not better than, software from vendors who conform to Open Standards.



3. The Open Standards camp is fractured. Standards are meant to foster cooperation, innovation, and customer choice. Unfortunately, in the melee of competition, large vendors are often guilty of using standards to club each other over the heads. They also use them, ironically, to keep smaller vendors out of the running by eliminating the possibility of innovation and reducing any competition to one of superior implementation of the given standard, which clearly favors large established vendors.



4. Microsoft is getting into the open standards game. Microsoft has been one of the loudest champions of open standards for XML and Web Services and has moved agressively to make C# an official standard. And they seem to be having a high time clubbing Sun over the head with various aspects of the Web Services standards process. Now, none of us believe that they truly believe in the philosophy of open standards, and there are even rumors that they will shortly abandon the official Web Services standards when they release Indigo. But in the meantime, their high visibility involvement in standards dulls the open standards arguments of the non-Microsoft camp.

(To be continued)

ASP.NET and Smart Clients

Microsoft makes money from Windows desktops, not from browsers

In response to the the latest installment of my Java vs. .Net series, a number of you responded with a focus on ASP.NET. ASP.NET is Microsoft's way of delivering browser-based DHTML applications.

Yes, ASP.NET is an important part of .NET, but I actually do not think that Microsoft is interested in promoting browser-based DHTML clients very heavily. Strategically, they need to continue to lock in Windows on the desktop, and fat clients are the strongest way to do that.

I believe that Microsoft's main strategic thrust will be around "Smart Clients". Smart Clients are .NET fat clients that rely on Web Services (served up by Windows Servers) and that can be trickeled to the client machine byte-by-byte (by Windows Servers), to make installation much more seamless to the end user. But they are still locally-installed Win32 applications.

Usability will be a primary driver for Microsoft to promote Smart Clients. Usability doesn't just mean the quality of the GUI or the richness of the controls (although those are very important). It also includes the ability to interact with other applications on the desktop (a big problem for browser-based apps) to provide an overall superior user experience (anyone remember the "Are you experienced?" campaign?).

Here is an excerpt from a newsletter that Microsoft sent around to ISVs this morning:

"ISVs: Get Ready to Deliver Smart Client Applications The Smart Client Readiness Program for ISVs gives you the software, tools, and technical resources you need to start building smart client applications. If your customers aren't asking for them yet, they will soon see the need for the next generation of anywhere, anytime data access. Enroll in the program today! http://go.microsoft.com/?linkid=215945"

Java vs. .NET, part 2 - The Nature of the Beast

What is Microsoft trying to do?

Microsoft is the uncontested champion of the desktop. In the business world, they own essentially the entire client-side market. This is a huge advantage for them. But it is also a limitation. In order to fuel its growth, Microsoft must find new, less-tapped-out markets to go after. The server room is one such market. Microsoft is already strong there, but they still have a lot of share to grow into, and it is a lucrative market.

In my previous post in this series, I claimed that Microsoft has the upper hand when it comes to the quality of the user experience. Microsoft’s user experience leadership is completely bound up with their domination of the desktop. It makes sense for Microsoft to use their hegemony on the desktop to their advantage. The client PC is their solid base, and .NET is the lever to get back to the target. .NET is an expansive strategy with many interlocking parts, and these parts come into play at various stages in Microsoft’s siege of the server room.

The UI layer of .NET is the tip of Microsoft’s spear. Microsoft leverages its usability advantage, combined with its very strong tools offering, to convince developers to adopt .NET as their platform for application development and deployment. .NET apps are delivered either as ASP.NET Web pages or as managed CLR fat clients. The thing is, in order to deploy and power .NET apps on the client or in the browser, you really need to install Windows servers, preferably Windows Server 2003 (formerly known as Windows .NET Server), in the server room. Ideally, you’ll also finally upgrade to XP on the desktops to boot!

From there, Microsoft uses the expansiveness of the .NET strategy to push out Oracle in favor of SQL Server and gets companies to install BizTalk and other Microsoft server technologies. The fact that so many companies already rely on Exchange for email helps in this. Microsoft will demonstrate the power and ease of using a pre-integrated stack from a single vendor to get customers to adopt more and more of their technology.

This is the threat that non-Microsoft vendors and the whole Java community faces. This plan is ambitious, but it is by no means easy, even for a company with the resources and advantages of Microsoft. Its success hinges largely on Microsoft’s ability to convince developers to adopt .NET. Therefore, the Java community’s challenge is to keep the tip of Microsoft’s spear from getting in by convincing developers and sys admins (and the companies that employ them) that Java has a more compelling answer for applications delivery than .NET.

(to be continued)

This work is licensed under a Creative Commons License.