The Economics of Components (II): Java-Based Development

ComputerWire

Issue Date: 08/01/2000
Issue Number: 11.3
Category: COMPONENTS

As with most new technologies, broad adoption and acceptance means that a number of elements must fall into place. The technological pieces have to be in place, vendor participation should be fairly robust, the promise of standards have to have some teeth, and IT departments have to see the economic benefits of change. And even if all these pieces come together, there is one make-or-break remaining prerequisite: developers must buy into an approach that requires a change in culture.

Has anything changed since our research of last year? In this report, we focus on organizations working with Java technology to see if CBD has begun to establish roots, and whether development organizations are starting to reap the benefits of reuse.

FACING THE MUSIC

The strongest driver motivating IT departments towards adopting CBD practices is time to market. Although always important for new application development, the emergence of e-business has ratcheted up the stakes in getting new applications out quickly.

A key driver: applications, which traditionally were utilities to automate internal processes supporting revenue centers, are themselves becoming the revenue centers. Before, a manufacturer could produce materials regardless of whether they had an ERP system; the same company today could not sell its materials on the internet or participate in a B2B trading exchange without the applications. More importantly, customer decisions on whether to patronize an e-commerce site may be driven, not only by the product or service, but by the ease of use of the e-commerce application or trading environment. The result: when done right, application development becomes a new profit center.

A little over a year ago, we looked at the economics of components and reuse. At that time, we concluded that the benefits of components and reuse remained debatable, based on information provided by more than half-a-dozen organizations developing applications using components. It wasn't for lack of incentive: the e-business vision then was considered a powerful motivator. Today, with B2B exchanges rapidly springing up, however, e-business for many organizations is starting to translate from vision to reality.

While building applications from scratch, using traditional procedural-based application development methods, may afford companies with tailored, customized solutions, there's a hefty price tag to pay for such a luxury-high cost and lengthy development cycles. Few companies can afford either. Additionally, programmer shortages plague the entire industry which further slows down the development process.

Although packaged solutions covering relatively generic operational functions such as financials, accounting, order management, inventory (more recently joined by customer-facing processes such as contact management, pricing, order histories, support management, etc.) became popular alternatives to custom development, for many organizations, they didn't provide the entire business solution or help a company adequately differentiate itself.

For these reasons, the industry has recognized that the time was ripe for more effective, rapidly productive development approaches. The rapid application development techniques (RAD) of the client/server years opened the way to approaches that encouraged fast prototyping and experimentation. That was fine for developing more effective front ends to data-driven transaction or decision support applications. However, fast prototyping of GUI-based programs was not a substitute for an effective means of building core enterprise business logic.

That's where object-oriented analysis, design, and development approaches entered the picture. With OO approaches, functionality could be developed from a business, rather than a data-driven standpoint.

However, it would be difficult to develop large applications using raw objects alone, which could be as narrowly-defined as "customer" or "business site." Components provided a way of compounding related objects together to get larger, more meaningful code modules covering items such as "customer order" or "site utilization."
Market research firm The Standish Group recently studied 60 enterprises which successfully built applications using object-oriented development. According to their research, CBD became a necessity when using OOAD (object-oriented application development) approaches. "IS departments are under tremendous pressure to get applications out fast," said Karen Boucher, executive vice president at Standish, who authored the report. She added that component-based development is now a means towards an end.

Boucher added that it was significant that her study could locate 60 organizations engaged in CBD. According to her, two years ago, that wouldn't have been possible.
Although C++ has a longer history as an object-oriented language, the difficulty of use presented a significant hurdle to OOAD. Over the past 12 - 24 months, Java has emerged as a kinder and gentler alternative, by automating or eliminating the rough edges of C++, such as the need to deal with memory management (including garbage collection and pointers). In response, Microsoft has recently announced C# (see sidebar).

