Ardethan,
I agree that the question of .NET vis a vis BEA is not one that affects today's investment decisions. I believe that I can clarify what I mean by characterizing BEA's approach to web services as "open' in contrast to .NET as proprietary.
Before I do let me make some appropriate disclaimers. I am not a technology expert. My knowledge of technology and BEA for that matter is only onionskin deep. I began to research BEA when the board began to discuss it. In that time I have put in many 10-hour days reading, thinking, and writing about BEA. What little I know of BEA is learned from their web site and white papers primarily and others' posts secondarily. I know far too little about software in general, and have not yet done any specific due diligence on its competitors. I listened carefully to Coleman's talks that can be found at www.bea.com. I cannot do much more than to present BEA's story and to apply, as best I can, the set of gorilla criteria. I have no business or financial expertise. In fact, about all that I can offer is a scholar's devotion to learning, and the experience that comes from being at home in a world of ideas, able to enjoy a good visionary when I find one, finding, in Abe Lincoln's words, "the fire of ideas" to be genuinely exciting. My hope is that my colleagues will correct me where I stumble and add their abilities and insight to make-up for all that I lack. I decided to do this much because I believed BEA was getting short shrift here, and as one of the few potential enabling gorillas that it had too much potential to be glanced at and set aside without more careful inspection. I will not have answers to most of the questions and concerns raised about BEA; I believe that you should find your own answers and share them with us. I am skeptical of answers that are not based on research, so, I urge you to do yours and that we combine our information and analysis. I believe that Philip Fisher's call for investigative research is basic for success in investing, and see this board as a resource for improving the quality of what any one of us alone might do. I value what emerges from the competition of a free marketplace of ideas.
Coleman says, and Matt Tomkins agrees, that history is on the side of the focused newcomer because each new wave of computing has spawned a new leader because of the old wave's Innovator's Dilemma. Going beyond that point, Coleman argues that .NET is complementary to BEA's leading position in J2EE Web Services. Coleman sees BEA as targeting the high-end enterprise market and Microsoft as targeting the mass markets of homes and small offices. Not only that, Coleman knows that he is ahead of Microsoft at this time and believes that he knows how to win a race, especially when competing against a known proprietary monopolist, when BEA is leading in WS technology, and when winning requires building a value chain of complementary partners.
The Future Web Service Gorilla Game.
With Web Services (WS), the next generation of distributed computing arrives. The impact of the Internet's ability to spread information worldwide through a heterogeneous network of computers heralds a sea change in how we live, work, learn, and play. According to a white paper written by Vawter and Roman, a simplified means of sharing process worldwide will be truly revolutionary.
theserverside.com
According to Graham Glass, a web service is defined as "A collection of functions that are packaged as a single entity and published on a network for use by other programs. Web services are building blocks for complex open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."
What is to be new about web service is that such services solve difficult problems of integration across different programming languages and middleware: any Internet-enabled application can be integrated with any other through the use of XML messaging. The vision for web services is that they will be exposed in public business registries describing their structure, requirements, business processes, and terms and conditions of use. Customers will understand their abilities and select them; because the services will be "smart," able to spontaneously invoke other web services that are necessary to accomplish their task in a customized way.
Thus, web services promise and portend a veritable virtual book of magical "Sorcerer's Secrets." Because a "process" is defined as "a systematic series of actions directed to some end," web services will automate business processes into combinable and re-combinable means-end building blocks. If such a metastrategy for victory over business processes succeeds, other worlds to conquer must surely follow.
What makes this promising possible future likely? All the major players, meaning Microsoft and the Java camp, agree on the standards that will establish simple web services, and the Java camp is working with standardizing bodies to establish a complete set of standards for complex business web services.
When better, cheaper, faster combines with standardization, together they unlock the hidden potential of markets. Remember: it is standardization that drive network effects, and network effects that drive tornadoes. And, it is the exponential power of Moore's law that has been driving the cost reductions that drive the economics of productivity.
Coleman believes that Microsoft is oriented down-market because, they seem focused exclusively on simple web services that can be shrink-wrapped as an off-the-shelf product requiring little hands-on service. Whereas, BEA is focused on both simple and a richer set of complex or business web services, and, moreover, will provide the service and support that are necessary for such a sea change in application development, deployment, and delivery over the Internet.
On BEA's web site, there is a foundational whitepaper, dated June 13, 2001 and entitled, "BEA WebLogic Integration." In its Table 1, Simple and Business Web Services are compared. WLS 6.1 offers simple web services now, making it not only the front-runner, but so far, the only product in the race to support WS. As yet, the value chain for web services is vestigial if not still a glimmer in its parents' eyes. Nonetheless, BEA's abilities in integration position it as my early favorite to become the first Web Broker to offer Business Web Services.
What are the differences between simple and business web services? Simple web services use XML and three primary standards: SOAP, UDDI, and WSDL; whereas business web services extend to include ebXML, plus XOCP, RosettaNet, cXML, , HTTP, and SSL, with other standards sure to follow as they are constructed and accepted by standardization bodies. Essentially, these facilities are protocols for how to conform or how to connect. What you most need to understand is that the simpler standards are useful but their functions are limited to simpler services, like requesting and receiving information. They permit point-to-point rather than multiparty communication and are limited to RPC and messaging without permitting collaboration or the use of workflow engines. Thus, simple services are not transactional or conversational, or personalized by collaborative agreements between parties. Finally, simple services are more limited in their Web security, using authentication and authorization but not non-repudiation or digital signature. Basically, simple web services handle simple business processes but not complex ones that bind time by involving multiple parties who are doing a deal: collaborating or negotiating or transacting conversationally through time.
Vawter and Roman promise and purport to provide an unbiased comparison of J2EE vs. Microsoft.Net approaches to building XML-based web services. Both J2EE and .NET are evolutions of application server technology developed for enterprise computing that are ramping up to become network-centric platforms for web services. The shared vision of both approaches is that the platforms will take care of the "plumbing." Developers, who draw on their specializations, can write application that run within a container that provides the tricky, heavy lifting behind-the-scenes.
J2EE is a standard, whereas .NET is a product strategy. The J2EE's camp's goal is to encourage a complete buy-in of standards and to let market competition choose the best-of-breed platform. (The sub rosa goal remains: to beat Microsoft.) Unfortunately, some proprietary stickiness remains in most (except for BEA) of the J2EE platforms. According to Vawter and Roman, however, .NET "is monopolism dressed in altruism. Microsoft been claiming that .NET is about open and inclusive web services, when in reality Microsoft is already making their web services closed and proprietary."
Based on their point-by-point comparison, they summarized a set of arguments that favor each camp.
Arguments for Microsft's .NET: (1) The A-team is marketing it; (2) Momentum from releasing their story of web services first; (3) A better story for shared context (because they are proprietary, they set up their single directory of one-time-and-done registration); (4) Awesome tool story with Visual Studio.NET; (5) Simpler programmer model (packaged, rather than developer differentiates features); (6) Language neutrality when developing new eBusiness applications; and (7) .NET is strongly interweaved with MSFT's underlying hardware server operating system.
Arguments for J2EE: (1) Being marketed by an entire industry; (2) A proven platform with few new APIs, whereas .NET introduces risks of first-generation technology (Bugs, anyone?); (3) Can deploy today (WLS 6.1 has.); (4) Existing J2EE code will translate into web services without rewrites; (5) .NET web services are not interoperable with current standards, the .NET framework (platform) has proprietary SOAP extensions and does not support ebXML; (6) More advanced programming model, permitting advanced object models and personalizing by well-trained developers; (7) Lets you take advantage of existing hardware, rather than forcing a move to MSFT-supported servers only; (8) Platform's neutrality isolates it from heterogeneous deployment environment, providing good portability (some slivers of proprietary advantage limit the Java ideal); (9) Better legacy integration through JCA; (10) Choice of any operating systems, Windows, UNIX, etc. while developing new applications; (11) Lets you use Java, which is better than C# (the MFTT look-alike) due to market-share and number of programmers. "According to Gartner, there are 2.5 million Java developers. IDC predicts 4 million by 2003. 78% [compared to 50%] of universities teach Java." (12) Only Java or C# should be used for mission-critical enterprise solutions; and (13) Most ISVs and SIs choose J2EE because they cannot control their customers' target platform, with J2EE beginning to dominate more and more as time goes on (showing network effects).
Vawter and Roman concluded that the advantages of J2EE architecture outweigh those of .NET. Although both will have market-share, customers stand to gain more benefits with J2EE, which, they conclude, is the preferred architecture.
Their final point is a decisive consideration. Compared to .NET, network effects will accrue to a J2EE because the value chain of programmers and system integrators cannot control the heterogeneity of customer's hardware and operating systems. (I believe, but have not verified, that the Java-camp's market share also larger now.) More reach and popularity tip the network effects toward Java. BEA's network effects will be driven exponentially by arithmetical increases in the number of WS applications, by increasing modular reusability and recombination, and by the dynamic conversational and collaborative richness that complex business web services will offer.
I believe that standardization drives network effects, and that BEA is currently ahead of Microsoft because of it is completely commetted to standardizing on all protocols that enable web sercice. The advantages listed above suggest that it may compete successfully in the enterprise market, particularly if Coleman is right and MSFT is positioning in a complementary soho mass market.
Not only does BEA have increasing network effects-specifically a comprehensive platform with many complementary applications under development that generate a cycle of increasing returns--but also a richer and more mature technology platform that is close to becoming a Service Broker, which is the ideal platform for web services. This concept was new to me until a week ago; but here is what I think I understand and may not.
In July 2001, Billy Newport published an article on the requirements of building industrial strength web services, called a Service Broker.
theserverside.com
Newport says that a service broker is a fundamentally new type of middleware platform that will be used to build real world enterprise-scale web services. By this, he means what BEA calls complex or business web services. A service broker is similar to a message broker, but is more flexible and integrated, providing a simplified interface to external systems. B2B integration is similar to the problem of integrating the ultimate suited of vertical applications, which Coleman calls "A2A."
A service broker is made up of seven components: (1) Business Process Manager; (2) Middleware Connectors; (3) Content-based Routing and Transformation for Messages; (4) Security Mapping; (5) Process State Management; (6) Connector Discovery Mechanism; and (7) Transaction Monitor.
Although not a technology expert, and looking for help here, WLS 6.1 comes close to having, at least, preliminary versions of these seven components. Although, BEA has advanced security, this security service may not be isolated into separate server architecture; at least, to my knowledge, there has been no separate product offering of a BEA Security Server. This is a crucial element. What's more, I do not know how closely BEA is followed by its competition, say, IBM or Sun, who also must value and use process managers since they share similar dreams. I need your help here, Thomas or others who know and understand more.
However, even if there were a security server, and BEA or Sun had all the components, the process of defining necessary standards is still incomplete. Complex business processes must be defined and broken into simpler business processes amenable to coding. Both clear and exacting analysis of business processes and the subsequent development of standardized protocols to guide their embodiment are necessary. Only then can skilled Java developers abstract these necessary processes as code that permits offering enterprise-strength web services.
Reliable and accurate simple elements can then be reused to model ever more complex processes. Business technologists, both software developers and business analysts, are building a future out of Java building blocks. Then, using the BEA Platform, enterprises can use the dynamic feedback of Business Process Manager to determine how accurate and successful their models are. This appealing promise of Web services--to enable integrated virtual e-business applications regardless of programming language and operating environment--beckons enticingly from the mist.
In conclusion, BEA has a strong value chain with accelerating network effects now. Also, BEA appears to be the technology-leader in nascent business webs services, and because humans are anticipatory creatures, its network effect is already beginning in a tornado of words driven by the winds of imagination. Although Microsoft is the prototypical gorilla, BEA may prove it has its own superior integration-with-process management-skills and weighty network effects to throw around in any gorilla clash in the new and future arena of web services. However, this battle will never even commence if the proprietary fever infects and overwhelms the immune systems of all of the cooperating players, who become so competitively eager to get "my" slice that they sacrifice portability, and with it, "the bigger, the better" network effects that could exponentially drive the size and value of their total market.
I hope this helps provide some background. If you are interested, I recommend reading the whitepapers directly so that you can filter out and correct any of my mistakes or misinterpretations. Also, the BEA integration whitepaper is the best summary of what BEA is doing that I have found.
Don |
