.NET and J2EE: The Architecture War Heats Up

October 1, 2003 Comments
Print
As companies prepare their CRM, ERP, billing and OSS architectures for next-generation Web services, they want to ensure all are compatible with one another. Legacy applications and first-generation billers were purpose-built, so they were not open; however, with Web services, carriers will want an environment that is open and that enables different components of their architectures to work smoothly together.

.NET’s XML and Web services capabilities seem to be its strengths; however, its maturity and ability to integrate with other solutions is still at question. Conversely, J2EE offers multi-platform support, yet ease-of-use has been said to lag that of .NET.

“There are myths that need to be eradicated so decisions can be made based on fact,” says Forrester analyst Ted Schadler, who notes that developers no longer have to be Java gurus to work with J2EE, nor should security issues around the .NET operating system be as serious as in the past.

To dispel the myths, Forrester recently released a report that constructs a strategy for dissecting enterprises into application domains to assist in determining which layers can benefit from J2EE and which from .NET.

“Most larger organizations have six to eight domains,” which Schadler notes can be broken out by Web site, security infrastructure, ERP systems and intranet portals that feed applications with information for knowledge workers. “Domains are ‘persistent,’ so they have a history and a future on which platform decisions can be based,” he adds.

Gartner predicts that both platforms will garner roughly equal market shares during the next five years, as both are competitive in terms of Web interfaces, Web services and XML support, according to Gartner analyst, Mark Driver, who co-authored “Harnessing the Power of Web Services and Middleware: Building and Deploying Integrated Applications for the Agile Enterprise.” Driver believes .NET and J2EE will command 80 percent or more of new e-business application development initiatives.

According to most industry experts small and mid-size businesses will turn to .NET, as consolidation of back-office data centers and client platforms around Windows server platforms will be a precursor to .NET migration. (For more on how a carrier views the technologies and how it will integrate them into its network, see “Verizon: Manageability Will Determine the Success of J2EE and .NET”).

“Microsoft currently is gaining market share in data centers,” according to Steve Zielenski, vice president of strategic solutions for Portal Software, which announced that its Billing Agility product will be based on the .NET platform—spawned from an agreement to jointly invest marketing dollars and engineering with Microsoft. Portal is banking on the fact that billing in Web services will require a lot of hardware, and most of Siebel’s and SAP’s sales come from Microsoft platforms. “We expect Microsoft will experience huge market share gains because of total cost of ownership; they will simply be able to offer more with less,” says Zielenski.

Portal is not the only billing vendor swearing by .NET for carriers’ legacy migrations. “As an organization with Unix expertise, and as a reseller of Solaris systems, it would seem we would push for J2EE, but we find J2EE to be very challenging in terms of migrations because of bandwidth capability issues,” says Don Tiedeman, vice president of services for Fujitsu, whose consulting services focus on telecom billing. While he believes both frameworks have well-defined APIs for providing interoperability, he likes the notion of commodity components and rapid uptake of technology. In fact, Fujitsu just completed a conversion of a mainframe system, which was costing $720,000 per year for equipment and applications. According to Dave Flawn, vice president of legacy migration at Fujitsu, “going to $20,000 worth of Intel computers in a cluster environment is now doing the same work.”

These supporters note that .NET is a significant departure from its legacy VisualBasic and C++ environments, as its C-Sharp language will phase out the other two in the next few years.

“We have been dabbling with C-Sharp in WAP development with our product,” says Don Culeton president and CEO of Info Directions, which is working to enable Web-based front ends for agent access and centralize business logic for easy distribution and access to billing, CRM and other systems from anywhere on the Internet.

For Info Directions, .NET’s common language runtime library provides capabilities on which C-Sharp applications communicate seamlessly over the Internet. Microsoft’s common language runtime allows companies to compile up to 27 languages (including Assembler), as well as run on MS runtime “It’s nearly impossible to build enterprise applications on a browser because of all the technologies you have to deal with, whether AFP, COM, JavaScript and then the browser itself,” adds Derrick VanGrol, vice president of marketing and sales for Info Directions, which 18 months ago became one of the first .NET-based billers when it ported its entire product to .NET. “Scalability, reliability and ease of development become issues as a result of working with too many variables in the J2EE environment,” adds Culeton.

