.Net Versus J2EE (Java) for CIOs: Strange Bedfellows

FOCAL POINT:The decision to select .Net or Java 2 Enterprise Edition (J2EE) is easy - both should be supported unless the IT organization (ITO) can standardize on Microsoft (MSFT). Because only the smallest ITOs will be able to exclusively use .Net as their application development and deployment platform, most must support both. Winning strategies will center on balancing each technology's unique qualities against development (e.g., skill, cost, time) and performance (e.g., reliability, availability, serviceability) constraints.

META Trend: During 2002/03, as business organizations focus on strategic partnerships and customer needs, IT organizations will (re)evaluate ROI strategies. As IT/business collaboration matures, organizations will incorporate more balanced performance investment approaches. By 2004/05, scenario planning will form the basis of balanced value/innovation programs that manage dynamic technology investments and enable organizational agility. By 2006/07, 25% of Global 2000 firms will dynamically assemble, restructure, and dissolve virtual teams on demand.

Not since the database wars (e.g., Oracle, Sybase, Informix) of the 1980s has there been such hype, countervailing claims, and ensuing confusion around emerging rival technology choices than has occurred between Microsoft's .Net and Sun Microsystems' Java application development and deployment technologies. MSFT uses the .Net moniker on all its software servers and tools to boost its adoption. Whether these technologies offer .Net support or even have anything to do with .Net is a separate issue. Java pundits have promoted features such as reliability, availability, and serviceability (RAS) and portability to boost J2EE adoption. The "open versus proprietary" argument underscores vendor orientation MSFT is the sole owner of and will make arbitrary changes to .Net’s direction. Java is predominantly controlled by Sun and is considered "open" because it enjoys broad support by leading IT infrastructure developers such as IBM and HP, as well as application suite vendors such as SAP and PeopleSoft.>.Net and J2EE are highly similar technology architectures for building multi-tier applications. There are standards and integrated development environments (IDEs) for building presentation layers as well as business and navigation logic components, and deployment platforms (e.g., application, integration, and Web servers) on which component behavior is specified and managed at runtime. MSFT’s .Net IDE is Visual Studio .Net. Numerous Java IDE providers exist, including Borland, Sun, Oracle, and HP, but the market is now circling around IBM’s WebSphere and BEA’s WebLogic.

The end game of either technology architecture is to speed the development of n-tier, distributed applications by minimizing the time spent building function logic and consuming previously developed, remotely located logic at runtime. However, in distributed scenarios, unless the developer is aware that such logic exists, the development process is problematic to complete. As a result, both technologies include XML-based facilities to facilitate the consumption of network-based logic, including the following:

• Location services that maintain registry lists of available services based on a standard called UDDI (Universal Description, Discovery, and Identification).
• Description services to describe how logic will behave, its runtime bindings details, and location via a standard format called WSDL (Web Services Description Language).
• Access services for logic discovery and linking based on a .Net- and J2EE-neutral XML RPC (remote procedure call) called Simple Object Access Protocol (SOAP). We note that SOAP traverses firewalls without robust infrastructure to manage access behind the firewall. Although this approach is attractive when initially working with business partners, it uses HTTP tunneling a potential security compromise. Security-conscious IT organizations should consider filtering/blocking HTTP tunneling, or they might as well open the native ports for the various protocols piggybacking on HTTP.

Because these services are essential for either architecture to be successful, both MSFT and the J2EE-based suppliers (e.g., IBM, BEA) are keenly interested in fully driving and supporting their evolution through maturity by 2005. This is a point when, for example, developers will rely on such services to locate and link to business logic that is self-describing, self-documenting, and largely self-configuring the end game of both strategies. These (binary) components of logic will replace, for example, MSFT’s executables and dynamic link libraries. Both technologies also support a runtime format (e.g., MSFT’s common language runtime [CLR]) that is hardware- and programming language-independent, enabling complete, seamless interoperability of software components, regardless of the language in which they were written.

As a result, this market will split into the following three factions:

• 20% of all enterprises will make an unconscious 100% commitment to .Net-based application development because the applications and services they buy are .Net-based
• 15% of this group making a conscious 100% commitment to .Net-only because they have the competencies and governance to do so
• The rest (and majority) of enterprises will support both technologies, similar to the approach that was taken when Visual Basic exploded in popularity as a lower-cost, easier alternative than COBOL and fourth-generation languages for client/server application development

