J2EE for Managers

Introduction

Enterprise Environment

Driving Forces

Options

Java 2 Platform

Why Java

Java 2 Editions

Java 2 Enterprise Edition (J2EE)

Definition

Architecture

Future

What's still missing

Good Uses of J2EE

Bad Uses of J2EE

Evaluating J2EE Application Server

Focus

Developer's Focus

Manager's Focus

Human Resource

Software Resource

Process Issues

Summary

Introduction

If you are managing large-scale applications, it's likely you have already or soon will evaluate enterprise architectures.  Making the appropriate decision and preparing for the endeavor requires knowledge and understanding the technologies and related issues.  This paper explores the current enterprise environment and available options.  It describes the technologies included in Sun's Enterprise Platform solution J2EE (Java 2 Enterprise Edition).  I conclude with the softer concerns of how this effects you as a manager and your development staff.

Enterprise Environment

It has always been a challenge to build systems that meet the needs of business.  It seems that there is never enough time or resources to accomplish everything.  While not all of the driving forces behind enterprise development are new, they have intensified due to the Internet and globalization.  They include, faster time to market, complexity, being a profit center, availability, mobility, reusability and business to business.  To satisfy these forces you will have to understand and evaluate the available enterprise options.

Driving Forces

Faster Time to Market

Multi-year projects are a thing of the past.  Today's project teams are lucky to get a six month deadline and the appropriate staff to complete it in that time.  This is due in part to intense global competition.  Organizations are not competing against the business next door, but across the country and the world.  For example, this past Christmas my wife and I were able to purchase products such as Ben and Jerry's gift certificates when there isn't a Ben and Jerry's within a hundred miles of where we live.  In the short history of the web it has shown that the first one to market is able to establish a customer base and develop customer loyalty.  Furthermore, internal customers can improve productivity as they get tools that can help them complete their jobs more quickly and accurately than before.

Complexity

Multiple hardware platforms, operating systems, software packages, protocols and languages are just some of the complexities with which IT managers and developers must handle to compete.  Providing integrated solutions in heterogeneous environments cause challenges in building, deploying and managing enterprise applications.  In addition, rapidly changing business requirements and the ever-present office politics only add to the complexity.  Add the rapid pace of technology advancement to the mix and you begin to wonder how anyone accomplishes anything.  You also begin to understand why many organizations fail.  The recent dot-com obituaries confirm this.

Profit Center

It used to be that IT departments were just assumed to be a necessary evil.  IT was just a cost of doing business, cash down the drain.  These opinions certainly have changed in the last couple of years.  IT departments have quickly become expected to produce a profit for companies.  In the case of dot-coms IT departments are the revenue stream.  However, it is not just internet companies that are expecting IT departments to produce a profit.  Traditional companies have found creative ways to sell products or attract customers using internet technologies.  For example, it was not long ago it would require a broker or travel agent for the consumer to purchase stocks or make reasonable airline reservations.  With the Internet, customers can often get better and quicker service performing these activities themselves.  Ideally transactions are more profitable for the company due to lower costs which are sometimes passed on to the consumer.  Technology is the enabler that replaces the human interaction and accelerates the process through automation.

Availability

With the advent of globalization and increased worker mobility, the requirements for access to information has changed.  Customers and employees expect to be able to access information in real-time 24 hours-a-day 7 days-a-week no matter where they are.  Historically organizations were able to do major processing in an all night batch process.  Organizations can no longer afford this the luxury.  Customers want access to products and services at their convenience.  Customer on the other side of the globe have different business hours and will not and can not wait until you open your doors.  Every minute of down-time means lost productivity or sales. 

Mobility

With the introduction of handheld technologies customers and employees are able to carry computers more powerful than just 10 years ago in the palm of their hand.  If the last decade was the information decade then this decade could be considered the communication decade.  IT departments are required to support these technologies so customers and employees can make informed business decisions regardless of location.  The network connection ankle chain that kept people tied to their desks has been broken.

Reusability

To meet business demand, IT departments do not have the luxury to reinvent the wheel.  Since they are expected to produce a profit, reuse can significantly reduce expenses.  Reusability at the enterprise infrastructure level may be the biggest reason for the move toward application servers.  Instead of each IT department developing and building their own infrastructure they can purchase a non-proprietary, standards-based, tested solution that they can reuse for many types of applications.