He agrees with critics who say that Sun’s focus on infrastructure has created many different flavors and extensions of J2EE. For example, IBM’s flavor of J2EE takes some work to integrate with BEA’s J2EE.

“By working with just the C-Sharp business objects, we serialize objects that are transported and reassembled on clients on either side of the Internet, which makes development much easier for us,” says VanGrol.

Despite those billing vendors that are currently supporting .NET, it is expected that just as many will support J2EE. Microsoft is not known to be as legacy-friendly as J2EE. “Because compiling on one language and compiling on other runtimes means the features are not there; Microsoft doesn’t have the same support for legacy applications,” says Stephen O’Grady, an analyst with RedMonk.

For legacy environments, J2EE offers open source toolkits (Eclipse, for example, which handles COBOL and Assembler code). Those have lots of supporters, including Hewlett-Packard, Borland and Oracle. Short of ripping everything out, Eclipse is a path many companies take. While it’s not necessarily easy, companies can take applications coded in COBOL or Assembler and plug them into their overall R&D.

“While .NET environments are supposed to ‘link into’ other environments through Web services, ‘linking into’ means building new Windows-based applications that hook into Web services technology, such as a Unix applications,” says Stefan Van Overtveldt, director of WebSphere Marketing at IBM Software. To do so, he contends, requires that companies leverage existing investment in hardware, software and all operational processes built around them. “Because our mission is to offer an application server, portal and pervasive product suite to support all devices in a variety of applications, as well as the complete set of development tools and partner ecosystem that goes with it, WebSphere is based on J2EE.” He says it enables Web services applications to be accessed from any device—cell phone, kiosk, PDA, car computer, and so on.

Because Windows requires developers to ostensibly build from scratch, it might not be viable for companies that rely on the availability and back-up capabilities of mainframes. “For them, it takes less time to take a legacy billing system or mainframe application and directly turn it into a Web service,” contends Van Overtveldt.

J2EE is expected to capture most of the larger enterprises, where data centers are comprised of mainframes and AS/400s, as well as Unix and Win32 systems. This will require support of heterogeneous environments and scalability not yet prevalent with .NET. The emergence of Java on mobile and wireless devices will add synergy to J2EE as well. “Those who use Unix will move to Linux, and are expected to choose J2EE to develop applications, as it leverages the Linux platform—popular for its ease of management in remote environments,” says Van Overtveldt.

While it’s tough to compare overall sales in the mobile space between .NET and J2EE, “There are more competitors in the J2EE realm, such as IBM and Borland, Oracle and Sun’s tools, than with .NET,” according to O’Grady.

While Microsoft has a good offering for the enterprise market for handhelds, the consumer handheld mobile phone market is becoming a Java playground, according to O’Grady. “Indeed, Sun pushed Java out of the gates quickly and leads in mindshare and development because of its vendor and communities that support it.”

During the JavaOne conference in June, Sun focused on branding Java as a consumer technology under the guise of application development for mobile phones. That will be important, as Vodafone and other carriers continue to make money online with handheld customers enjoying football, adventure games, and so on over mobile networks. “The mobile space is poised to explode as devices are becoming capable of interesting things; it will be an interesting market for both IBM and Microsoft to go after new developers,” says O’Grady.

While most agree that Microsoft’s Visual Studio sets the bar in enterprise development of mobile applications, the rich, functional applications are difficult to read on small devices like phones. Ubiquity is more plausible with Java, as all operating systems and most devices support it.

That will be important for many telecom companies focusing on putting intelligence into wireless networks. “Some believe Linux will beat out Windows installations when overhead costs on remote systems are a factor,” says Van Overtveldt.

Mobile applications aside, there is no question application development around Win32/COM applications will facilitate a considerable migration to the .NET framework. Even Scott McNeely, chairman, president and CEO of Sun, has said it’s not important who is first to market, but who is first to market with volume.

The meaningful differences between the two environments will come down to cost, tools, performance, scalability, integration and security.

Cost

While Microsoft claims it is less expensive because it runs on Intel and has cheaper licensing as well as a bigger pool of programmers, Java has more enterprise tools vendors and applications and much more venture capital behind it.