C#: Microsoft's New Player on the Block Although Microsoft licensed Java over three years ago, it has fallen casualty to the escalating Sun/Microsoft legal and mindshare battles. The latest blow: Microsoft's omission of its Visual J++ tool from Visual Studio.NET, the company's upcoming release in of its flagship development tool suite. Yet. Omitting Java left a gap in Microsoft's arsenal, which included Visual Basic (VB), its simple 4GL; C, a well-established 3GL; and C++, a complex adaptation of C with object-oriented support. The gap was for an object-oriented language free of C++'s complexities. In June, Microsft unveiled its long awaited answer: C#. Although Microsoft claims it's not an answer to Java, consider the facts: It has simplified C++ by eliminating had-to-manage features such as multiple inheritance, and it provides a way to avoid C++'s memory pointers. In other ways, C# continues Microsoft's design philosophy, which packs features and leverages native APIs. For instance: * Pointers: These features claim chunks of memory for executing processes. The hazard: If memory is not relinquished, it can eventually crash the system and leave it exposed to security breaches. While Java eliminates pointers by automatically allocating and relinquishing memory, C# lets you have it both ways. You can let it manage pointers automatically, or you can manually write pointers into the code. * Security: While Java does not allow applications to allocate memory fore themselves, C# compensates for potential security exposures through an "evidence-based" security model that looks for destructive behavior. * Native Execution: While Java uses a "virtual machine" architecture to insulate it from platform differences, Microsoft's C# runs natively to take full advantage of its performance advantages. It comes at the price of having to continue porting applicaitons. XML: C# allows developers to attach XML schema as classes. Java currently lacks direct XML support.

Consequently, two and a half major component architectures have emerged. For Microsoft platform applications, COM+ has become the predominant architecture. It rivaled CORBA, which was the multi-platform alternative. With Java, Enterprise Java Beans have recently emerged, providing a Java-based architecture that is compatible with some CORBA technologies.

RISKS

Technology Chase. In the Java environment, the standards were until recently a fast-moving target, making it difficult for development groups to keep pace. Some standards, such as interfaces to wireless and XML, and container-managed persistence (an automated form of mapping EJBs to relational data structures) have yet to be fleshed out. However, with Java 2, Sun has finally lengthened the rev cycles to allow development groups to grow more comfortable with the spec.
Note: Although this report focused on Java, our sources indicated that on the Microsoft side, COM (on the front end) and COM+ (for the back end) were evolving at a similar torrid pace. And as we noted in the sidebar. Microsoft has just introduced another new variable into the race: C#.

Risks of Third-Party Components. Ideally, by using component-based development approaches that adhere to standards, IT groups can mix and match internally-developed components with those purchased on the open market. Given the youth of this market, off-the-shelf components may not always be available for the desired functions, making internal (or outsourced) development the only issue. If off-the-shelf components are available, the next issue is compatibility. For EJBs, there are two elements to this issue:

* Component interoperability. Theoretically, with Java 2, Sun's standards have grown reasonably comprehensive, but whether third-party component providers yet adhere to the spec may be another story. Moral of the story: check which version of the spec the component complies with, and test and test and test. (We'll follow up with a report on web application testing in the September issue.)

* EJB Appserver interoperability. The J2EE standard supposedly standardizes most basic functions. However, every vendor has different approaches to functions such as failover or load balancing. A developer of a high-end, securities industry web site that is heavily reliant on EJBs believes that component portability from one appserver to another is certainly doable, as long as "superclasses" containing vendor-specific settings are superimposed around core Java functionality.

Analysis Paralysis. CBD requires extra upfront analysis and design effort to create robust component architectures and engineer functionality for reuse. Is it possible to do too much of a good thing? Battle-scarred veterans of the upper CASE days of the late 1980s may recall endless analysis sessions which generated code modules that fell into disuse when businesses changed.

Few if any development groups track time by task or phase (e.g., analysis, development, testing, deployment, etc.), and in all likelihood, they shouldn't waste precious resources doing so. Therefore, it's hard to tell if a development team spent too much time doing analysis. The only useful metric is to judge whether the project met its deadlines.

Because most development shops do not track their time by task, the only way to judge if they are overdoing the analysis is to check whether projects have missed their deadlines. And, of course, the only way to know how much reuse happened is to look back several years after the projects are done to see if the same components have shown up again in new applications.

SHOPPING FOR COMPONENTS