Business to Business

Businesses have also found that it is less expensive and quicker to conduct business electronically.  Retail stores can maintain inventory levels and automatically order products from the warehouse with limited human intervention.  Productions can arrive on the next shipment rather than wait for an expensive periodic manual inventory.  Out-of-stock items often translate to lost sales or costly special shipments.  Some organizations have found B2B communications so valuable they won't even entertain suppliers not willing to accept electronic orders.  Large organizations are forcing smaller suppliers to participate in B2B exchanges in order to continue conducting business with them.

Options

Enterprise software development is a large investment in time and money.  Choosing the right enterprise development option can greatly affect both of these investments.  In today's marketplace there are three options, Sun's Java 2 Enterprise Edition, Microsoft's DNA and a home grown proprietary solution.  A vaporware solution that is getting considerable amount of press right now is Microsoft's .NET architecture.  Because .NET isn't even available nor will it be for at least 1 to 2 years despite what Microsoft would have you believe, we will not address it as a possible solution in this document.  If you wish to investigate and review the propaganda, visit http://msdn.microsoft.com/net/.  An approach to choosing an enterprise solution is to treat it like a buy vs. build decision.  If you take this approach and choose to buy you can eliminate the home grown proprietary solution reducing your options from three to two.  If you choose build, beware of consequences I address later.  Read on to see what you may be missing out on and may require to build into your solution.

Java 2 Enterprise Edition (J2EE), Sun's enterprise solution, is a popular open and multi-platform option, built on standards rather than a product or single do-all technology.  Over 29 vendors provide J2EE implementations both open source and commercial products.  This openness provides the ability for creating a best of breed solution.  Implementers and vendors of J2EE solutions have the ability to combine the different services of J2EE into a comprehensive solution.  Examples of the effectiveness of a best of breed solution would include JBoss, Enhydra and  OpenJODA which all also happen to be open source solutions.  Even Borland has taken this approach by including Tomcat, an open source web container into the Borland Application Server product.  The J2EE architecture has gained unprecedented support by major vendors and industry heavy-weights (besides Sun of course) including BEA, Borland, IBM, HP-Bluestone and Oracle.  Most notably missing is Microsoft which is also equally not surprising.

An alternative to J2EE is Microsoft's DNA.  While DNA and J2EE share many common enterprise  services like e-mail capability, server-side business objects and dynamic web user interfaces, they are quite different in their approach.  DNA uses multiple languages in its solution, including C++ and ASP (VBScript).  The DNA solution is also strictly tied to the Windows platform.  Using a Unix platform for performance head-room is not even possible.  Additionally, instead of being built on a standard specification, it is built on a suite of Microsoft software.  This means those using the DNA option live and die by Microsoft.  If Microsoft has difficulty producing a solid trouble free product everybody using the DNA architecture suffers.  Furthermore, if Microsoft decides to stop supporting a particular application or part of the DNA infrastructure organizations may also suffer.  I spoke to an organization recently that built their applications in Fox Pro which ironically will not be supported as one of the "many" languages available in .NET.

Historically, the proprietary solution has been a popular option for many organizations.  However, with the demands of the marketplace being so great, most companies can not afford to invest the time or money into building a proprietary solution from scratch.  Many hidden costs and issues exist and reveal themselves when implementing a proprietary solution.  First, there is no vendor support.  Since the software is built from the ground up the implementers become their own vendor, responsible for maintaining their own code base.  Second, since it is the first time the solution has been implemented it is unproven.  There are no third-party newsgroups, FAQ, manuals, product conferences or support pages.  You only have what you have time to create which is often nothing.  Additionally, the developers have to take on the responsibility with keeping up with technology while continuing with existing maintenance.  I have spoken with many organizations that have implemented successful proprietary solutions in the past but are now facing the fact their application is not web enabled.  Last, it is impossible to hire new staff that know proprietary architecture.  Candidates quickly realize they won't be developing marketable skills while developing and maintaining proprietary solutions;  they'll be falling behind technically compared to their peers.

Java 2 Platform