But J2EE is not synonymous with Java. From a service provider standpoint, J2EE is a new infrastructure; it’s the familiarity with Java that sometimes confuses audiences. There are major differences between the Java language and the J2EE descriptive architecture.

.NET supporters claim they get Unix performance at half the cost. “.NET will enable companies to reduce the hardware and infrastructure costs around databases, underlying operating systems, connectivity and supporting software,” says Portal’s Zielinski, citing tests run at a European GSM operator with 15 million subscribers. He concedes the test showed negligible results in terms of performance between .NET and J2EE, but a 50- to 90-percent savings in terms of integration for Web self-care and internal desktop applications. However, those numbers were built around utilization of Portal’s CRM partnership with Siebel.

J2EE supporters warn that such claims around cost savings should be taken lightly, as performance and scalability issues should also be considered. “Microsoft has in the past compared newer .NET benchmarks around their common runtime environment with old performance numbers from Java Virtual Machine,” says Sun Microsystems’ Glen Martin, product line manager for J2EE. He says companies should make apples-to-apples comparisons using the most recent performance numbers from J2EE 1.4.2 on Linux and Solaris, as opposed to numbers that are six years old from JVM.

“Cost savings are significant for companies that don’t need scale and want simple applications, however, they must consider that Windows systems don’t scale beyond eight processors, while Sun’s run on 100 processors or more,” says Sun’s Ralph Galantine, group marketing manager for Java technologies.

While mainframes and Unix systems cost thousands or hundreds of thousands of dollars, J2EE’s talent for handling significant workloads has thus far lured the likes of eBay and Charles Schwab’s online trading Web site. With millions of transactions handled every day, it may be attractive for carriers and service providers supporting high volumes of transactions and subscribers, monthly billing statements or cell phone Web services.

However, Microsoft works with customers like HP (whose Wi-Fi service is launching with a South African telecom), BroadWing, Qwest and T-Mobile as examples of Tier 1’s using .NET toolsets and runtimes. He notes that Verizon took less than 9 months to connect with its back-end infrastructure using .NET.

Immaturity?

To work with these larger players, Microsoft will have to address challenges around .NET that stem from its “immaturity” with new runtime, development and security, as well as lack of integration into Microsoft’s Office and other established product lines.

In terms of immaturity, Andy Chu, global market strategist in Microsoft’s Communications and Mobile Solutions unit, notes that .NET has been around for years and that its strategy has become much “broader” than that of J2EE. “It encompasses the developers, infrastructure builders and end users,” he says. Because of the ubiquity of its desktop presence, he says Microsoft is set to help bridge the gap between service provider-type services and end users. “It’s an end-to-end picture that ties end users to OSS and BSS infrastructure.”

However, that end-to-end picture is a result of the fact that the entire .NET environment is tied to Windows. While its proprietary technologies (such as VisualBasic, COM and Microsoft Transaction Server) are pervasive, many strategists want to avoid being cornered into using proprietary solutions in evolving Web services strategies because of security and integration issues.

Security

Despite Microsoft’s relatively recent promulgation of “trustworthy computing,” some believe there is a “fundamental failure” due to the fact security is an add-on with .NET. That means Windows bugs affect it, even with ad hoc security from enhancement packages.

Because J2EE’s security was built into its environment from the first line of code, with Tivoli, Entrust and Netegrity cooperating into J2EE efforts, security continues to be a sore spot in the Microsoft sales pitch.

That might change, admittedly, as most experts agree that Windows Server 2003 is a secure operating system. In fact, Windows Server 2003 reportedly has a higher security certification than Linux. “Traditionally, Unix shops are more familiar with security requirements than their Windows brethren,” says RedMonk’s O’Grady, yet he agrees that Microsoft is catching up as an enterprise operating system. “They are proving themselves as an enterprise OS, but Windows will have to prove itself in security realms before it’s no longer considered risky,” he adds. Indeed, Windows security continues to be stigmatized because of the desktop, especially in light of the recent Blaster worm.

Because .NET gives developers and users the option to work in “safe mode” or “unsafe mode” for source code, there are concerns that opening up access to anything written in unsafe mode (C++) opens up the entire framework to viruses. About 98 percent of viruses stem from buffer overruns that make programs execute incorrectly and overwrite the program code itself. Unlike C++-based languages, J2EE doesn’t permit that type of error, as application programmers don’t create buffers, thus eradicating an entire class of programming errors and catastrophic viruses. “One piece of unsafe code makes the entire system unsafe,” says Galantine.

