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

Weave the design patterns together

By Bin Yang, JavaWorld.com, 08/10/01

Page 6 of 6

As for application security, the client, which starts the scheduler, should first obtain authorization, implemented through either declarative or programmatic authorization. It is worthwhile to mention that you're starting a multithreaded process here; however, you're not creating a concurrent threads situation because of the thread scheduler's algorithm.

Figure 7. The Scheduler

Pattern name: Integration Rule Engine

Context

You want to automate your integration process and the integration business rule described in a text script, so that each B2BTaskHandler can consult with the Integration Rule Engine about how to conduct the actual tasks, and nonprogrammers can modify the rules.

The problem

When and how do you use a rule engine to help develop a more flexible integration solution?

The forces

The solution

You can pick from several options for embedding a rule engine in J2EE-based systems. JESS (Java Expert System Shell) allows rules to access any JavaBean's get or set methods as simple property values (see Resources).

In E++, I suggest you load a rule engine with RuleEngineController, which provides you with a RuleEngine instance, rule parser, and fact-assert functionality. The RuleEngine can be implemented as a stateless session EJB so that the container can handle any security issues. You define specific business rules in clp script. Each B2Bhandler uses one rule engine instance to fulfill its task. Therefore, you can define your working memory element (WME) to resolve conflict set (CS). The UML diagram is also shown in Figure 7.

Pattern name: Dispatcher

Context

You want to design a remote service dispatcher so that B2BTaskHandler can get services from it without being bound in any specific service implementation.

The problem

How do you design a dispatcher that dynamically loads or removes available remote services?

The forces

Even if the B2BTaskHandler or RuleEngine want specific remote services, they shouldn't need to know the services' locations. In case of any service failure or network problem, you could change the services dynamically.

The solution

The Dispatcher component acts as an intermediate layer between B2BTaskHandler and services. The Dispatcher implements a unique service name so the handlers can refer to services by a simple string name instead of their implementation details. The handlers rely on the Dispatcher to locate a particular service; the Dispatcher's registration maintains all the available services. As another benefit, Dispatcher provides methods so the administrator can add or remove services dynamically. One could think of having a daemon process running against the Dispatcher to update the list of available services.

The Dispatcher's UML diagram is shown in Figure 7.

Pattern name: XML DTD

Context

According to your business requirements, to communicate with backend services you need to use an XML schema to define your messaging.

The problem

Should you define your own XML schema?

The forces

XML's real strength will become apparent as more industries agree on standard schemas. However, due to competition concerns, numerous companies continue to define proprietary XML schemas. Moreover, XML does not define how information content should be structured. As a result, you'll face difficulties when dealing with business integration.

The solution

Because DTD schema design requires effort, in an ideal world you could adopt a well-accepted schema as your own. (I've provided links to preconstructed e-commerce schemas in Resources.)

If you cannot find a predefined schema to fit your needs, you'll have to develop one yourself. In that case, consider these points:

• How do you represent information for integration? Take as an example an order.xml in the TSP case from Part 1. To me, designing a good XML DTD is similar to designing a Java object. An order.xml attribute acts just like a private attribute in an Order.java object, such as orderId. The Order.java object contains several objects, such as credit card, billing address, order date -- these should be elements.
• In a serious integration application, XML transformation proves essential. As such, you shouldn't deal directly with any incoming XML responses from the backend systems. In that way, you carry your partner's specifications to your problem. You do want to transfer the schemas into your XML schema so your application handles only one DOM structure converted from the schema. As such, in case you need to integrate with new partners in the future, you won't have to change much. The Java API for XML Parsing (JAXP) 1.1 provides a standard way for an application to access any XML-conformant parser and XSLT-conformant processor.

Pattern name: Security

Context

You understand that to secure your communications with your business partners, you must address security.

The problem

TCP connections are subject to eavesdropping, spoofing, masquerading, false packet insertion, and packet modification. What level of security do you need to build trusted relationship with your business partners?

The forces

Your potential integration partners will be either within the same large organization or over the Internet, so you must address all possible scenarios to secure the remote method invocations or messaging communication.

The solution

Recent cryptography technologies can make your Internet communication acceptably secure. You can choose from several well-accepted security standards:

• 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.

About the author