Why Java?

Rather than asking "Why Java?" you should ask yourself, "Why use anything other than Java?"  Sun originally introduced the Java Language along with many promises.  At the time Java struggled to live up to them.  But after 5 years Java has advanced and proven itself as a flexible, secure and cross platform language fulfilling the promises Sun said it would.  But besides that there are many other good reasons to consider Java.  Enterprise computing requires distributed computing functionality, Java was built to include networking and distributed objects in the base language.  These features do not require purchasing additional non-standard software products or add-ons.  Since distributed computing was included in Java since the beginning there is a large pool of resources capable and experienced in building complex systems.  Furthermore, because of Java's success in general development as well as the enterprise arena, there is a large amount of industry support from everyone except Microsoft. 

Java 2 Editions

The Java platform is quickly becoming all things to all people.  The platform has branched from its humble beginnings as a browser based technology to include desktop, embedded and enterprise applications.  To simplify the rapid growth of the Java platform, it has been organized into three editions geared toward three specific markets.  They are: Standard Edition (J2SE), Micro Edition (J2ME) and  Enterprise Edition (J2EE), the primary focus of this paper.

The Standard Edition is the foundation of both the J2ME and J2EE editions.  It includes the Java Language, Java Platform and Java Virtual Machine.  The API included with the Standard Edition allows developers to write Applets, Desktop Applications, JavaBeans and distributed applications.

The Micro Editions focuses on embedded and hand held development.  It requires the Standard Edition for compiling.  Due to the limited nature of this form of development certain device profiles or software representations of specific hardware may only have access to a subset of the full Java Platform.  This is a notable area in which  Java's promise of write-once run anywhere may not fully apply.  But then again how many developers want to run an entire enterprise application server on a Palm Pilot.  The Micro Edition can help provide solutions for the enterprise demands of availability and mobility by hosting a client application that accesses a J2EE application server.

As a brief introduction, the Enterprise Edition is intended to provide a standard component-based architecture for implementing server-side business logic.  It addresses common problems with solutions for transaction management, distributed objects and security.

Java 2 Enterprise Edition

Java 2 Enterprise Edition (J2EE) is a set of independent standards combined to simplify the process of building enterprise applications.

Definition

J2EE is a specification that combines pre-existing independent specifications to produce a scalable enterprise platform.  The independent specifications when combined form the J2EE API that allows organizations to build applications independent of a J2EE application server vendor's implementation.  This pluggable architecture does not only apply to the business applications that organizations write but it also applies to the vendors that implement their solutions to a set of interfaces called the Service Provider Interface.

Architecture

J2EE architecture is just really an evolution of the recent client/server or multi-tier architectures.  It provides a presentation tier, business logic tier and a data tier.  J2EE additionally supports dividing the presentation tier into two parts for thin-client solutions.  The client-side which commonly uses a web browser and a server-side which usually produces dynamic web pages using either the JavaServer Page (JSP) or Java Servlet technologies.  One notable difference between other multi-tier and J2EE architectures is the use of the container-component relationship.  The components such as JSP, Servlets and Enterprise Java Beans (EJB) live in the context of a container.  The container provides common services to the components it hosts including resources & connection pooling, threading, life-time & transaction management.  It also acts as a communication proxy for components in other containers.

J2EE Architecture

Future

J2EE continues to evolve through the Java Community Process (JCP).  Sun is working with other vendors to shape the future of J2EE and the other Java editions.  Some of the items that are currently proposed in the JCP include XML Data Binding, application deployment and application management.  

With the introduction of XML into the enterprise arena, it has become common practice to map XML data to Java classes.  This is often not a trivial task nor is it implemented in a standard way.  The XML Data Binding specification will address this issue by creating an API to simplify and standardize the binding of XML data to Java classes.  