The bottom line is that companies will have to balance ease of use and time to market with security concerns. Chu says that security compromises are attributable to the fact that Windows-based systems generally have not been treated with the same reverence as mainframes and legacy systems. “You have to apply the same discipline to Windows-based technologies,” warns Chu. “J2EE, Linux and Unix are all subject to the same risks; it’s an operational integrity issue. You don’t drop NIC cards into a mainframe; there need to be centralized security controls in place.” Microsoft has bolstered its Security Response Center to help customers identify and fix security issues expeditiously, as well as learn how to be more stringent with security protocols in developing applications.

While .NET introduces a number of new features, developers must consider at what cost. “There will be considerable discontinuity, which will create a significant learning curve for developers,” says Driver, noting that most developers can expect a learning curve to proficiency to last from three to nine months, although, that timeline can be as long as 12 to 15 months for some (such as COBOL developers). However, despite those considerations, it’s difficult to gauge learning times effectively, as there are many variables that affect training times, including framework, runtime, languages and infrastructure.

Ease of Integration

Telecommunications, by default, is a heterogeneous environment with many operating systems. Openness and integration are therefore of paramount importance. An integrated business portfolio is necessary when multiple OSSs and BSSs are affected from the basic linkage of data exchange all the way up to full business process integration. Without integration, something as simple as employing an address correction can become complicated. The IT organization has to be able to drive changes in the process from top to bottom through GUIs. For example, implementing an address change with an automatic update and population process requires that developers accommodate differences in how systems are implemented. One billing system may have the first record as the first name and the second record as the last name, yet another system may have those fields reversed. Companies have to be able to recognize those differences and map them out in an integration strategy.

Developers want to do this without having to adjust their applications to differences among devices, as they ultimately will tailor information to users’ devices. A cell phone GUI will present data differently than a PC or kiosk.

One of Microsoft’s biggest selling points is its claims to integrate, and thus move to market with new services faster. The claim that .NET is deeply integrated into Windows because there is one big mass of code does not necessarily mean it’s an advantage.

Microsoft has attempted to answer that criticism with its shared-source initiative.

While it has impressed some, it has left others cynical. Microsoft has submitted approximately 40 percent of .NET’s APIs and specs to the European Computer Manufacturers Association (the standard organization that also controls JavaScript Web scripting language), but many complain they are lower-level APIs. “That enables them to retain proprietary control over the higher-level elements of the platform,” says Gartner’s Driver in his report.

“Theirs is more of a ‘lead vendor’ approach, where they implement something and partners coalesce around it; it’s not a process to ensure interoperability among vendors,” says Martin, noting that the Java process includes reference implementations and compatibility tests. “Without implementation models and compatibility tests, you cannot weed out vagueness.”

As a result, a common complaint is that .NET is difficult to integrate to systems running on other operating systems, whether Unix, Linux or mainframes.

“We understand that people can’t just phase out existing legacy infrastructure or wrappers around legacy infrastructure; our platform has to be part of the overall infrastructure,” says Chu.

Because mobility, integration, security, performance and scalability all hold different meanings to different organizations, it is impossible to say .NET or J2EE is “superior” in an all-encompassing manner. Each has its advantages and disadvantages, depending on the area that is most important to Web services strategies. Openness and integration among different facets of carriers’ architectures, as well as integration among OSSs and BSSs, will be factors to consider in evaluating both technologies.

Verizon. Manageability Will Determine the Success of J2EE and .NET

While most of the heated debates around .NET and J2EE focus on security, scalability and ease of integration, there is one variable around which all the others depend: manageability.

We got an opportunity to speak to Shadman Zafar, senior vice president, IT architecture and E-Services for Verizon about the importance of the oft-forgotten, but ever-present issue of managing growing Web services development platforms. Currently, Verizon is evaluating how Web services can enable integration of applications and published services, as well as ease project development.

Q: What should be the single-most important factor to consider when looking at platforms like J2EE and .NET?

