HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Yes, Virginia, there are still people who think you can build a complex B2B e-commerce Web site using HTML. The good news is, these people are mostly harmless; they'll learn the error of their ways quickly and probably before their projects are too far down the road. There are far more insidious and dangerous misconceptions out there in the IT world regarding e-business systems.

At this point in Web history most of us know that an effective e-commerce site isn't brochureware, nor can it be built with client/server technology. Many businesses have chosen to base their Web commerce systems on J2EE (Java 2 Platform, Enterprise Edition) and its EJB (Enterprise JavaBean) components, as J2EE is intended to be a complete platform for Web-enabled, multitier, secure, transactional Java applications. J2EE promises better quality, maintainability and portability of systems. With the popularity of J2EE a number of vendors are offering application servers, e-commerce platforms aimed at providing object execution engines, transactional control, security and other services. These products help separate business objects from presentation logic so sites can assemble content dynamically, and content and business rules can change in real time.

No more tedious infrastructure development for us, right? We can now revel in our choices of application servers that package these and other commerce services. Well, here's the rub: all application servers aren't created equal. Despite J2EE standardization, there are still profound differences in the capabilities and scalability of these systems.

B2B Application Servers for the Discerning Designer
Most of the application servers on the market today were designed for early e-commerce Web sites that were shopping-oriented or CRM-oriented. Transactions were usually simple, and often the greatest challenge was getting personalized content to a browser. Today businesses are looking to build complex B2B systems in which transactions are more precise, applications more diverse and performance more critical. Look at the requirements and characteristics of a digital exchange, a typical B2B e-business system (see Figure 1).

Figure 1
Figure 1:
  • The system must tie together information, such as product catalogs from many suppliers, and applications, such as order management, scheduling and auctions, in real time.
  • The site must implement complex business rules to customize and secure business transactions between customers and suppliers.
  • It must scale to service thousands of concurrent customers initiating complex transactions with information drawn from hundreds of partners and suppliers.
  • The development team can't rely on prepackaged software to provide the complex business rules, sophisticated transaction control or flexibility required by the application.
  • Competitive advantage comes from nonstop performance and availability. The application can't be taken down for updates, performance tuning, system reconfiguration or system failure.
When selecting application servers for complex B2B systems, designers need to look beyond all the happy hype and ask vendors some hard questions:
  • How flexible is the server's application model? Does it support more than just EJB applications so it can more easily integrate other internal and external business systems?
  • How scalable and available is the server? Does it support the kind of nonstop, high-speed, high-volume service required by complex B2B applications without unnecessary hardware, software or administrative costs?

  • How flexible are the security services offered by the product? Do they include multilevel access control that can change dynamically?
  • How well integrated are all the services offered by the product? Are they patched together by the vendor through recent acquisitions (meaning you may end up doing the real integration), or was the system designed from the ground up so that services work together in a reliable, consistent way?
The answers to these questions may determine whether designers enjoy accolades or massive headaches a few months down the road.

Universal Application Models
Above all, B2B Web sites must be flexible. You need an application server that supports easy integration and deployment of diverse application models.

Consider our digital exchange company example (see Figure 2). Already this application combines several architectures into one application or set of components: EJBs, CORBA objects, JSPs and servlets. A common, well-integrated environment is crucial for success. But there are more integration challenges ahead. Today this system does daily batch loads from affiliate catalogs; when prices change from one day to the next, the company absorbs the cost differences. In the future this company's goal is to integrate with supplier systems to update prices in real time.

Figure 2
Figure 2:

Integration like this calls for an application server that supports a diverse set of applications and requirements. Such a server must be designed for heterogeneous business environments:

  • It must be Java-centric, not just EJB-centric. Business objects may be written in pure Java and accessed through EJBs, but they should also be accessible through CORBA wrappers, RMI (Remote Method Invocation) or other methods.
  • XML parsing and support should be built in so the application server can integrate quickly with existing business systems and take advantage of standard XML APIs developed by various vendors and standards organizations.

If you employ multiple application models in your system mix, the problem of deployment becomes more complicated. Thus the application server should also include a universal deployment model that can be used to deploy EJB, CORBA and Web/servlet applications. Standardized XML-based deployment descriptors can be used for each application model, forming the basis for a common deployment process.

Comprehensive Scalability
Scalability can make or break an e-business strategy, yet this aspect of application server performance is often taken for granted in the decision process. Application server architecture makes a profound difference in application performance; problems often surface after a site is live, causing interrupted service, embarrassment and lost revenues.

For complex B2B sites we need to define scalability more broadly than in the past. To be scalable, a system must include the ability to handle peak loads in terms of users, information and transactions, and to maintain service and performance through resource failures, maintenance and upgrades.