Two separate proposals have been introduced to address the issue of application deployment.  The first addresses the deployment of user applications based on Swing or Java Foundation Classes (JFC).  Java Network Launch Protocol (JNLP) will be required in future versions of J2EE.  An implementation of this protocol is already available from Sun called Java Web Start.  The technology provides for the deployment ease of applets without the restrictions while providing the rich user experience expected with Swing.  After installing Java Web Start or other application that understands the Java Network Launch protocol, a user just needs to click on a web page link to install the application.  The interesting thing is this can actually be done today.  The only requirements are that Java Web Start be installed on the client machine and a web server is available to serve a JNLP file.  A JNLP file is an XML document with a specific format which contains instructions for Java Web Start.  Because J2EE requires a web container, it already has the necessary web server component available for the application.  The second proposal addresses deploying the server-side components by requiring that J2EE vendors implement a standard development API.

Currently there are no requirements for managing deployed applications.  While most vendors implement their own proprietary mechanism there is a proposal that intends to specify an API for managing J2EE applications.  A standard API will simplify the management and configuration of environments that support heterogeneous application servers.

What's Still Missing

While J2EE addresses many areas of enterprise development it does not cover everything.  I mention this primarily to set expectations and to identify areas where development teams may need to focus or where you will have to purchase additional software.  Currently, nothing in the specification addresses workflow or scheduling.  While some vendors include these features in their products or make them available for additional purchase understand that by definition they are proprietary.  Since no standard specification governs their implementation such usage may tie you to a vendor's implementation for that portion of your application.  Additionally there is support for languages other than Java through CORBA.  However, integrating languages that do not support CORBA may require additional software or effort.  The only standard for logging J2EE applications is System.out and System.err.  I believe there needs to be more robust logging support.  Java 1.4 may address part of that by implementing a logging scheme itself.  Lastly, may additional business functions have been getting good deal of press in the trade magazines.  Unfortunately, the J2EE specification does not currently address any of them.  I hope going forward these may become integrated just as JMS was implemented by Message-driven beans.  These technologies include web services, content management, syndication and personalization.  Again some J2EE vendors include these in their offerings but they prevent application server transparency.  Also missing is cross-vendor application server interoperability.  Today you can't mix and match application server communication very well, although message-driven beans will go a long way to alleviate this.  You certainly can not use one vendor's application server and replace the built-in EJB container with a specialized implementation from another vendor.  Related to this notion, today we have general purpose application servers.  They're designed to host any application.  As the market evolves we'll also being to see more application servers that tout their specialized strengths like "best for high performance real-time financial applications" or "ideal for e-commerce applications that require enhanced security for critical transactions."  They'll all be able to also host general purpose applications.  Those features will be a basic commodity.  The specializations will be how vendors differentiate their products.

Good Uses of J2EE

J2EE is an ideal solution for applications that require high availability, security, reliability, transactions and scalability.  Additionally, organizations that do not want to lock themselves into a vendor will find peace in knowing that J2EE applications servers implementations are available from over 29 vendors.  This peace has a dark side because that means you must select one.  J2EE is to enterprise development as SQL is to database development.  This means that in practice each vendor's implementation may differ in subtle or even significant ways.  Furthermore, J2EE lends itself very well to an Application Service Provider Model.

Bad Uses of J2EE

Organizations needing to implement a small simple solution will find that J2EE is very cost prohibitive.  Most J2EE application servers range from $5,000 to $35,000 per CPU.  This means that shrink wrapped desktop office productivity packages would also not be good candidates.  Additionally, applications requiring disconnected clients may not gain value from the J2EE architecture because the business logic resides on the server and those clients would not have access to it while disconnected. 

Evaluating J2EE Application Servers

The first step many organizations take when starting a J2EE endeavor is to acquire an application server.  All application servers are not created equally.  Depending on the background and core competency of the application server vendor it may use different strategies and optimize different technologies.  Also, many organizations purchase a J2EE application server and then only use limited parts making it a very expensive solution.  Most people would not use a 3-speed power screwdriver to adjust their reading glasses.  Let me suggest an alternative: build a pilot J2EE application using Sun's Reference Implementation or an open source application server, like JBoss.  This prevents you from spending a lot of money before knowing the technical requirements of your application or having an opportunity to performance test it with different application servers.  By sticking to the J2EE specification and staying away from proprietary extensions, you may be able to build all or at least a significant portion of your application before selecting an application server product for development.

There are many issues to consider when choosing a product and vendor of a J2EE Application Server.  While each organization must determine their own priorities and criteria for evaluating the products, here are some common criteria that you should consider.

 Focus