Since the days of the Visual Basic Controls (VBXes), an aftermarket of third-party components has emerged. In most cases, these components consist of GUI controls rather than full-functioned business logic. In the Java world, several on-line sources have emerged, ComponentSource.com (http://www.componentsource.com) and Flashline.com (http://www.flashline.com).

According to Andrew King, vice president of market development at ComponentSource, the company offers over 3000 components in its catalog. The bulk of products are COM components (2700) and the rest are Java components.

Flashline's offerings include JavaBeans, Enterprise Java Beans, and COM, components, the lion's share, approximately 600, of which are Java components, according to company president and CEO, Charles Stack. They have also just released a component manager add-in tool for an IDE (integrated development environment) which integrates CBD with programming. At Flashline, the EJB market is still in its infancy, with roughly a dozen third parties (offering about 20 individual EJBs each) having developed EJBs for sale.

The marketplaces are just one avenue for getting components; befitting this immature market, word-of-mouth still plays a large role as an information source on what third party components available and what's useful.

IT managers in this position are constantly dealing with a still young and nascent marketplace and the instability of pricing models, compliance with industry standards and product strength. No surprisingly, many have mixed feelings about purchasing third-party components. Naturally, as with any purchased software products, there are concerns about vendor viability. Mostly what the industry is dealing with at this point is a comfort level, with concerns such as:

* Who provides a guaranty of service?

* Is there a return policy?

* Is source code available or accessible?

* What are the pricing models?

* Are the components downloadable, maintainable?

THE CLINCHER: REUSE

The promise of a building block approach to application development is a cheaper, faster, better way of getting critical applications up and running. However, the operative word in component-based development is reuse. Reuse, say industry participants, is where organizations will realize the greatest return on investment for reducing cost, time and effort throughout the software life cycle. But we found in our last research a year ago that reuse was the exception, not the rule. For starters, it goes against developer culture, which often values originality ahead of utility or practicality.

According to the Standish report, ROI for reuse becomes more apparent in subsequent projects, as development efforts take less time and, hence, less money. Although not a startling conclusion, the key hurdle is achieving reuse, not simply within the same application, but future projects. The tradeoff, of course, is that extra time and effort must be expended up front to come up with functionality that apply beyond the exiting project requirements document. Although it does not necessarily impact the requirements assessment stage, reuse involves added efforts beginning with specification and design. In some cases, development itself may become a larger exercise if the actual functionality developed must be made broader.

Not surprisingly, it isn't uncommon for companies to find their initial component-based development efforts taking longer and cost more than anticipated. If designed properly, the Standish report estimates that ROI for reuse is about 10% for second project and third projects, with the potential to jump to as much as a 60% savings by the fifth and sixth projects.

At this early stage in the market, Boucher observed that few companies are designing software with reuse in mind. Instead, as stated earlier, companies forging ahead with component-based development are doing without creating a new development framework-one that considers reuse. "The reality of the component-based software market is that it's rare to find a company not doing this type of development., However, if there's still any hype about this market it's about reuse," she said. While reuse is happening to a degree, it's not occurring anywhere near what it should.

In fact, Boucher noted that finding companies doing object-oriented development for the Standish study was easy. Conversely, finding those that met the criteria for reuse, which was key to the study, was difficult. According to a report commissioned by Flashline.com, there is a need for management tools that allow developers to easily locate and maintain components. It notes that tools which store, represent, search and retrieve designs and tools are just now being developed and embellished with hypertext with hot buttons for navigation.

"Software development is a trillion dollar market run like a 19th century craft," said Stack. He expects that as organizations adopt a more industrial approach to software development, the benefits of reuse and the appeal of purchased components will grow. In the rush to get applications out the door, it's no wonder why organizations are bypassing creating new development methodologies. Implementing the required methodology can take anywhere from six months to a year. Additionally, there are upfront investments to consider, including:

* Creating a separate group of domain engineers, performing domain analysis and developing architectures;

* Developing and maintaining asset management tools, such as repositories, for architectures, designs, documentation, and code;

* Tools to aid in the integration of architecture, design and software products to speed prototyping, full-scale development, modifications and maintenance; and

* Redesigning and implementing the proposal evaluation criteria and process.

USER EXPERIENCES

Empire District Electric Company. A midsize utility based in Joplin, Missouri, Empire provides electric service to 140,000 customers in a 10,000 square-mile area covering parts of Southwest Missouri, Southeast Kansas, Northwest Arkansas and Northeast Oklahoma. Several years ago, the company realized that it was in dire need of replacing a 20-year old mainframe-based customer information and billing system. The company turned to CBD for new application development.

In the electric utility industry, customer information and billing systems are the bread and butter systems. In fact, with industry deregulation, a robust and flexible customer information and billing system can be a huge competitive advantage. However, these systems can be big and complex, as well as costly-upwards of $50 million. That leaves many companies who are looking to replace older systems, out in the cold, including Empire.

While in the past, it was common practice for utilities to build their own customer information and billing systems, the recent trend is towards packaged solutions. However, sectors like utilities have such specialized information needs that a packaged software market never gained the critical mass that it attained in other sectors such as manufacturing or retail. Furthermore, as a sector, utilities generally lacked the resources to spend tens of millions of dollars for vendors to build applications.
That was the situation that Empire faced back in the 1995 timeframe. So, the company's IT department decided to take matters into its own hands, opting to create its own system. According to Ron Yust, director of information services, the company got engaged in a one-year pilot using SmallTalk, an object-oriented language dating from the 1980s that was considered more intuitive than C++.

However, around that time a couple of other events were going on: the company was going through a reorganization and Java was introduced into the market place. The utility company made the switch to Java, seeing it as the future for CBD. At the same time SmallTalk was going away.

Over a two year period, beginning in 1998, the company had a team of five developers devoted to building the customer information and billing system. Called Centurion, Empire's customer information and billing system, using XML along with Java technology features including Java Database Connectivity API (JDBC), Enterprise JavaBeans (EJBs), JavaHelp technology, and Java Servlets, went live November 1999.

Before any development took place, the IT department had adopted a philosophy that development work going forward would be based on an object-oriented architecture which would benefit both developers and users. "Using object-oriented development we create a one-to-one mapping with our database model which reflects our business model," said Yust. Additionally, the company turned to CBR for cost considerations, as well.

In 1998, the company hired four developers, none of whom had any Java knowledge. The firm's 5-person team all hit the books and brought themselves up to speed on Java. Yust designed the framework and programmed it. At the time, each developer cost the company about $40,000/year in salary, or $160,000 in total. These new hirees filled existing vacancies, as well as, assumed responsibility for the customer information and billing system project. We didn't get figures on how much time was spent in self-training, but we assume that it was probably on a part-time basis for 3 - 6 months.

According to Yust, the learning curve was minimized due to the systems design. "We had a toolkit handle all of the housekeeping, such as GUI presentation and server interactions. Developers also wrote APIs into the framework to implement components.

At the end of the 2-year project, the developers created about 2000 reusable software components. About 100 of the components are business objects and each business object has about 20 supporting objects for the client and server side. To aid in application development, the company built its own tool that examines database schema and generates code. In fact, Yust reported that 90% of the code was generated automatically using this tool. The other 10% of code was done manually. "It was the ten percent that required ninety percent of the programming effort because it included the business logic," he said.

Most of the estimated $500,000 cost for the new customer information and billing system was labor (we assume that self-training time was included in this figure). If we compare this expenditure to the system cost of $6 million suggested by an outside consultant, Empire saved itself $5.5 million by building the application itself using Java technology and CBD. That $6 million figure only represents system cost, not the cost Empire would still have paid its internal staff.

At the time, Yust looked at industry benchmarks for an implementation timetable. He determined that, regardless of whether the company bought or built, the benchmarks indicated that the system would still take two years to implement. In the end, Empire developed its own system and implemented it in the same timeframe plus, the company believes that the system it developed is more flexible and adaptable than one it might have purchased. The system runs on NT and Oracle and has multi-platform capability. In fact, the company tested Java's multi-platform capability and found that indeed the program could run on a variety of platforms with no changes required in the code.

On the other hand, by developing internally, it has a documentation and maintenance burden that, with packaged software, is typically borne by the vendor (typically in return for an annual maintenance charge of about 15 - 20% of the original software purchase price). But, as mentioned above, Empire had little choice given the lack of packaged customer information system offerings for the electric utility industry.

While Empire considers the project a success, it was not without its challenges. The company adopted the Java architecture just as the Java wave was cresting which meant that the company was always waiting for a new release of Java to take advantage of new capabilities or to bypass errors in previous releases. Another challenge was finding developers skilled in Java-Empire didn't. They opted for self-training instead. However, using a modern, object-oriented language like Java, and a standard component-based architecture, Empire's maintenance burdens should be more modest compared to legacy programming languages like COBOL.

The company's bravery might pay off: other utilities are interested in purchasing Centurion. "We started this project as an act of desperation but it might turn into a opportunity to generate revenue," said Yust. The utility considers itself a trailblazer in the Java marketplace, particularly as a utility engaged in this type of development.

Managemark Inc. A company in the application service provider market, Managemark is a producer of business-to-business Web applications for corporations and next-generation e-business portals. Managemark turned to object-oriented design when its ExpenseAble application, developed using Microsoft's Active Server Pages (ASP) scripting language, a non-object oriented approach, began to falter. The company ported its applications using Java technology.

When Managemark developed its ExpenseAble application, a suite of services that includes online, desktop and mobile applications that process expense reports and streamline administrative duties for users, it chose ASP for development because it was looking for a "quick and dirty" way to get its development effort going. The company used ASP to write the user interfaces and all the business logic. According to Satish Kamatkar, engineering manager, the project took nine months to complete and the application was launched in June 1999.

Hundreds of customers signed up for the ExpenseAble. At that point, the company realized that its application didn't scale well. Furthermore, it proved difficult to maintain, and customers were complaining about slow response times.

The maintenance issues were particularly troublesome and were the direct result of the way in which the code was engineered. A single file contained all the code,
which included ASPs, JavaScript, HTML, and SQL calls. If developers needed to change a page or troubleshoot, they had to open the whole file, which was tedious and time consuming.

The IT department decided to port the application using an object-oriented approach which it hoped would save time and money. In January 2000, the company chose the Java2 platform because it attracted a critical mass of industry support, promised the scalability that the company needed, and eliminated burdensome maintenance requirements. "We're short on resources and we don't want to spend extra money on cycles for troubleshooting when we could be spending money on our products," said Kamatkar.

Since January, Managemark has completed three phases of component development using the Java 2 platform, Standard and Enterprise Editions, incliuding technologies such as JSPs, Enterprise JavaBeans, JDBC, and the Java Media Framework.

To minimize risk, the first phase of component development using Java involved only a portion of the ExpenseAble application. The company selected parts of the application that affected some, but not all, customers. The first phase of development entailed building a new product feature, called corporate cart, which the vendor prototyped and deployed on a beta site before making it available to all customers. The new feature took about three months to build using Java Servelets and JDBC.
The second development phase involved porting an application feature that had to do with submitting an expense report. A database-intensive feature, it had previously been plagued with performance problems and was the cause of many customer complaints. Though the volume of work required during this phase exceeded that of the first project, it too took only three months to complete. Kamatkar contributes the development efficiency to the experience it gained during the first phase of development work, meaning that IT staff had gained expertise having already built the infrastructure.

When all was said and done, application response times, which were way above the industry standard taking about eight to 10 seconds, were reportedly by over 50%.
The third phase of development work at Managemart has to do with integrating the company's applications with partners products. Wireless Knowledge, a company of Microsoft Corp. and Qualcomm Inc., and provider of wireless computing solutions, asked Managemark to port its ExpenseAble application to its wireless device. The port was completed in about a month thanks to component reuse.

In all, Managemark reported that it developed about 20 components and created a clean three-tier architecture for the ExpenseAble application. This architecture separates the various application layers: presentation, business and data access.

When Managemark began Phase I, the company had limited familiarity with object-oriented programming. Initially, the company used four core people on the project but six months later had 10 - 12 developers working on its project-an additional four people were hired after completion of the first feature. The cost for the additional expertise was $80 - $100 per hour, depending on the level of expertise.

Based on an average cost of $90/hr for one Java developer, Managemark paid approximately $3600 per week/per individual, or $14,400 for four outside experts per week. The cost of hiring outside help to complete phase two was about $173,000 for twelve weeks. The company continues to use the outside developers bringing labor costs well above $200,000.

While Kamatkar didn't have exact expense figure for all of the development work ongoing since January, he knows that the company has saved between 30% - 40% in total cost of ownership (TCO), with savings of at least $100,000 on application maintenance costs alone.
The company reported several benefits to using Java for application development, including:

* ExpenseAble is robust and scalable;

* The application is easy-to-use and maintainable;

* The company can more easily attract IT talent because of its chosen application architecture and design; and

* Cost savings.

Firstborn Multimedia Corp. Software component reuse has been key to the business success of New York City-based Firstborn Multimedia Corp., a creator of interactive web presentations. A $3 million company with four programmers, Firstborn began relying on reusable components about six months ago. "We're dealing with clients that have compressed development cycles," said Robert Forras, vice president of technology, noting that many client projects include features and functionality that are "standard stuff."

For the past year-and-a-half, the company moved into web-related multimedia work. For Firstborn, reuse enables the company to leverage code across its client base and differentiate it for customers by mapping in new fields. The company's technology of choice is Enterprise Java Beans. For Firstborn, The beauty of reuse is that the code has already been battle tested and doesn't need to be retested saving time and money. The company hasn't had to go out and hire additional developers, saving upwards of $50,000 per developer.

The company has turned to several vendors for product, including BEA Systems Inc. Firstborn uses more than half-a-dozen components in BEA's WebLogic Commerce Server, which carries a full suite of Java-based components including catalog, shopping cart, inventory management, order entry, order management and shipping components. Forras notes that he buys components from other vendors as well but can't discuss them at this time.
Adopting a reuse strategy for application development has put Firstborn 50% ahead of the game in terms of how much business it has been able to take on. The company currently has 50 clients.

One complaint Forras has about the third party component market is product pricing, noting that a lot of offerings are far too expensive. For example, he pointed to one company charging $45,000 per processor on the client for its code which would total $450,000 if the code were to run on 10 processors. "If the customer wanted to scale up to 20 processors, the cost would jump to almost one million dollars," he said. In this case, he noted that his developers could build the same component for $200,000 and make it scalable to meet clients needs.

This is not a religious issue for Firstborn. If the price is right, said Forras, Firstborn would buy components rather than make them.

Jellyvision Inc. A 65-person creative company specializing in the invention of interactive experiences and creator of products such as the "You Don't Know Jack" adult trivia CD-ROM game, Jellyvision is another company realizing the benefits of component-based development and reuse. Founded in 1984 as Learn Television, a creator of educational media, Jellyvision took a turn in 1996 and expanded its product line outside of the education market. At that time, it brought its development efforts in-house, and now has a 10-person programming staff.

Jellyvision decided that it would look for ways to develop the user experience utilizing both off-the-shelf components and building parts of the application in-house. "We wanted to use a cross-platform, quick, productive type of language for scripting the user experience and Java rose to the top," said Dave Krohn, director of technology, who noted that the company must develop both for the PC and the Mac markets.

To do the hardcore multimedia, the company coded in C++. Java, he noted, wasn't robust enough for the company to use it in this area because, at that time, Java2 platform development lagged behind on the Mac platform.

(Note: At Java One 2000, held in June, Steve Jobs made the long-awaited announcement to make the Mac "the best Java delivery vehicle on the planet.")
The company used Java for scripting of the experience and Java Native Interface (JNI) to write Java code calls to C++. Despite the fact that the multimedia experience
is different for the Mac and the PC, Java code for the user experience is compiled only one time for both the Mac and the PC.
For Jellyvision, the benefits of reuse come from the reusability of the engine itself, which allows the company to quickly create the user experiences. "We write the engine once and reuse it over and over again. It's the core of our experiences," explained Krohn, adding that at most there's minimal customization for each experience.

THE PRICE AND REWARDS OF DISCIPLINE

Not quite a mainstream technology, companies doing component-based software development often feel like trailblazers. The advantages of component-based development are obvious: the ability to have more manageable code, and the potential to reuse logic in future application development projects.

But there are costs and risks. For starters, as we noted, it costs more to perform the more disciplined software engineering practices to architect applications as components, and to design business logic for future as well as present needs. There is developer cultural resistance to using somebody's else's code. There is the technology chase. And, if third-party components are used, there are interoperability and standards compliance concerns. Additionally, because components come with a number of features, including standard interfaces and techniques for managing their own life cycle, they consume more computing resources than raw code.

These are manageable costs and risks. The main hurdle, however, is that CBD is a strategic decision for development shops which impacts the types of developers they must recruit or retain, the amount of necessary training, and the long-term architecture of applications that will be deployed. Although components do not have to be designed as objects, using OO approaches makes reuse far more feasible. For that, it requires the development organization to commit to object-oriented design, including getting the necessary training if developers come from traditional programming backgrounds. The bottom line is that CBD is a development strategy that may be more expensive to implement initially.

The rewards, including more robust software engineering and the potential to reduce future development maintenance and development costs are powerful inducements. Now all you have to do is recruit the right developers, which in today's tight job markets, is anything but simple.

J2EE: A Primer Java 2 Enterprise Edition was first announced a year ago by Sun to provide the base specifications for common functions performed by server-side Java. By specifying basic plumbing, the goal was to make server-side Java portable to different vendor appservers. In practice, users of appservers released before the J2EE standards will have to migrate to current versions before they could feasibly port applications. J2EE encompasses several major technologies, including: * Enterprise Java Beans (EJBs). This is the component architecture for server-based Java beans. While client-side Java Beans primarily covered GUI features, EJBs cover back end functions including business logic and database connections. There are two types of EJBs: session beans, which are used for business logic and session management, and entity beans, which encapsulate data objects and map them to relational database table structures. (Note: EJB versions 1.0 and 1.1 predate the J2EE spec; EJB 2.0 is the version that is J2EE-compliant.) * Java Servlets. These are small Java web applications which are deployed on the server at run time. They can run in the webserver (for rudimentary web applications), or behind the firewall (for greater security) in an application server. They provide higher-performance alternatives to CGI web programs (CGI is the default API used by webservers to initiate program sessions). They are theoretically more portable than Netscape (NSAPI) or Microsoft (ISAPI) gateway alternatives. * JavaServer Pages (JSPs). JSPs extend Java servlets by providing the ability to dynamically generate data-driven HTML and XML web pages. In effect, they separate the creation of web pages (presentation) from the application (business logic). They are built using XML tags or Java Beans (which generates the content) and Java scriptlets (small pieces of Java code which contain the display logic for generating the web page itself). (Note: Microsoft's equivalent is the ASP, or Active Server Page.) * Java Naming and Directory Interface (JNDI). A generic API for Java programs that theoretically provides access to any directory service. This allows Java objects such as AWT and JavaBeans components to be bound to directories without the need for additional translation steps. However, as a generic API, it does not provide native access to low-level protocols that are specific to LDAP or Microsoft's Active Directory. * Java Transaction API (JTA). This provides an interface to Java-based transaction services, avoiding the need to write EJBs to perform the task. * Java Message Service (JMS). This provides an API for accessing enterprise messaging systems, such as IBM's MQSeries. * Java Database Connectivity (JDBC): The Java-based interface to SQL (relational) databases. J2EE updates JDBC, adding features such as the ability to include scrollable result sets (where large blocks of data can be browsed).

Sun Clears Path for Java Licensees to Support Microsoft's C# As this report went to press, Sun clarified its Java licensing terms as part of a realization that Java and C# will likely coexist. This report appeared in the Computergram July 31, 2000 issue. Sun Microsystems Inc, the industry's increasingly pragmatic Java police force, has given its consent for licensees to hook its developer and runtime environment into Microsoft Corp's nascent C# language, a cornerstone of Redmond's recently launched .NET strategy. Palo Alto, California-based Sun said it was powerless to stop ISVs or developers licensed to use Java from developing compilers that enable Java to natively access files, resources and features of C#, and vice versa, via the much-touted common language runtime environment. "Sun is not in the position to tell people how to change their business model," Gina Centoni, Sun Java platform product manager, told ComputerWire. She was backed by distinguished Sun engineer Tim Lindholm who refused to reveal terms of individual licensing deals but said: "Sun doesn't hold that type of requirement in their [partners] licenses." Sun's stance on C# marks the latest phase in an increasingly pragmatic stance on Java. The company last year abandoned plans for Java to be ratified as an independent standard and is recently thought to have offered IBM more liberal licensing terms. But Sun said it had no immediate plans itself to link Java to C# or .NET, as it could see no customer demand. Sun was backed by IBM: while the company will evaluate C# the company has no plans to develop an interface for Java or its own native languages such as RPG3 language for AS400. Scott Hebner, IBM director of e-business marketing, said: "IBM's commitment to Java is unwavering." Between them, IBM and Sun have wasted no time in dismissing C# and .NET. The companies see C# simply as the latest version of C++, and a tool designed to unify fiercely entrenched developers from Microsoft's separate Visual Basic and C++ camps. C# does, indeed, bring both camps together, offering access to each others code and resources and a single developer environment via the forthcoming VisualStudio.NET. But third parties have already begun to seize on C# and the common language runtime. Vancouver, British Columbia-based ActiveState Corp is hooking Perl into .NET and said C# removed the need for interpreted language, as code can be compiled natively. Company chief executive and founder Dick Hardt added chip developers could potentially write a compiler for their separate own chip sets, such as the AMD chip or the planned Itanium chip, that maximize the code's performance on different devices. "To the user they would be transparent. There are a small number of people who write chips. But this lets people optimize the code for their particular chip," Hardt said. He added .NET, though VisualStudio.NET, would let developers write across platforms using existing Windows-based skills and without the need to learn Java programming.

© 2000 ComputerWire Inc