E++: A pattern language for J2EE applications, Part 2

Weave the design patterns together

1 2 3 Page 3
Page 3 of 3
  • IP security: The Internet Engineering Task Force's standard IP extensions provide security services at the IP level. IP security adds authentication, encryption, and data integrity services to the

    IP layer. This new standard is based on Virtual Private Networks (VPN), primarily used to secure a large organization with multiple Internet sites. Within a large organization, a VPN could provide acceptable communication security, provided repudiation is not an issue.

  • Secure Socket Layer (SSL): SSL has becomes a de facto standard to secure HTTP connections. SSL uses X.509 certificates for authentication. Based on your X.509 certificate and your communication servers' certificates, you resolve three of the four security requirements for Internet-based communications: confidentiality, integrity and authentication. (The fourth requirement is nonrepudiation, is addressed next.)
  • Digital signatures: The last security issue is nonrepudiation. A digital signature resembles a hand signature -- it is undeniable evidence of a document's origin because only the entity who has the private key can create the signature bit. To digitally sign an XML document, one has to first calculate the hash value of the document, and then use, for example, the Java Cryptography Architecture (JCA) API to sign or verify it. Any change (except whitespace) to a signed XML document will invalidate the digital signature. However, digital signatures usually require extra steps to prepare the document. Remember, different XML processors may produce different surface strings for the same XML document because of, for example, differences in character encoding.

Pattern name: Remote Wrapper Facade

Context

The dispatcher needs to register the related remote services, which have nonobject-oriented APIs.

The problem

How do you deal with a large number of nonobject-oriented applications?

The forces

You don't want nonobject-oriented applications to ripple through your carefully constructed distributed architecture, especially if that architecture must change and evolve over time.

The solution

You should avoid directly converting nonobject-oriented functionality. Instead, for each set of related functions and data, create one or more wrapper facade classes to encapsulate these functions in more concise, robust, and maintainable methods. Let the dispatcher register these wrapper facade classes. Examine the Remote Wrapper Facade's UML diagram in Figure 8.

Figure 8. The Remote Wrapper Facade

Pattern name: Proxy Adapter

Context

The dispatcher must register all the related remote services, which have object-oriented APIs.

The problem

It is inappropriate to register the remote services directly; you do not want to hardcode their physical locations and protocols. To the dispatcher, the remote services should be simple and transparent.

The forces

The remote access implementations should be runtime-efficient, cost-effective, and smart.

The solution

By leveraging your business domain knowledge and rule engine, your proxies can provide some intelligence to improve your application performance, load balancing, and cache information to improve access performance. In other words, you may put some business domain knowledge through ruleEngineController to turn the Proxy Adapter into smart adapters. In general, it's here where developers can improve application performance or security.

Pattern name: Prototype and Reality Bridge

Context

Your integrated business entities reside on remote computers. You need a strategy to connect them. You want to lower the integration surprise as much as possible.

The problem

How can you ensure a seamless evolution from prototype to real implementation?

The forces

When integrating remote business entities, you must ensure that:

  • The distributed communication protocols are verified with real network traffic situations
  • The integration time to real production systems is as short as possible

The solution

If you want to guarantee a seamless evolution from prototype to reality, you'll benefit from maintaining two coexisting implementations for any remote entity. Your prototype simulations provide required integration functionalities at the development phase without interrupting the existing operations, but provide you with real distributed communications. Any protocol or traffic-related nonacceptances should be resolved at this time with your prototype application. As for functionality, we need to leverage the Bridge pattern or common interface so that the swap will be easier.

Formula for success

I believe in the following formula:

a successful project = domain-specific business modules + a well-designed framework

A framework should be based on standard components; otherwise, your business-module development will be largely overwhelmed by learning adopted standard technology platforms as well as proprietary technology. The E++ framework moves us towards reusability, extensibility, portability, and customizability. Since the E++ framework is based on standard J2EE components, to integrate or leverage it you'll need only the J2EE developer guide. By leveraging design patterns and a rule engine, E++ builds an efficient, intelligent J2EE application framework. It improves an application's performance, network traffic, and object caching.

The major patterns presented here should serve as a starting point for your development efforts in E++. To reference all of E++ 1.0 beta's patterns, visit http://www.organizeknowledge.com.

A Sun-certified Java 2 architect and programmer, Bin Yang has been programming in C-like languages since 1988, with a dozen publications in computer simulations. He works as a Java/J2EE consultant with www.OrganizeKnowledge.com. His current interests are to add more design experiences and intelligence to J2EE/XML messaging applications to improve software reusability, distributed application performance, security, and network-traffic loads.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3