Cost-Effective Scalability
In its quest for scalability the J2EE world has embraced clustering, the use of shared redundant resources as a solution. But early J2EE clustering architectures have focused mainly on failover, with limited gains in scalability. Early clustering architectures offer a single JVM per host machine and keep clusters of these limited application servers in sync at the cost of duplicate hardware and increased system administration. As the load increases, these systems must be taken offline to add more hosts, gaining marginal scalability at the cost of availability.

In assessing the scalability of an application server, look for these architectural features:

  • A multi-VM architecture, with intelligent, multilevel load balancing that matches processing needs for specific operations to Java VMs configured to meet those needs, optimizes application performance and scales further on a single platform. Multi-VM application servers can cost two to 10 times less than single-VM servers in a deployed, high-volume Internet commerce site.
  • A transactional, distributed object cache that can maintain data integrity efficiently for shared objects across VMs, multiple servers and multiple heterogeneous databases is critical for distributed B2B environments.
  • A persistent object store can be a performance plus in an application server by providing transparent persistence for Java objects to minimize object-to-relational translation for in-process data and support for distributed, heterogeneous transaction control.

Availability Beyond Failover
We often confuse high availability with system failover. In some application servers system-level failover is the main availability mechanism; hence, the definition fits. However, mature products offer more efficient failover mechanisms and higher overall availability.

Many systems failover only at the hardware server level. Look for an application server that fails over at the level necessary to maintain service (VM, server, host), reducing the need for expensive hardware redundancy. Look also for tools and features that allow administrators to expand and adapt the e-commerce system without interrupting service. You should be able to add new functionality to your site without taking the Web site, application, application server or hardware server offline. Upgrades or completely new applications should be deployable remotely without downtime.

A highly requested feature of some application servers is the ability to deploy a new version of an application with the same name on the same host while clients are still executing the prior version. New clients are automatically given the new version to use the next time they log in, so upgrades are painless for everyone involved.

Pluggable, Dynamic Security
A complex B2B site requires full-power security at all levels: user accounts, applications and methods, and wire security. Look for application servers with pluggable interfaces for authentication and encryption protocols. These will let you use the latest Java-based security technologies without your having to rewrite or update your applications. For method-level protection look for application servers that offer ACLs (Access Control Lists) for fine-grained and dynamic security.

Pluggable PKI Authentication
Authentication is the process of properly identifying people and things. When a user requests access to your system, the application server must validate his or her identity. Multifactor authentication is ideal (see Figure 3). In this approach authentication is based on some combination of who you are (name, user account name), what you have (driver's license, digital certificate) and what you know (mother's maiden name, account password).

Figure 3
Figure 3:

User accounts and passwords are already available so a pluggable interface for digital certificates completes the multifactor authentication strategy. PKI (Public Key Infrastructure) is a very strong and versatile authentication mechanism by which certificates are managed and passed to systems and their users. A certificate represents that user throughout the system. The principal (X.500 name) that's attached to the certificate can be associated with a particular VM execution thread, providing a single sign-on by authenticating the user throughout the entire user session.

ACL-Based Authorization
Authorization is the process of determining what actions a user can take and the resources he or she can access. Your application server should allow or deny access based on authorization policies defined by your business requirements.

ACLs are a flexible way of implementing authorization policies. They're objects that can be associated with any application in the system down to the method level, and they allow you to dynamically modify the permissions for any particular user or group. They're explicitly checked by the application being run by the user. When a user or principal attempts to access a system resource, such as an object method or a component, access is authorized or denied based on ACLs associated with that resource. ACLs can also be associated with a named context in a naming service.

Pluggable SSL Wire Protection
Secure over-the-wire communication is essential for sensitive data transmission such as a funds transfer. As with PKI technology, a pluggable interface will allow you to select the SSL provider that best fits your security needs without changing application code.

Avoid the Pain, Go for the Gain
Okay, so the vendor you're considering has assured you that their application server has all the features you need: a flexible deployment model, scalability to last a lifetime and security enough to satisfy the most demanding paranoid user. Your final question should be, "What do I have to do to get all this?" Do you have to somehow integrate the content services with the business rules engine? Do you need to spend months of developer time adding a nonobject-oriented TP monitor to get distributed transaction control or figuring out how to implement the workflow you need? As far as possible, find an application server that incorporates all the features you need out of the box, either by itself or through true technical relationships with its partners.

Finally, remember that experience counts. Scalability starts with technology but is realized through design. So find a vendor with a proven track record of designing scalable, distributed business systems. They'll help you build an e-business platform that will take you from your first Web application through enterprise and inter-enterprise integration.

Author Bio Anita Osterhaug, a member of the Advanced Application Architecture Team (A3T) at GemStone Systems, Inc., has 19 years of experience in high tech. She's also a professional technical and business writer.
Anita can be contacted at: [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.