The critical issue for most IT organizations regarding .Net and J2EE will be how to support both alternatives as evolving standards, such as Web services, play an expanding role in externalizing business functions to partners, employees, suppliers, and customers. Further, migration costs (e.g., VB 6 to .Net) must be considered. Successful approaches will justify all new and migration costs using drivers such as business value and use, cost, languages, deployment choices, performance controls, responsiveness, support for existing applications, integration, training, and staffing/resource utilization. There are compromises that users must consider during adoption of such technologies.

Because both .Net and J2EE were derived from the murky successes and broadly published failures surrounding the object models of the 1980s, these new designs are not yet broadly supported by standardized componentry. Either technology can be used to implement the other’s implementation blueprints. Performance benchmarks show insignificant advantages that good process, competence, and experience can offset. As a result, using typical criteria is problematic when making strategic decisions on organization, operations, policy, training, etc. CIOs have other criteria to consider in their .Net and J2EE strategies.

Continuing corporate focus on productivity and ROI will strengthen MSFT’s case of low cost and high productivity through 2003, and result in a growing number of .Net deployments. By 2004, we expect MSFT to have approximately 30% of the new enterprise application market, with Java stabilizing at roughly 40%, and the remainder split across other existing technologies (e.g., legacy, CORBA). This mix is a dramatic shift away from a pure-Java direction that we believe is being driven primarily by the much greater developer productivity within .Net environments, the quality of the overall frameworks, and the continuing need to integrate efficiently with client devices. Through 2005, the battle for n-tier platform share will drive continued integration of services (e.g., integration, portals, transactions) with application servers/operating systems supported by integrated development suites (e.g., Sun’s SunONE and IBM’s WebSphere suites).

By 2005, business executives will refine their predominantly economic-oriented (cost-reduction) IT investment justification models with a balanced-scorecard-type model (e.g., financial, business process, customer, employee). This change will improve valuation methods for .Net and Java. By 2006, the end game of IT business process integration will become the focus for IT suppliers. A three-way war will be waged among once mildly cooperative partners such as MSFT ("fat" operating system orientation and application "tools"), IBM (infrastructure orientation), and SAP (application suite orientation). Each will become fiercely competitive toward the other, weakening partnerships to minimize revenue sharing and redefine the concept of technology partnerships a change that will have a permanent impact on all IT suppliers.

Success with .Net and Java will not be found in technology comparison, but rather in the creation, operation, and management of a common infrastructure (e.g., skills, policy, process), including testing/quality assurance, promotion-to-production/change management, maintenance, and instrumentation. Just as was done with client/server development tools such as Oracle’s Developer/2000 and Sybase’s PowerBuilder, IT executives will need experienced, productive people to leverage their .Net and J2EE investment. These development platforms require integration with all post-development processes to ensure that application behavior is predictable and controllable. From a testing perspective, IT executives will need application and infrastructure impact analysis to ensure that existing service-level agreements can be met. Change management/promotion-to-production and maintenance processes (e.g., user interface, business logic, integration logic) will be needed, ensuring that existing IT investments are not blindly compromised. In addition, instrumentation of an application’s components (e.g., user interface, business logic, interaction logic, database access) will be necessary to map out performance hot spots and plan accordingly.

We believe client device support, cost, and greater productivity of the .Net approach will prompt its use for smaller, departmental, and user experience needs. Java’s lower productivity yet greater scalability, broad operating system support, and better ability to manage distributed complexity will drive it into back-end business logic management far more often than .Net ever will. The current state of maturity (or lack thereof) of both technologies is enough reason to avoid granular technical comparisons. Competition will ensure functional leapfrogging.

A binary approach to managing these technologies will be too often applied, preventing their optimal use. We believe high-performing IT executives will apply a balanced-scorecard approach to optimally structure .Net and Java impact by leveraging common infrastructure and cross-platform compilers or integration infrastructure. For example, many IT suppliers will support both .Net and Java (e.g., IBM, SAP, Oracle, HP, BEA Systems). Attention will center on core disciplines and processes (e.g., application development, infrastructure development, operations) and assets (e.g., hardware, software, people) that IT executives have made significant investments in, enabling more controlled, quality responses to future application or service demands. The goal is to smoothly integrate these development and runtime environments into the ITO’s business model as a means of improving responsiveness, cost predictability, skill forecasting, and overall IT value and business alignment. Otherwise, silo-type organizations will occur, introducing more management issues such as dissention among personnel, career development concerns, and political standoffs that will serve to destabilize an organization’s cohesiveness.

With the introduction of any new technology comes job security fears and career development opportunities. All developers do not work on all projects. More experienced (and typically higher-compensated) developers will want more challenging tasks and projects. Savvy development managers will have models to define what skills and technology will be used for typical functionality.