A: Initially, when people think about architecting platforms, they don’t think about the mess they can potentially make of their data centers. They don’t think of the cooling problems, the tangle of chords and the myriads of extra power outlets. Rather, they think solely of the price-to-performance ratios. However, a strategy for managing the platform as Web services grow will make or break you. Manageability will determine the success of J2EE or .NET.

Regardless of the cost savings initially reaped, manageability will come to the forefront. You could use 100 machines to support 1 million customers or half a machine—depending on the tools the platform provides sometimes it is cheaper to support 100 machines than half a machine.

Q: Why is manageability such an issue in enterprise deployments of Web services?

A: The goal in using Web services in the enterprise sector is to reduce the costs associated with duplicated development efforts and over time reduce the software defects. When you get to the point of offering published services, account summary checks or bill disputes online via a PC or handheld, you want the holy grail of balancing ease of development and quick time to market with tight security, ease of administration, and ultimately ease of use for the end users.

Initially, some development teams built the service and others started to use it. The experience to date has been so far so good, but as with anything that brings benefit, we try to get more of it. In the enterprise world, that means hundreds or even thousands of services are being built to be utilized by other development projects within and outside the enterprise.

At this point, managing SLAs for the Web service (performance, reliability and capacity planning) becomes crucial. For example, a bill payment service can take 10 seconds to respond without causing any problems for the customer. However, if it takes 10 seconds for a call center representative who is under severe timing constraints from the quality department, it is not a usable service. Similarly, a wireless user checking for the status of an order may not have high reliability requirements, but an E911 look-up that checks on a change of address requires a flawless reliability.

Q: What can you do to ensure manageability?

A: Internally, we have developed a Web services management model to work with both the J2EE and .NET frameworks. Currently we are sharing our approach with industry leaders like BEA, Microsoft and IBM regarding management and deployment of Web Services in the enterprise environment. While both .NET and J2EE are actively moving towards enterprise-class Web services management models, neither camp has completely reached a final answer.

My personal experience on the management side is that J2EE is developing a little faster on management within the data center side. However, .NET has better development tools and faster development cycles, hence the developer community sees tremendous appeal for .NET, whereas the operations community pushes for J2EE because of the management tools.

Q: Some of the complaints around .NET still revolve around security, integration and scalability, while J2EE lags far behind on the front-end GUIs. Who is closing the gap faster?

A: I had two teams recently building similar applications on two different platforms. The .NET team had more than 300 off-the-shelf gadgets with which to work, while the front-end on the J2EE team offered only two—both of which were pretty bad. The team had to expend time and energy to make a third option. However, while .NET development went faster, in my architectural and security checks later, I found the J2EE team was clean, while I had to spend a lot of time with the .NET administration.

As for who is trying harder, I see .NET coming much farther with security than J2EE with the front end. I think both environments will succeed, and after all that is the promise of Web services that different environments can co-exist with little cost of integration. However, I see that front-end applications continue to be built in .NET due to large groups of ISVs developing front-end controls for .NET environment, whereas .NET continues to struggle in fighting the battle on the server and data center, especially in the security area.

In general you will find most people feeling comfortable with J2EE sitting on the back-end database servers, whereas .NET is inching its way through Web servers to applications servers and going towards database servers.

Q: What about the contention that J2EE “owns” the mobile computing space for development?

When devices don’t need high resolution or high fidelity or a highly pleasing experience—such as cell phones—then yes, J2EE, or J2ME, is good. But when you go above 160 or 240 resolution, then it tips the other way toward .NET. You hit a critical point where you have to measure strong security against graphics and usability. But, when you want to tip to the other direction, you have to be careful things don’t get messy; going from one architecture to the other takes a lot of energy. It doesn’t happen sometimes because enough business logic and investment goes into the software that migrating becomes a big program in and of itself.

Obviously there is nothing in one platform that cannot be done in the other. One requires more effort on security and manageability and the other requires more effort on front-end development.

The Microsoft gene pool is all about the front-end first; therefore, they have thousands of ISVs that develop to their platforms, and all of them look at the front end first. Conversely, Sun and J2EE supporters like IBM think of the back-end and servers, so security and manageability of the data center are their concerns, and those of their ISVs.

There is industry momentum, but then internal momentum to consider. Development teams grow with the success of each application; sometimes success can move you in the wrong direction, as internal momentum can dictate what architecture you go with.

Comments