With the advent of J2EE technologies, developer's and manager's focus will change.  Eventually developers should find they are spending less time concerned with technical infrastructure details and more time implementing business solutions.  While the developer's focus becomes more narrow, a manager's focus becomes broader to enable developers to implement complex business applications.

Developer's Focus

Burden of  communicating among services has been reduced so developers can focus on the market differentiators.  Developers will find most of their time occupied by one of three areas: business logic, presentation logic or deployment issues.  See the diagram below.  It depicts the developer's area's of responsibility in green.  Ideally the business logic is in the EJB Container, the presentation logic is in the web container and other application clients.  The configuration and deployment issues can occur in all areas.   They will probably change from implementing common services in proprietary systems to taking advantage of already existing services provided by J2EE and the application server product.  They may find it necessary to implement services mentioned in the What's Still Missing section.

Developers Responsibility are identified in green.

Manager's Focus

A manager's focus can be broken down into three main areas: human resources, software resources and process issues.  

Human Resources

Roles

The human resource side first includes organizing and staffing a successful development team.  And secondly, providing the team with the training required to complete the job.

There are several standard roles that should exist on any J2EE development team.  They include architect, database administrator, software developers, web designers and system administrators.  While most of these roles are self-explanatory it may be helpful to further define how some of these roles map back to a developer's primary focus.  In some organizations it is not uncommon to split software developers into two groups.  One group would focus on the business logic while the other group focuses on the presentation logic.  Who then is concerned about deployment issues?  Deployment issues specific to presentation logic and business logic fall on the shoulders of those groups implementing those parts but the remaining issues by default go to a system administrator.

Additional roles that may determine the success of first time J2EE ventures are the mentor and scout.  For first time J2EE projects, I would even say a mentor is a necessity.  Mentors provide value in the fact they have already implemented systems in the technology being used.  They provide insights that inexperienced individuals cannot know.  I have always found it interesting that developers are asked for estimates in technologies they have never used.  Estimates should be a major role of a mentor since they are experienced in those areas.  Mentors can also be used to prevent problems in the future.  Mentors are an ideal candidates to perform code reviews, and establish & review standards.  Having experience can help identify problems early in the project.  Additionally, mentors should be required fulltime for three months to a year depending on the skill level of the team and complexity of the project.  To effectively and cost-effectively use a mentor do not expect them to spend all or even most of their time coding.  In general a mentor should only be expected to code about 25% of the time and that coding should be on difficult problems that have taken members of the development team significant effort to try to solve.  What then should a mentor be expected to complete during the remaining time?  The following contains a list of common activities a mentor should be expected to complete.

A scout's role is a little different than the mentor's role.  A scout is an individual that is empowered to investigate or perform a proof of concept on technology not currently being used by their organization or department.  A scout is able to recognize opportunities to use a new or updated technology or technique that will help the team be more productive, efficient, or improve quality.  An example might be to investigate how to use a Palm Pilot or cell phone to enable mobility while still accessing server-side business logic.  If the proper individual is selected and the investigation proves successful, the scout could eventually move into a mentor role with the experience gained.

Training

For a successful J2EE project, the development team must be equipped with the proper knowledge.  Experience is the best teacher.  However, organizations do not have the funds or time for teams to repeatedly build an applications until they get it right.  An investment in a couple of weeks of good training, followed up with a talented mentor can prevent development efforts from going down the wrong path or wasting time building something that already exists.  Many organizations offer Java, EJB and J2EE training.  Make sure when selecting a trainer or training organization that you choose one that offers practitioners.  Practitioners will be able to guide you through their experience and provide tips and tricks they have learned a long the way.  Often this means they can share the issues they struggled with the most.  The alternative is someone who studied a book; may even be certified but has no practical experience to deal with real-world issues like the ones you have.