Even with management frameworks in place, IT executives should remain aware and respond to complicating factors that will influence success with both technologies. The vendor community will have challenges. MSFT has publicly stated its .Net commitment; however, because it is the sole .Net proprietor, IT personnel should remain focused on the availability and quality of newly delivered functionality. No application delivery commitments should be made on future MSFT technology, because MSFT has a reputation for mediocre quality and delayed delivery of new software releases. Thorough testing and application and infrastructure impact assessments prior to production use should be mandatory. Wholesale XML enabling of Visual Basic 6 and Active Server Pages (ASP) code for .Net consumption is expensive and risky. IT executives should justify and profile the risk of all changes to their application portfolio to drive this migration.

Market dynamics (e.g., diminished IT spending) will further drive the number of J2EE-compliant products (e.g., application server, integration server, and IDE) down to five market leaders (i.e., IBM, Sun, SAP, Oracle, and BEA) and a small quantity of niche players. Vendors will become more desperate for business, compromising the integrity of their product line for revenue gain. CIOs should maintain a reasonable understanding of two or three vendors’ products through vendor briefings, reference validation, and industry research firms.

Because application vendors choose their own brand of J2EE-compliant tools, IT executives should plan to support (e.g., development, operation, maintenance) multiple application server brands with a particular emphasis on skill needs (e.g., frequency of use, duration, level, experience). Sourcing may prove attractive in hard economic conditions when consultant supply is high, driving prices down. CIOs should use the .Net/J2EE balanced-scorecard management framework to gauge their needs.

Hardware platform/operating systems for development and deployment (e.g., application servers, integration servers, database servers, portals) will impact .Net and J2EE adoption. The leading Unix flavors (e.g., IBM’s AIX, Sun’s Solaris, HP’s HP-UX), Linux, z/OS (IBM mainframe), and OS/400 (AS/400) will support Java. Windows-based operating systems (e.g., Windows 2000, Windows XP) will be the only platforms to support .Net. To refine .Net or Java selection, IT executives should recognize and leverage the inherent RAS qualities as well as the scalability of these platforms.

Microsoft’s .Net is a collection of core technologies, languages, and models to build, integrate, and run XML-based Web services, MSFT-based applications, and other Web-based applications. Core technologies include the following:

• .Net enterprise servers:
  - BizTalk Server: Similar to a message broker; enables development and deployment of integrated business processes internal and external to the organization
  - Commerce Server: Development and operation of e-commerce functionality
  - Content Management Server: Development and deployment of content-driven Web sites, targeted and personalized by user profile and browsing device
  - Exchange 2000: Messaging and collaboration, including group scheduling, discussion groups, team folders, instant messaging, real-time data, and video conferencing
  - Host Integration Server 2000: Windows-based application access to other systems by providing application, data, and network integration
  - ISA (Internet Security and Acceleration) Server 2000: Internet connectivity via integration of an extensible, multilayer firewall and a scalable Web cache; builds on Windows 2000 security and directory for policy-based security, acceleration, and management
  - SharePoint Portal Server: MSFT’s portal
  - SQL Server 2000: Web-enabled database management system; similar to IBM’s DB2 and Oracle’s database servers
  - Windows 2000 Server: Derivation of MSFT’s Windows NT operating system, including directory, Web, application, file, communications, and print services
  
• .Net Framework: MSFT’s programming model for building, deploying, and running Web-based applications, smart-client applications, and XML Web services within the .Net environment
  
• .Net security: Role-based Web application security via MSFT’s Internet Information Server supporting common HTTP authentication schemes, including Basic, Digest, NTLM, Kerberos, and SSL/TLS client certificates, and evidence-based security (running of semitrusted code) services
  
• ASP .Net (formerly referred to as ASP+): Compiled Web development platform for providing the services necessary for developers to build Web applications
  
• Common language runtime: Runtime services, such as language integration, security enforcement, memory, process, and thread management; at development time, CLR facilitates life-cycle management, strong type naming, cross-language exception handling, and dynamic binding to reduce the amount of code that a developer must write to turn business logic into a reusable component
  
• Windows Forms: Programming framework for building Win32 applications
  
• Visual Studio .Net: Programming toolset for building and integrating XML Web services, Microsoft Windows-based applications, and Web solutions
  
• Visual FoxPro with .Net: .Net-enabled version of Visual FoxPro for consultant-developed, data-intensive, complex desktop and workgroup applications

Languages include the following:

• JScript: Flow/process/navigation control of application code
  
• Visual Basic .Net: Object-oriented constructs to enable more componentized, reusable code, including implementation inheritance, encapsulation, and polymorphism; organizations can enhance VB 6 code with .Net features, or use MSFT’s COM interoperability to integrate .Net and non-.Net application code
  
• Visual C# (pronounced "C sharp"): Similar design goal to that of Java, but different in perspective (e.g., C# is a language, Java is a platform); C# is a derivative of C and C++ that simplifies many issues with these languages (e.g., memory management, language syntax)
  
• Visual C++ .Net: For highest-performing applications within .Net
  
• Visual J# .Net (pronounced "J sharp"): Java developers can continue developing code using a familiar syntax from within .Net

J2EE technology architecture includes the following:

• J2EE application model: Architecture for implementing services as multi-tier applications (including partitioning of business and presentation logic from underlying services) and for delivering required scalability, accessibility, and manageability; the application model also includes the JavaBeans component model to simplify the componentization of Java technology-based code for common reusable functions
  
• Enterprise JavaBeans (EJB): In the J2EE platform, middle-tier business functions are implemented as EJB components; this construct enables service developers to concentrate on business logic and enable the EJB server handle the complexities of delivering a reliable, scalable service
  
• JavaServer Pages (JSP) technology and servlets: Present middle-tier functions to the client tier as simple-to-access Internet-style services; JSP technology is intended to simplify the presentation of dynamically generated pages to a browser servlets enable implementation of dynamic presentations completely in the Java programming language

The following are standard Java service APIs for basic access to these systems:

• JDBC (Java Database Connectivity): The standard API for accessing relational data from Java
  
• JNDI (Java Naming and Directory Interface): The standard API for accessing information in enterprise name and directory services
  
• JMS (Java Messaging Service): The standard API for sending and receiving messages via enterprise messaging systems such as IBM MQSeries and Tibco Rendezvous
  
• JavaMail: The standard API for sending e-mail
  
• Java IDL: The standard API for calling CORBA services

The J2EE platform includes the following elements:

• J2EE deployment specification: A standard that defines a common way of packaging applications for deployment on any J2EE-compliant platform
  
• Java technology standards for the J2EE platform: Standards that all J2EE platform products must support
  
• IETF standards for the J2EE platform: Standards defined by the Internet Engineering Task Force that all J2EE-compliant products must support
  
• CORBA standards for the J2EE platform: CORBA standards on which the J2EE platform bases its middle-tier interoperability

A J2EE application is packaged into one or more standard units for deployment to any J2EE platform-compliant system. Each unit contains a functional component or components (e.g., enterprise bean, JSP page, servlet, applet), a standard deployment descriptor that describes its content, and J2EE declarations previously specified by the application developer and assembler.

Once a J2EE unit has been produced, it is ready to be deployed to a J2EE platform. Deployment typically involves using a platform’s deployment tool to identify location-specific information, such as a list of local users that can access it and the name of the local database. Once deployed on the local platform, the application is ready to run.

J2EE and .Net are attempts to take complexity out of building and deploying network-based applications (e.g., user interface and device differences, database access, transaction management, business and process logic) by creating reusable, controllable infrastructure components. J2EE is well defined and openly discussed among leading IT suppliers. .Net is also broadly discussed and will catch up to J2EE as MSFT is forced to deliver on its own marketing hype. We expect to continue seeing large, scalable, reliable applications built using both Microsoft and Java technology. The key success factor continues to be in the maturity of the application architecture, design, development, operation, and maintenance processes, not in the underlying technologies. Although .Net products in particular will be delivered over a relatively long period of time, it is the future application development standard for MSFT-oriented IT organizations, and the way in which MSFT will deploy subscription services and updates.

CIOs in medium and large IT organizations will deploy both .Net and J2EE as a hedge against relying on only one integrated development environment toolset, judiciously ensuring that the appropriate environment is used for a given application. As previously discussed, .Net has quicker implementation timetables, but does not scale or provide sophisticated security disciplines. Although development takes somewhat longer in J2EE, it scales well and promotes good application and infrastructure management discipline.

Business Impact:Next-generation application development and deployment options such as .Net and J2EE will become critical success drivers to managing increasingly demanding performance constraints (e.g., speed, quality, cost) placed on IT executives by their business peers.

Bottom Line:Unless an organization is completely Windows-only, IT executives should have an adoption plan to support both .Net and J2EE -- realizing that optimal value in these technologies will be found through assessing the economic, efficiency, effectiveness, and empowerment benefits that such technologies offer.

META Group originally published this article on 1 November 2002