Training is expensive and time consuming.  The Gartner Group has identified it costs approximately $13,000 and $21,000 to migrate a C++ and COBOL developer respectively to just the level of a casual Java developer.  These figures include the cost of the training, lost productivity, practice time and expected salary increases.  It does not include travel and related expenses.  Between the actual training class and practice time it can take between a month and two months to successfully  prepare a development team for the challenges of J2EE.  Because of the expense and time involved make sure you perform a skills gap analysis.  Determine the skills you need to implement your solution.  Then determine the skill and levels of the existing staff.  Acquire training to fill that gap.  If the intent is an application that requires a web front end it may not be necessary to spend a week on Swing.  Also, get creative.  If your team is split between presentation and business logic, send each group to courses focused on the appropriate skill set..  After they complete the training courses and gain some initial experience have them cross train each other over lunch or short sessions.  As a trainer I have learned you never really know something until you teach it.  This technique will reinforce what they've learned and reveal areas for continued self-study.  In addition, a week of training can be overwhelming and tiring.  By providing learning opportunities throughout the process it can remind people of what they've learned at the appropriate times.  A mentor can be very helpful here in performing a skills gap and identifying additional learning opportunities during the development process. 

The training needs for J2EE development include the following:

• Object-oriented development
• Multi-tier or distributed computing
• Java
• J2EE
• Modeling
• Methodology
• Specific application server
• Selected J2EE technologies
  • JSP
  • Servlets
  • EJB
  • JNDI
  • JDBC
  • JMS
  • JAXP
  • JAAS
  • JTA
  • JavaMail

The following diagram depicts one possible progression of understanding and experience of a Java Developer.

Java training path

Process Issues

The process of J2EE development is not all that different than other object-oriented development so don't forget the importance of gathering requirements, modeling, using a methodology such as Rational Unified Process (RUP) and iterative development.

Software Resources

Developing J2EE applications will require the supporting software.  Of course an application server of some kind will be required for development and testing purposes and ultimately run the production application but there are additional products required for designing, developing, testing and executing.  In some cases the software may be bundled in a complete product alleviating the process of evaluating and purchasing multiple items.  Because modeling is such an important aspect to the success of an application, invest in a good modeling tool that is based on UML.  I would also recommend getting a modeling tool that generates Java code for your classes since it can save a large amount of time.  Many of the modeling tools now even understand the J2EE paradigm and model EJBs.

For development a good IDE capable of generating, managing and debugging code is required.  If you've already selected an application server or one was selected for you, select an IDE that integrates well with the application server.  This can either be by selecting a IDE produced by the same application server or by acquiring a IDE plug-in.  Just make sure that the IDE integration increases productivity.  If it doesn't, don't use it.  As an alternative use a command line build and deploy tool like ANT.  Also to reduce the risk of losing or mismanagement of source code make sure you acquire version control software.  Version control is the lifejacket of software development.

During and after the development of the application it is important to test the application to verify it meets the business needs.  Many software products can simply this process.  User interface testing tools can validate that information entered by a user provides the expected results.  This is especially necessary when doing regression testing to verify changes to the application did not adversely affect something else.  Profilers can be used to identify areas of an application that should be addressed for optimization.

Ultimately, the application server is not the only software that runs in production.  Integration with databases and legacy systems requires the proper drivers.  Third party products such as XML parsers may also be needed although even these are becoming officially supported specifications as part of the next Java 2 release.  Lastly, investigate using a web server.  While J2EE applications provide a web container that can serve up static content like HTML pages and images they are not optimized for that purpose.  Front-ending an application with a web server can provide faster response for static content as well as simplify firewall configuration.

Summary

J2EE is not a silver bullet.  It will not solve all development problems and it is not right for every situation.  It will allow developers to focus on the organization differentiators instead of the complicated and error prone issues such as distributed computing environments and managing object transactions.  Furthermore,  because of the expense and the resources required to implement a J2EE solution it may not be the appropriate choice for smaller systems. 

Compared to other enterprise solutions, J2EE solutions reduce risk by offering a open and tested specification.  J2EE does not lock organizations into specific platforms (other than Java) or tie them to particular vendors provided they avoid those implementations that are proprietary or can be abstracted to mitigate dependence on a specific vendor.  By designing and implementing to the J2EE specification, organizations can choose the runtime environment that best meets their business and technical needs.

For a J2EE application to be successful there are three requirements, training, mentoring and modeling.  Furthermore, as I am sure you have heard with other technologies do not make your first attempt at J2EE a mission critical application.  Just as enterprise development is large and complex so is J2EE.