IT World

AKON

2007-08-04T09:28:00.001-07:00

Web security gateways meet rising malware threats

2007-07-12T21:37:00.000-07:00

By Neil Roiter, Senior Technology Editor
12 Jul 2007 | SearchSecurity.com

If your organization is like most, Web security gateways weren't high on your list of antimalware measures until pretty recently. Your attention to incoming Web traffic has focused largely on policy control--HR concerns over employee access to Internet pornography, gambling, etc., and productivity, as users spend disproportionate time shopping online and checking up on their stocks and favorite teams.

We're getting more work done and better efficiency on our network--speed improved dramatically.
Michael Dermer,
chief operating officer, Urology San Antonio

Anti-malware largely meant anti-virus and was pretty well controlled by email screening and desktop antivirus. While Web security gateways are attracting increased attention, desktop antivirus vendors are scrambling to reinforce their products with improved heuristics, host-based IPS and application controls. The antivirus vendors are responding to the rapidly shifting threats from email-borne viruses to Web-based malware designed to steal confidential data and identities and take control of corporate computers.

"What's changed and started the market heating up is Web component of malware," said Peter Firstbrook, a research director at Stamford, Conn.-based Gartner Inc. "Since the first quarter of 2005, Web-borne malware has grown 540%."

It's easy to see why. Web 2.0 is spawning new business opportunities with little consideration (surprise!) for security. Users who have been conditioned over more than a decade to be wary of suspicious email attachments can be more easily steered to a malicious Web site that can install a bot, Trojan or rootkit without alerting the victim. Criminal motive has replaced adolescent hubris, as the bad guys find profit in identity theft, fraud and stealing sensitive corporate data more lucrative than Internet graffiti or fast-moving worms.

The problem is as vast as the Internet. A recent year-long Google study led by Niels Provos calle "The Ghost In The Browser Analysis of Web-based Malware," found that 450,000 Web sites--at least 10% of those analyzed downloaded malware to unsuspecting users, and another 700,000 were suspect.

The problem is compounded because legitimate Web sites can be temporarily compromised and turned into drive-by download perpetrators.

Small wonder that organizations are showing a growing interest in Web security gateways.

"Our plan is for every entry port in our enterprise have zero day Web protection," said a wide area network program manager who uses Aladdin eSafe Web security gateway to protect the networks of a large aerospace and defense company. "We decided we needed more that URL filtering, which was the standard method of doing things through 2005."

URL filtering has approached commodity status. Gartner estimates that 75% to 95% of all enterprise networks employ it. Organizations see a quick return in user productivity and freed bandwidth.

"Unauthorized use of the Internet is totally jamming our pipeline, slowing business systems," said Michael Dermer, chief operating officer of Urology San Antonio, a group practice of 23 physicians and about 150 employees. "Administratively, we were hearing we need more staff and help, but it didn't seem the workload was increasing." Dermer said URL filtering from eSoft made an immediate difference.

"We saw an overnight change," he said. "We're getting more work done and better efficiency on our network--speed improved dramatically."

SOA, Web services security hinge on XML gateways:

SOA, Web services security hinge on XML gateways: XML security gateways could be the missing piece in most SOA deployments, says Tim Bond, a senior security engineer at webMethods Inc.

By contrast, Gartner pegs Web security gateway malware filtering at around 15% network coverage, this figure should increase significantly, with most vendors offering some combination of the components that Gartner uses to define the Web security gateway market--URL filtering, Web traffic malware detection and application control (IM, P2P, Skype, etc.). Gartner pegged the total market at about $700 million in 2006 and expects a 20-25% annual increase.

The Web security gateway market is an interesting mix of appliance and software vendors, each expanding on their primary strengths--URL filtering vendors like Websense and Secure Computing; traditional AV vendors like McAfee, Trend Micro and Sophos; IM control specialists like FaceTime and email security vendors such as IronPort (recently purchased by Cisco) and MessageLabs--by development, acquisition or partnerships. Newer companies like Mi5 and Anchiva suggest room for growth. (Gartner identifies Blue Coat and Secure Computing as market leaders in a June Magic Quadrant report for this newly defined market.)

Managed Web security gateway services are another option. Although the market is still young, vendors are starting to offer their technology as a service. ScanSafe, the first company to offer antimalware and URL filtering and IM control as pure-play services, actually scans all their customers Web traffic. It OEMs for companies like Postini and AT&T. MessageLabs, which initially sold ScanSafe-based services, now offers managed services based on its own technology.

Vendors and analysts say this is in large part a replacement market. Since most organizations are already budgeted for URL filtering, it's relatively easy to step up and add value at the web security gateway, either through new products or adding features to existing deployments. The pressure is growing, as the rapid development and deployment of complex malware outstrips the ability of any single technology to protect enterprises.

"We were proactive. We started seeing more and more alerts coming through as zero day threats," said the aerospace/defense manager, as he monitored feeds from Symantec's DeepSight services. He chose Aladdin because its packet inspection technology offered better zero-day protection than signature-based detection alone, but uses IronPort for email gateway protection. "We don't believe in too many eggs in one basket."

In fact, while there are compelling arguments for using the same vendor's products on the desktop and at the Web security gateway, best security practice may dictate deploying the widest range of coverage with different solutions.

"Malware detection is converging. It's all malware. Whether rootkit, adware or spyware, but malware is growing so fast and so diverse and so complex, no one vendor will catch it all," said Gartner's Firstbrook. "It needs to be from a different vendor; it's totally necessary--needs to be from different vendor. Each only knows what they know about."

In addition to protecting large enterprises, Web Security gateways make some sense for SMBs, which can add a layer of defense without necessarily beefing up security on every desktop. Gateway-based malware protection offers a single point of policy control and management. It's an alternative for companies feeling the pressure to upgrade their desktops to run the latest antimalware software, who can opt instead to wait until the end-of-life cycle runs its natural course. Specialized systems, such as medical devices that can't be updated easily, can be protected at the gateway.

"From cost perspective, I don't have to upgrade desktops; putting too much software on them affects performance," said Jay Wessel, vice president of technology for the Boston Celtics, who uses Mi5's Webgate. "It's a centralized place in which you can fix things quickly for everyone." That kind of control is important to small IT operations like his.

"I like things that live in my room better than things I have to put in anybody else's office," Wessel said.

Hacked By Godzilla - MS32DLL.dll.vbs - wscript.exe

2007-07-12T13:50:00.000-07:00

This is basically what Hacked by Godzilla - MS32DLL.dll.vbs - VBS.Zodgila do when it execute:
Creates the following files:[DRIVE LETTER]:\MS32DLL.dll.vbs[DRIVE LETTER]:\MS32DLL.dll.vbs[DRIVE LETTER]:\autorun.infNote: %Windir% is a variable that refers to the Windows installation folder. By default, this is C:\Windows (Windows 95/98/Me/XP) or C:\Winnt (Windows NT/2000).
Adds the value:“MS32DLL” = “%Windir%\MS32DLL.dll.vbs” to the registry subkey:HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Runso that it runs every time Windows starts.
Adds the value:“Window Title” = “Hacked by[REMOVED]” to the registry subkey:HKEY_CURRENT_USER \Software \Microsoft \Internet Explorer \Mainto modify title in Internet Explorer.
Attempts to copy itself to removable drives and create registry entries every 200 seconds.
Information above was taken from Symantec website.
If your computer affected by “Hacked by Godzilla - MS32DLL.dll.vbs” worms:-
Your Internet Explorer title will end with “Hacked by Godzilla”
You might not able to open any of your drive thru double click (you still able to open/explore using right click -> explore)
How to remove “Hacked by Godzilla - MS32DLL.dll.vbs” (VBS.Zodgila) worm?
Open Task Manager ( Right click on your taskbar and click “Task Manager” )
Click on Processes tab and select “wscript.exe” and click “End Process” button. (Remember to remove all wscript.exe)
Go to My Computer, Click on Tools -> Folder Options, click on View tab
Under Advance settings,check “Show Hidden files and folders“,uncheck “Hide extensions for known file types“,uncheck “Hide protected operating system files (Recommended)”and click “OK” button
Go to C:\WINDOWS or C:\WINNT and delete file MS32DLL.dll.vbs
Now go to all your drive in your computer, and delete autorun.inf and MS32DLL.dll.vbs including your USB Drive and Floppy disk. All the autorun.inf and MS32DLL.dll.vbs file is located at the root directory of your drive, ex: c:\MS32DLL.dll.vbs, d:\MS32DLL.dll.vbs …
To access your drive, Go to My Computer, right click on the drive and select “Explore”
Next we are going to clean your registry record. Click Start -> Run, type regedit
Go to HKEY_LOCAL_MACHINE \Software \Microsoft \Windows \Current Version \Run and delete MS32DLL (right click on it and select delete)
Now we are going to disable CD Autorun, Go to HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Cdrom look for Autorun and double click on it and enter 0 as it’s DWORD value
You can skip this steps if you do not wish to disable CD Autorun feature. But Hacked By Godzilla worm spread when CD Autorun is ON.
Go to HKEY_CURRENT_USER \Software \Microsoft \Internet Explorer \Main and delete “Window Title” which has it’s value of “Hacked by Godzilla“
Now go back to My Computer, Click on Tools -> Folder Options, click on View tab
Under Advance settings,uncheck “Show Hidden files and folders“,check “Hide extensions for known file types“,check “Hide protected operating system files (Recommended)”and click “OK” button
Empty your Recycle Bin.
Restart your PC and your PC should be clean from Hacked by Godzilla now

EJB

2007-07-12T05:15:00.001-07:00

EJB

EJB 3.0 specific features

General EJB features

EJB-aware coding assistance

Powerful EJB-aware refactorings

IntelliJ IDEA features rich support for EJB development. Supporting EJB specifications from 1.x to 3.0 and leveraging it through all its features, from coding assistance to refactoring,
IntelliJ IDEA stands for the weapon of choice for developing EJB applications.

IntelliJ IDEA leverages all EJB in the dedicated module type — the EJB Module, which lets you handle EJB and relevant objects (ejb-jar.xml and other descriptors, EJB security and EJB deployment settings, etc.) under one functional entity. This simplifies EJB applications development, debugging and deployment.

EJB 3.0 specific features

IntelliJ IDEA fully supports annotation mechanism for creating EJB, and Interceptors, with automatic code generation, completion and dedicated binding editor.

EJB persistence support is powered with generating of persistence mapping from entity beans, Hibernate or JDBC source and the visual Persistence diagram builder that lets you get the complete picture of how your persistence entities relate one to another.

Additionally, IntelliJ IDEA supports entity listeners and Embeddable Enterprise Beans.

For your existing EJB projects (versions 1.x and 2.x), IntelliJ IDEA provides the migration to EJB 3.0 that includes:

Converting EJB environment access
Rebuilding EJB deployment descriptors
Transforming EJB interfaces
Turning Entity Beans into Container Managed Persistence

to the top

General EJB features

IntelliJ IDEA eliminates routine work through generating stub code for entity EJB, session EJB, message EJB and other EJB types, CMP EJB fields and EJB relationships. Dedicated context editors also help modify EJB and their properties.

IntelliJ IDEA automatically builds standard EJB deployment packages either in JAR or exploded directory format and automatically generates appropriate EJB XML descriptors for all EJB included in the module (ejb-jar.xml).

to the top

EJB-aware coding assistance

IntelliJ IDEA leverages code completion for both EJB code and descriptor files and also supports

EJB error highlighting: IntelliJ IDEA continuously checks your EJB source code for EJB specification compliance, so that all possible inconsistencies are immediately detected and highlighted in the editor.

EJB intention actions and quick fixes: For most EJB errors detected in your code, IntelliJ IDEA will provide you with the ability to automatically correct the erroneous code by showing an intention action light bulb in the editor that expands into a list of possible corrections.

to the top

Powerful EJB-aware refactorings

All global refactorings, like Rename, Change Method Signature, etc., are aware of the EJB specification and will therefore correct all necessary references in your code so that your EJB structure is not broken. Refactorings also apply to all XML descriptors to ensure the total integrity.

JBoss performance testing

2007-07-12T04:42:00.000-07:00

JBoss Remoting Performance Benchmark Report

1. Overview

This performance benchmark report will cover three separate areas of performance related to JBoss Remoting. Section 3 (All transports - speed results will cover basic performance when making synchronous invocations from a single client to a server and will include results for (1) all of the JBoss Remoting transports, (2) two raw Java transports, and (3) two Spring Remoting transports.^[1] Section 4 (All JBoss Remoting transports - all invocation types) will cover performance differences among the various JBoss Remoting transports when making different types of client to server invocations (i.e. synchronous and asynchronous). Section 5 (All transports - scalability) will cover how well the JBoss Remoting transports, raw Java transports, and Spring Remoting transports scale as more clients are added.

This report is NOT intended to indicate how fast different transports are in absolute terms, but to compare speed and scalability of transports relative to one another. The tests were run on laptops and the results might not be indicative of performance levels achievable in a production environment. However, since all tests in each group were run on the same hardware, using the same environment and test scenario, the results should be sufficient for side by side comparisons. All the test result data are included at the end of this report along with instructions on how to reproduce the test runs in any other environment.

2. Terms

Since there is a limited amount of space within the graphs for full descriptions of the transports and test scenarios, the abbreviations are explained here.

socket_java: JBoss Remoting using the socket transport and default Java serialization
socket_jboss: JBoss Remoting using the socket transport and JBoss serialization
rmi_java: JBoss Remoting using the rmi transport and default Java serialization
rmi_jboss: JBoss Remoting using the rmi transport and JBoss serialization
http_java: JBoss Remoting using the http transport and default Java serialization
http_jboss: JBoss Remoting using the http transport and JBoss serialization
multiplex_java: JBoss Remoting using the multiplex transport and default Java serialization
multiplex_jboss: JBoss Remoting using the multiplex transport and JBoss serialization
raw_socket: uses straight Java Socket API with Java serialization
raw_rmi: uses straight Java RMI API with Java serialization
spring_rmi: Spring Remoting using the Spring rmi transport
spring_http: Spring Remoting using the Spring http transport

3. All transports - speed results

In the first performance test a single client continuously makes synchronous invocations on a single server. This test shows how quickly the transport can make remote invocations when not under load (basically showing raw data transfer speed). Three test runs were executed for each transport, and the averages are given in the following graph.

The graph shows that the JBoss Remoting socket transport with JBoss Serialization is able to make the largest number of requests per second, followed by the raw rmi and raw socket transports (which use the Java API directly and not a remoting framework).

4. All JBoss Remoting transports - all invocation types

The second performance test also consists of a single client making invocations on a single server, but the test runs span two dimensions: transport and invocation type. The transports exercised in this case are the JBoss Remoting transports, and the invocation types are the following:

Multi-threaded sync: uses 10 threads to make concurrent synchronous invocations from the client to the server. Is very similar in load to using 10 individual clients.
Async - client side: uses single threaded client to make asynchronous invocations from the client to the server. The calling thread will hand off the invocation to a client side pool of worker threads that make the actual client to server invocation.
Single threaded sync: uses single threaded client to make synchronous invocations from the client to the server.
Async - server side: uses single threaded client to make asynchronous invocations from the client to the server. The calling thread will make the actual network call to the server, where the invocation payload will be handed off to a worker thread pool where it will be picked up for processing.

The following graph indicates how long it took each JBoss Remoting transport to make 100,000 client to server invocations for each invocation type. The lower the time, the faster the combination of transport and invocation type.

The results show that the JBoss Remoting socket transport with JBoss Serialization was the fastest transport over all the different invocation types.

5. All transports - scalability

The final performance test is designed to indicate how well the various transports scale in response to increased load from additional clients. Each client uses a single thread to make 100,000 synchronous invocations on the server. The following graphs indicate the total number of invocations per second processed by the server as it services up to thirty clients. The numbers are averaged over three runs. For the sake of readability the results are partitioned by serialization type. ^[2]^[3]

Several phenomena may be observed in these graphs.

Since the cpu is kept at close to 100% utilization in these tests (except, perhaps, in the case of a small number of clients, depending on the speed of the hardware), the ideal in scalability would be for the total number of invocations processed by the server to remain flat as the number of clients increases, indicating that there is no overhead cost for additional clients. Nearly every transport/serialization combination shows the same pattern of an initial spike (until the cpu is saturated, presumably) followed by a gentle decline from 10 to 20 clients and a smaller decline from 20 to 30 clients. For example, the performance of the JBoss Remoting socket transport with Java serialization declines 6.6% from 10 to 20 clients and 3.2% from 20 to 30 clients. The most significant exception is the JBoss Remoting transport with JBoss serialization, which remains nearly flat as the number of clients increases from 5 to 30, decreasing by only 2.1%.
When using Java serialization none of the Remoting framework transports, JBoss or Spring, achieve the performance of the raw socket and raw rmi transports. However, the JBoss Remoting socket transport with JBoss serialization outperforms both of the raw transports at 10 clients and beyond.
The JBoss Remoting socket transport with Java serialization and the Spring rmi transport show almost identical results. The JBoss Remoting http transport with Java serialization and the Spring http transport show nearly identical results as well.
Among all of the Remoting framework transports, the JBoss Remoting socket transport with JBoss serialization is the clear favorite in these tests.

6. Test structure

All the performance tests run for this report have the same basic structure and most share the same base code (the most notable exception being the Spring Remoting http transport, which requires a web container for server side deployment). All tests have one or more clients, each of which starts by creating a callback server and then sending the total number of invocations it intends to make. The server will then create a call tracker that will manage the test invocations as they come in from that client, ensuring that all intended invocations are received without duplicates. The server will also create a client to call back on the callback server created within that client instance.

Once the client and server have been fully initialized with their initial configuration data, the client will begin its loop to make test invocations. The number of test invocations is configurable, but for this report, the clients each make 100,000 test invocations. The payload size for each invocation is configurable as well, but for this report will be approximately 1024 bytes (plus size of payload wrapper for each transport). The time it takes the client to make all its test invocations is the main result captured for this report. When the call tracker on the server side has received all the invocations from its associated client, it will call back on that client (actually the client's callback server) and send the number of test invocations it received and number of duplicate test invocations, if any. This will indicate test run completion from the client's perspective.

All the transport tests (except the Spring Remoting http transport) are executed using the JBoss JRunit test framework. This means that each test run can be executed within ant as a junit task, which will call on a JRunit test driver which will spawn one or more client test instances and a server test instance. All configuration information (as seen below) can be modified within the JBoss Remoting build.xml file and tests can be executed via running the JBoss Remoting ant script. All the performance test source code can be found within the org.jboss.test.remoting.performance package of the JBoss Remoting project. Everything needed to run all the transport tests are included within the JBoss Remoting project (except a web container, which is needed for the Spring Remoting http transport tests).

7. Testing environment

7.1. Speed test and invocation type test

The first two tests (speed test for all transports and invocation type tests) were run in the following environment.

Hardware: Dell Inspiron 8600, Intel Pentium processor 1.69GHz, 2GB RAM
Operating System: Microsoft Windows XP Professional (Version 2002, Service Pack 2)
Java Virtual Machine: Sun, Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)
Software:
- JBoss Remoting 2.0.0.GA
- Spring 1.2.8
- Tomcat 5.5.17 (for Spring Remoting http transport tests)
Test script configuration:
- numofcalls = 100000
- payloadsize = 1024
- numofclients = 1

7.2. Scalability test

The third test (scalability) was run in the following environment.

Hardware: Dell Inspiron 9400, Intel Core Duo T2400 processor 1.83GHz, 2GB RAM
Operating System: Microsoft Windows XP Professional (Version 2002, Service Pack 2)
Java Virtual Machine: Sun, Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
Software:
- JBoss Remoting 2.0.0.GA
- Spring 1.2.8
- Tomcat 5.5.17 (for Spring Remoting http transport tests)
Test script configuration:
- numofcalls = 100000
- payloadsize = 1024
- numofclients = 1, 5, 10, 20, 30

8. Test result data

The test result data including all the junit result files (in xml format) and the MS Excel spreadsheet used to capture raw result data, calculate averages, and generate graphs can be found within test_results.zip.

^[1]It was not possible to test the Spring Remoting hessian and burlap transports as the versions shipped with 1.2.8 of Spring do not support sending of Externalizable objects, which is what the test payload object implements.

^[2]The raw_rmi and raw_socket transports use only Java serialization. They are included in the JBoss serialization table to aid in comparison.

^[3]The spring transports use only Java serialization. They are included in the JBoss serialization table to aid in comparison.

JBoss Remoting Downloads

Business Rule Engine

2007-07-11T20:35:00.000-07:00

Article

Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications

By Qusay H. Mahmoud, July 26, 2005

For many mission-critical applications, the process of automating business policies, procedures, and business logic is simply too dynamic to manage effectively as application source code. Using business rules can help you develop more agile applications. The Business Rules Group defines a business rule as a statement that defines or constrains some aspect of the business; a business rule is intended to assert business structure or to control or influence the business's behavior. A rule engine evaluates and executes rules, which are expressed as if-then statements. The power of business rules lies in their ability both to separate knowledge from its implementation logic and to be changed without changing source code.

The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP) program, defines a Java runtime API for rule engines by providing a simple API to access a rule engine from a Java Platform, Standard Edition (Java SE, formerly known as J2SE) or a Java Platform, Enterprise Edition (Java EE, formerly known as J2EE) Java technology client. This article provides an overview of JSR 94 and discusses how to fit business rule technology into Java technology applications. Sample code gives a flavor of the effort involved in developing rule-based applications.

Introduction

Many business applications have to deal with the dynamic changes of market economics. For example, applications for use in the insurance and banking industries must be able to accommodate the inevitable market changes that no one can predict or plan for during design. A solution is to have a rule engine, which is basically a set of tools that enable business analysts and developers to build decision logic based on an organization's data. The rule engine applies rules and actions as defined by end users without affecting how the application runs. The application is built to deal with the rules, which are designed separately.

Examples of rule engines include Drools, Fair Isaac Blaze Advisor, ILOG JRules, and Jess, to name a few. The lack of standards, however, may be a major factor in deterring businesses from using rule-based applications. Most rule engines have proprietary APIs, making them difficult to integrate with applications. If a rule engine is no longer supported and the business decides to adopt another rule engine, most of the application code will need to be rewritten. JSR 94 is an attempt to standardize rule engine implementations for Java technology. The four rule engines mentioned earlier support JSR 94.

JSR 94 provides guidelines for the rule administration and rule runtime APIs, but it defines no guidelines for what language to use to define the rules and actions. Efforts are under way to standardize a common rule language, including the Rule Markup Language (RuleML).

Rule Engines

The underlying idea of a rule engine is to externalize the business or application logic. A rule engine can be viewed as a sophisticated interpreter of if-then statements. The if-then statements are the rules. A rule is composed of two parts, a condition and an action: When the condition is met, the action is executed. The if portion contains conditions (such as amount >=$100), and the then portion contains actions (such as offer discount 5%). The inputs to a rule engine are a collection of rules called a rule execution set and data objects. The outputs are determined by the inputs and may include the original input data objects with modifications, new data objects, and possible side effects (such as sending email to the customer).

Rule engines should be used for applications with highly dynamic business logic and for applications that allow end users to author business rules. A rule engine is a great tool for efficient decision making because it can make decisions based on thousands of facts quickly, reliably, and repeatedly.

The When, Where, and Why of Rule Engines

Rule engines are used in applications to replace and manage some of the business logic. They are best used in applications where the business logic is too dynamic to be managed at the source code level -- that is, where a change in a business policy needs to be immediately reflected in the application. Applications in domains such as insurance (for example, insurance rating), financial services (loans, fraud detection, claims routing and management), government (application process and tax calculations), telecom customer care and billing (promotions for long distance calls that needs to be integrated into the billing system), ecommerce (personalizing the user's experience), and so on benefit greatly from using rule engines.

Rule-based applications communicate with the rule engine by passing in the set of rules to be executed. Then, the application can inspect the results and either display them to the end user or perform further processing. The rule engine determines when to evaluate each rule based on the input required for the rule as well as the results obtained from the evaluation of previous rules. You do not need to specify the order or the dependencies of the rules.

In a Java EE enterprise application, for example, rules can fit into applications such as the following:

At the application tier to manage dynamic business logic and the task flow
At the presentation layer to customize the page flow and work flow, as well as to construct custom pages based on session state

Adopting a rule-based approach for your applications has the following advantages:

Rules that represent policies are easily communicated and understood.
Rules retain a higher level of independence than conventional programming languages.
Rules separate knowledge from its implementation logic.
Rules can be changed without changing source code; thus, there is no need to recompile the application's code.

These benefits, however, are not without cost. As with any tool, the decision to integrate a rule engine into your application should be based on cost versus benefits. The cost includes the learning curve and the effort involved in building an interface between the application and the rule engine. In addition, different rule engines use different format and syntax for defining rules. Therefore, if an organization decides to move from one rule engine to another, business analysts and developers must learn and understand the operation of yet another tool.

JSR 94

JSR 94 defines a simple API to access a rule engine from a Java SE or Java EE client. It provides APIs to

Register and unregister rules
Parse rules
Inspect rule metadata
Execute rules
Retrieve results
Filter results

Note that JSR 94 does not standardize the following:

The rule engine itself
The execution flow for rules
The language used to describe the rules
The deployment mechanism for Java EE technology

In other words, it doesn't standardize the semantics of rule execution.

JSR 94 Architecture

The APIs are defined in two main packages:

The Rules Administrator API: This API, defined in the javax.rules.admin package, provides classes that can be used to load rules and associated actions as execution sets. A rule execution set is a collection of rules. Rules can be loaded from external resources such as URIs, an InpuTStream, an XML Element, a binary abstract syntax tree, or a Reader. It also provides methods to register and unregister rule execution sets. This package can also be used to define the permissions on execution sets to provide access authorization.
The Runtime Client API: This API, defined in the javax.rules package, provides classes to be used by clients to run the rules and get results. Only the rules that have been registered using the Rules Administrator API are accessible. This API enables clients to acquire rule sessions and execute rules within that session.

The JSR 94 Expert Group made the decision to have two separate packages to reinforce the distinction between (1) executing a rule execution set that an administrator API has previously loaded and registered into the runtime environment and (2) the dynamic loading and execution of external resources (which can be performed only by using the Rules Administrator API). In addition, the separation allows a more fine-grained control of the user population, permitting some users to execute rules but not to administer them.

The Rules Administrator API

This API uses the RuleServiceProvider class to get an instance of the RuleAdministrator interface, which provides methods to register and unregister execution sets. The high-level capabilities of the administrator API are the following:

It acquires an instance of the RuleAdministrator interface through the RuleServiceProvider class
It creates a RuleExecutionSet from external serializable or nonserializable resources including
- org.w3c.dom.Element for reading from an XML subdocument
- java.io.InputStream for reading from binary streams
- java.lang.Object for reading from vendor-specific abstract syntax trees
- java.io.Reader for reading from character streams
- java.lang.String for reading from a URI
It registers a RuleExecutionSet object against a URI for use from the RuleRuntime.
It unregisters a RuleExecutionSetobject from a URI so it is no longer accessible from the RuleRuntime.
It queries the structural metadata of a rule execution set by retrieving a list of Rule objects from the RuleExecutionSet.
It sets and gets application or vendor specific properties on rule execution set and rules.

The Runtime Client API

This API provides access to vendor implementations of the Rule Engine API, in a way similar to Java DataBase Connectivity (JDBC) software. Vendors expose their rule engine implementations to clients through the RuleServiceProvider class. This class provides access to the runtime and administration APIs. The vendor provides a rule service provider URL that uniquely identifies the implementation. All rule service providers should be registered with a RuleServiceProviderManager object in order to be accessible to clients.

At the heart of this API is the RuleRuntime interface, which provides methods to allow clients to create a RuleSession used to run the rules. A rule session is a runtime connection between a client and a rule engine; it is associated with a single rule execution set and may consume rule engine resources, but the rule session must be explicitly released when the client no longer requires the rule session. Thus, the rule session does two things:

It provides a mechanism to access the list of all the rule execution sets registered with the rule service provider.
It defines the type of the session that client wishes to establish: stateful or stateless.

A statelessRuleSession works on a per-client request basis.
A statefulRuleSession is a dedicated session in which objects are not lost as long as the session is maintained between the client and the rules engine.

The Runtime Client API's high-level capabilities are the following:

It acquires an instance of a rule engine vendor's rule service provider through the RuleServiceManager class.
It acquires an instance of the RuleRuntime interface through the RuleServiceProvider class.
It creates a RuleSession through the RuleRuntime.
It gets a java.util.List of registered URIs.
It interacts with an acquired RuleSession.
It retrieves metadata for a RuleSession through the RuleExecutionSetMetadata interface.
It provides an ObjectFilter interface to filter the results of executing a RuleExecutionSet.
It uses Handle instances to access objects added to a statefulRuleSession.

The JSR 94 Reference Implementation

Because the JSR 94 reference implementation is built as a wrapper over the Jess rule engine, you will need Jess 6.1a3 or later in order to work with the reference implementation. Jess, which stands for Java Expert System Shell, is a rule engine and a scripting environment. Note that Jess is not freeware: It can be licensed for commercial use, and it is available for academic use. The JSR 94 reference implementation license is governed under the Jess license agreement. The Jess language and scripting environment evolved from the CLIPS expert system shell, which was initially developed by NASA. The CLIPS system language syntax and structure are similar to the LISP functional programming language.

To test the JSR 94 reference implementation, do the following:

Download the JSR 94 reference implementation and install it by unzipping the archive in a directory of your choice.
Download Jess. Once you unzip the archive, copy the file jess.jar from the Jess installation directory to the lib directory of your JSR 94 reference implementation installation.
Change the directory to lib under your JSR 94 reference implementation installation
Run the sample example using the following command:
java -jar jsr94-example.jar

If all goes well, you will see output similar to the following. This output was generated by the sample application that we will discuss next.

C:\jsr94-1.0\lib>java -jar jsr94-example.jar

Administration API

Acquired RuleAdministrator: org.jcp.jsr94.jess.RuleAdministratorImpl@9304b1
Acquired InputStream to RI tck_res_1.xml: sun.net.www.protocol.jar.JarURLConnect
ion$JarURLInputStream@c17164
Loaded RuleExecutionSet: org.jcp.jsr94.jess.RuleExecutionSetImpl@cd2c3c
Bound RuleExecutionSet to URI: RuleExecutionSet1

Runtime API

Acquired RuleRuntime: org.jcp.jsr94.jess.RuleRuntimeImpl@1d99a4d
Got Stateless Rule Session: org.jcp.jsr94.jess.StatelessRuleSessionImpl@7a84e4
Calling rule session with the following data
Customer credit limit input: 5000
Invoice 1 amount: 2000 status: unpaid
Called executeRules on Stateless Rule Session: org.jcp.jsr94.jess.StatelessRuleS
essionImpl@7a84e4
Result of calling executeRules: 2 results.
Customer credit limit result: 3000
Invoice 1 amount: 2000 status: paid
Released Stateless Rule Session.

Got Stateful Rule Session: org.jcp.jsr94.jess.StatefulRuleSessionImpl@1e51060
Calling rule session with the following data
Customer credit limit input: 3000
Invoice 1 amount: 2000 status: paid
Invoice 2 amount: 1750 status: unpaid
Called addObject on Stateful Rule Session: org.jcp.jsr94.jess.StatefulRuleSessio
nImpl@1e51060
Called executeRules
Result of calling getObjects: 3 results.
Customer credit limit result: 1250
Invoice 1 amount: 2000 status: paid
Invoice 2 amount: 1750 status: paid
Released Stateful Rule Session.

Sample Application

To get a flavor of the effort involved in using the Java Rule Engine API, Code Sample 1 shows an example that comes with the reference implementation; the output above was generated from this sample application. This example loads a set of rules from an external XML resource file. The source code is fully commented. This example demonstrates the life cycle of developing applications using the Java Rule Engine API, and it shows several usage scenarios.

Code Sample 1: RuleExample.java

public class RuleExample {

  // The rule service provider URI as defined by the reference implementation.

  private static final String RULE_SERVICE_PROVIDER = "org.jcp.jsr94.jess";



  /**

   * Main entry point.

   */

  public static void main(String[] args) {

     try {

        // Load the rule service provider of the reference implementation.

        // Loading this class will automatically register this provider with the

        // provider manager.

        Class.forName("org.jcp.jsr94.jess.RuleServiceProviderImpl");



        // Get the rule service provider from the provider manager.

        RuleServiceProvider serviceProvider =

            RuleServiceProviderManager.getRuleServiceProvider(RULE_SERVICE_PROVIDER);



        // Get the rule administrator.

        RuleAdministrator ruleAdministrator = serviceProvider.getRuleAdministrator();

        System.out.println("\nAdministration API\n");

        System.out.println("Acquired RuleAdministrator: " + ruleAdministrator);



        // Get an input stream to a test XML ruleset.

        // This rule execution set is part of the TCK.

        InputStream inStream =

            org.jcp.jsr94.tck.model.Customer.class.getResourceAsStream(

            "/org/jcp/jsr94/tck/tck_res_1.xml");

        System.out.println("Acquired InputStream to RI tck_res_1.xml: " + inStream);



        // Parse the ruleset from the XML document.

        RuleExecutionSet res1 =

           ruleAdministrator.getLocalRuleExecutionSetProvider(

           null).createRuleExecutionSet( inStream, null );

        inStream.close();

        System.out.println("Loaded RuleExecutionSet: " + res1);



        // Register the rule execution set.

        String uri = res1.getName();

        ruleAdministrator.registerRuleExecutionSet(uri, res1, null);

        System.out.println("Bound RuleExecutionSet to URI: " + uri);



        // Get a RuleRuntime and invoke the rule engine.

        System.out.println("\nRuntime API\n");

        RuleRuntime ruleRuntime = serviceProvider.getRuleRuntime();

        System.out.println("Acquired RuleRuntime: " + ruleRuntime);



        // Create a statelessRuleSession.

        StatelessRuleSession statelessRuleSession =

            (StatelessRuleSession) ruleRuntime.createRuleSession(uri,

             new HashMap(), RuleRuntime.STATELESS_SESSION_TYPE);



        System.out.println("Got Stateless Rule Session: " + statelessRuleSession);



        // Create a customer as specified by the TCK documentation.

        // Then call executeRules on the input objects.

        Customer inputCustomer = new Customer("test");

        inputCustomer.setCreditLimit(5000);



        // Create an invoice as specified by the TCK documentation.

        Invoice inputInvoice = new Invoice("Invoice 1");

        inputInvoice.setAmount(2000);



        // Create an input list.

        List input = new ArrayList();

        input.add(inputCustomer);

        input.add(inputInvoice);



        // Print the input.

        System.out.println("Calling rule session with the following data");

        System.out.println("Customer credit limit input: " +

             inputCustomer.getCreditLimit());

        System.out.println(inputInvoice.getDescription() +

             " amount: " + inputInvoice.getAmount() +

             " status: " + inputInvoice.getStatus());



        // Execute the rules without a filter.

        List results = statelessRuleSession.executeRules(input);



        System.out.println("Called executeRules on Stateless Rule Session: " +

             statelessRuleSession);



        System.out.println("Result of calling executeRules: " + results.size() +

             " results.");



        // Loop over the results.

        Iterator itr = results.iterator();

        while(itr.hasNext()) {

           Object obj = itr.next();

           if (obj instanceof Customer)

               System.out.println("Customer credit limit result: " +

                ((Customer) obj).getCreditLimit());

           if (obj instanceof Invoice)

               System.out.println(((Invoice) obj).getDescription() +

               " amount: " + ((Invoice) obj).getAmount() + " status: " +

               ((Invoice) obj).getStatus());

        }



        // Release the session.

        statelessRuleSession.release();

        System.out.println("Released Stateless Rule Session.");



        // Create a statefulRuleSession.

        StatefulRuleSession statefulRuleSession =

            (StatefulRuleSession) ruleRuntime.createRuleSession(uri,

             new HashMap(), RuleRuntime.STATEFUL_SESSION_TYPE);



        System.out.println("Got Stateful Rule Session: " + statefulRuleSession);



        // Add another invoice.

        Invoice inputInvoice2 = new Invoice("Invoice 2");

        inputInvoice2.setAmount(1750);

        input.add(inputInvoice2);

        System.out.println("Calling rule session with the following data");

        System.out.println("Customer credit limit input: " +

             inputCustomer.getCreditLimit());

        System.out.println(inputInvoice.getDescription() +

             " amount: " + inputInvoice.getAmount() +

             " status: " + inputInvoice.getStatus());

        System.out.println(inputInvoice2.getDescription() +

             " amount: " + inputInvoice2.getAmount() +

             " status: " + inputInvoice2.getStatus());



        // Add an object to the statefulRuleSession.

        statefulRuleSession.addObjects(input);

        System.out.println("Called addObject on Stateful Rule Session: "+

             statefulRuleSession);



        statefulRuleSession.executeRules();

        System.out.println("Called executeRules");



        // Extract the objects from the statefulRuleSession.

        results = statefulRuleSession.getObjects();



        System.out.println("Result of calling getObjects: " + results.size() +

             " results.");



        // Loop over the results.

        itr = results.iterator();

        while(itr.hasNext()) {

           Object obj = itr.next();

           if (obj instanceof Customer)

              System.out.println("Customer credit limit result: " +

               ((Customer) obj).getCreditLimit());

           if (obj instanceof Invoice)

        System.out.println(((Invoice) obj).getDescription() +

                   " amount: " + ((Invoice) obj).getAmount() +

                   " status: " + ((Invoice) obj).getStatus());

        }



        // Release the statefulRuleSession.

        statefulRuleSession.release();

        System.out.println( "Released Stateful Rule Session." );

        System.out.println();

     } catch (NoClassDefFoundError e) {

        if (e.getMessage().indexOf("JessException") != -1) {

           System.err.println("Error: The RI Jess could not be found.");

        } else {

           System.err.println("Error: " + e.getMessage());

        }

     } catch (Exception e) {

        e.printStackTrace();

     }

  }

}

The rules loaded in this example are part of the use cases that come with the JSR 94 Technology Compatibility Kit (TCK). The rules are written in Jess. If you are familiar with a functional programming language such as Lisp or Haskell then the Jess code will be familiar. Note that other rule engines, such as Drools, have adopted XML syntax for describing rules. Code Sample 2 shows the rules file.

The definition of a rule execution set is not within the scope of JSR 94. The implementation given in this file is written for the reference implementation. A rule engine vendor verifying its rule engine should modify this file to match the vendor's specific needs.

This rule execution set will be invoked by the TCK in a stateless manner.

The rule execution set must have support for the following business object model:

Customer class: The Customer business object is a simple business object that contains a name and credit limit property. The definition of this class can be found in org.jcp.jsr94.tck.model.Customer.
Invoice class: The Invoice business object is a simple business object that contains a description, amount, and status property. The definition of this class can be found in org.jcp.jsr94.tck.model.Invoice.

The rule execution set has the following definition:

It supports Customer and Invoice business objects.
It defines one logical rule.

Rule 1: If the customer's credit limit is greater than the invoice amount and the status of the invoice is "unpaid," then decrement the credit limit with the invoice amount and set the status of the invoice to "paid."

Note that additional physical rules may be defined to accomplish the requirements mentioned earlier.

The rule execution set has the following semantics.

Input:

A customer with a credit limit of 5000.
An invoice with an amount of 2000.

The rule execution should produce the following output:

The customer's credit limit is 3000.
The status of the invoice is "paid."

Code Sample 2: rules.xml





  RuleExecutionSet1
  Stateless RuleExecutionSet for the TCK for Jess

  
      (defclass org.jcp.jsr94.tck.model.Customer
          org.jcp.jsr94.tck.model.Customer)
      (defclass org.jcp.jsr94.tck.model.Invoice
          org.jcp.jsr94.tck.model.Invoice)

      (defrule rule-1
        ?customer <- (org.jcp.jsr94.tck.model.Customer
                           (creditLimit ?limit) (OBJECT ?C))
        ?invoice <- (org.jcp.jsr94.tck.model.Invoice
                           (amount ?amt&:(> ?limit ?amt))
                             (status "unpaid") (OBJECT ?I))
        =>
        (modify ?customer (creditLimit (- ?limit ?amt)))
;         (printout t "The credit limit of the customer is "
;                     (get ?C creditLimit) crlf)
        (modify ?invoice (status paid))
;         (printout t "The status of the invoice is "
;                     (get ?I status) crlf)
      )

Conclusion

Business rule technology provides a solution to manage dynamic business logic. You can use rule engines in both the application tier to manage dynamic business logic and in the presentation tier to customize the page flow. JSR 94 provides a vendor-neutral Java SE or Java EE interface to access a rule engine. You can create agile enterprise applications by combining Java EE and business rule technology, managing the business behavior outside the source code.

JSR 94 is an attempt to standardize rules engine implementations for Java technology. The specification provides guidelines on how to implement the Runtime Client and Rules Administrator APIs as well as guidelines on how developers can integrate a rules engine into an application by means of an API -- without limiting how rules and actions should be created or what language the developer should use.

As with any tool, the decision to integrate a rule engine into your application should be based on cost versus benefits. But as JSR 94 gains momentum, application servers may start offering JDBC-like support for multiple vendor implementations of the API, just as they provide support for multiple databases.

Useful Forums from BEA

2007-07-11T20:27:00.000-07:00

Exec2Exec for executive IT and line-of-business professionals.
IT2IT for IT management professionals.
Arch2Arch is the program for architects, by architects.
Dev2Dev is the program for developers, by developers.

Designing Performance Testing Metrics into Distributed J2EE Applications

2007-07-11T20:12:00.000-07:00

Introduction

In ancient computing times, a wise system architect once said, "you can't manage an application you can't monitor." In many cases, documenting the design for a new application, let alone how it might be monitored, is typically beyond the scope of the project. This article describes a reusable mechanism for capturing application-bound, performance statistics for highly distributed J2EE applications.

Applications essentially need to be engineered to support established service levels (i.e. Service Level Agreements). In some cases, SLA might be very granular, such as, stating the elapsed time expected to persist data related to a person. The architecture depicted in Figure 1 was implemented to handle an Internet order entry, including a self-service feature to allow a customer to update his own profile.

Figure 1. Distributed J2EE Architecture

Because of expectations of high order volumes, the application was engineered to provide distributed EJB transactions, which can be pooled and clustered for high availability and scalability. Highly distributed applications not only need to be engineered from a distributed object standpoint, but from a load balancing and clustering perspective, too. The architecture does not reflect load balancing and clustering implementation details.

This document describes a basic methodology for performance testing the distributed architecture. Essentially, the document describes the design and edits required to collect basic instrumentation/timing estimates for a distributed J2EE application.

The Distributed Architecture and Time Synchronization

The J2EE application relies on five tiers: a Web, EJB, EAI (Enterprise Application Integration), ERP (Enterprise Resource Planning) and DBMS tier. An Internet client makes an HTTP request to the Web tier and forwards the request over RMI/IIOP to the EJB tier. The EJB tier communicates with the SeeBeyond EAI tier using a SeeBeyond MUX e*Way . The EAI tier communicates with the Peoplesoft CRM (Customer Relationship Management) application within the ERP tier using a Peoplesoft adapter. Finally, The CRM application integrates with an Oracle DBMS over SQL*net.

A key part of any distributed environment is the time server. Within the methodology, instrumentation metrics are collected on the server where the code is executed, so it is important that all machines within the distributed J2EE architecture are time synchronized. Within the IBM AIX UNIX environment, the xntpd daemon sets the internal clock time on a machine. The service is used to synchronize time services with an external machine using the Network Time Protocol (NTP). Typically, there is a time server, which does not necessarily need to be another AIX or UNIX machine, within an organization's network that all machines synchronize with on startup. (In reality, machines with xntpd configured synchronize constantly, not just on startup.)

Alternatively, a machine can synchronize with an external time server on the Internet. The xntpd daemon defaults to off, so time settings, such as the IP address of the time server to synchronize with, needs to be configured within an ntp.conf file. Since instrumentation metrics are collected at the second or even millisecond levels, discrepancies between machines can lead to spurious performance statistics.

Object Specification and Instrumentation Behavior

The proposed J2EE architecture relies on a number of well-known design patterns, such as the Business Delegate (a.k.a. Proxy), Data Access Object, Model-View-Controller, Session Facade and Transfer Object (a.k.a. Value Object). A transfer object is a serializable class that groups related attributes, forming a composite value. In the architecture, the Transfer or Value Object is used as the return type of a remote business method, such as an Enterprise JavaBean. Fetching multiple attributes through the value or transfer object in one server roundtrip decreases network traffic and minimizes latency and server resource usage.

Figure 2 depicts the PersonValueObject, which implements IPersonValueObject and Serializable interfaces. The PersonWorkerBean uses a PersonValueObject for containing person and instrumentation attributes. Instrumentation attributes are long values, which contain a timestamp from calling System.currentTimeMillis(). The PersonValueObject also includes accessor methods for all attributes.

Figure 2. UML Class Diagram Value Object Specification (a.k.a Transfer Object)

While it is good OO practice to provide accessor methods instead of allowing direct manipulation of instance variables, it also increases overhead by imposing an additional method call. You want accessors to hide the implementation of get and set, and to allow subclasses to change the synchronization of a get or set, but there will be an overhead cost. Value objects can be sub-classed or they may have associations with other Value objects. For example, if requirements dictated that all Value objects in the application needed to be performance tested, refactoring instrumentation operations within a "FrameworkValueObject" would strongly be recommended. In this alternative specification to Figure 2, the PersonValueObject would extend the FrameworkValueObject and implement the IPersonValueObject interface; the IPersonValueObject interface would extend the IFrameworkValueObject interface. However, the operations listed in the IPersonValueObject would be the same as depicted in Figure 2 for either specification. The advantage to using this model is that all value objects would extend the FrameworkValueObject and therefore have instrumentation behavior; however, this is a complex relationship, and while correct from a UML (Unified Modeling Language) perspective, in and of itself would exert a performance cost to the application.

For value objects that have a direct association with other value objects, those relationships are implemented as class instance variables. UML recommends that for value objects that have an aggregation or composition association with other value objects, those relationships should be implemented as a Collection. A Collection is the root interface in the Java Collection hierarchy. A Collection represents a group of objects, known as its elements. This interface is typically used to pass collections around and manipulate them where maximum generality is desired. For example, a PersonValueObject contains one to many AddressValueObjects or a Collection of AddressValueObjects. However, this relationship is not included in the diagram, because it is not related to capturing timing estimates, but it is important to "real world" applications.

Instrumentation Data Collection Process

The objective of the methodology for this project was:

To estimate the total elapsed time to marshal and persist a PersonValueObject within middleware components.
To determine which tiers or key processes were the most expensive from a performance perspective and where optimization might be needed.
To be able to log timing estimates from multiple tiers in a single log file, which makes performance analysis and reporting simple.

Once the value object was wired for collecting instrumentation/timing, instrumentation edits were required in the J2EE and SeeBeyond application code. This required identifying the objects that would set timing estimates into the value object for the tier, and which object would be responsible for getting the estimates and writing them to a log file. The number of places in the code that timing metrics were collected was, in a way, an arbitrary decision. It was determined that the following objects needed to be reworked:

PersonWorkerBean on the Web Tier - would be responsible for setting timing attributes (that is, T1 and T6) on the PersonValueObject to determine total time spent marshaling the remote Session EJB from the Web tier, getting all timing estimates from the PersonValueObject and writing them to a single log file.
EJB SessionBean on the EJB Tier - responsible for setting timing estimates (T2 and T5) on the PersonValueObject to determine elapsed time spent on the EJB tier getting a connection to SeeBeyond and parsing the PersonValueObject into a delimited string for SeeBeyond processing.
PersonDAO (Data Access Object) on the EJB Tier - responsible for setting timing estimates (T3 and T4) on the PersonValueObject to determine total time spent on the EAI tier.

Architectural Limitations

The input for testing the application was generated using Mercury Interactive's LoadRunner via an HTML browser; this discussion, however, is out of scope for this report. Internet/network timing estimates, that is, download time from the HTTP server to the browser, are not collected through the value object; intranet download timing estimates must be imputed by estimating elapsed overall response time through LoadRunner minus PersonValueObject timing estimates collected in the framework_log4j.log.

The target of the log4j log output can be a file, an OutputStream, a java.io.Writer, a remote log4j server, a remote Unix Syslog daemon, or even an NT event logger, among many others. The performance of the log4j package is also quite good. On an AMD Duron clocked at 800Mhz running JDK 1.3.1, it costs about 5 nanoseconds to determine if a logging statement should be logged or not. Actual logging is also quite fast, ranging from 21 microseconds using the basic configuration.

It is important to point out that the purpose of the methodology is not memory and CPU application profiling as would be performed by tools such as JProbe from Quest Software or Optimizeit form Borland. The only tools that are engineered for distributed performance monitoring similar to the methology discussed here are PathWAI Dashboard from Candle Corp. and Introscope from Wily Technology.

Figure 3. UML Sequence Diagram - Create a PersonValueObject

A successful execution of the application from the Step 1 createPerson on the PersonWorkerBean to Step 23, writing the timing data to a Log4j log file would result in a single row that can be parsed into the following matrix. Timing estimates are collected in milliseconds. The table below is used to depict the elapsed time for processes within the application tiers, which is somewhat an arbitrary decision based on requirements. In effect, various permutations and combinations of processing times can be estimated, as long as the analyst/programmer has a solid understanding of the context of the timestamp captured. For example, 250 represents the total elapsed time marshaling the PersonValueObject from the Web tier through the entire application, whereas, the Incremental Elapsed Time Column is an imputed estimate for processing within tiers.

Implementation Details

Step 1: Implement instrumentation code edits for the IPersonValueObject Interface for the PersonValueObject Class (see Figure 2).

Step 2: Implement instrumentation code edits for the PersonValueObject Class (see Figure 2).

Step 3: Instrumentation code edits for the log4j.xml that sets priority level for application logging to the framework_log4j.log file. log4j relies on a configuration file for runtime settings. It also provides an ability to dynamically set the log levels (i.e. DEBUG, INFO, WARN, etc.).




debug="true">
        class="org.apache.log4j.FileAppender">

Step 4: Implement instrumentation code edits for the PersonWorkerBean (see Figure 3). The PersonWorkerBean logs the timestamps to the framework_log4j.log file by invoking a log4j.info method on a static reference to the Log4j Logger class. There are really two key classes: the PropertyConfigurator and Logger. The PropertyConfigurator.configure method is used to pass the location of the configuration file. The Logger is used to set the logging messages, the logging level and to identify which classes in the application you want to log errors for. The recommended pattern for extending the Logger class within Log4j is wrapping or creating a reference. It is strongly discouraged that users subclass either the Logger classes. Log4j provides an ability to (dynamically) set the log levels (i.e. DEBUG, INFO, WARN, etc.) or provide the level through a configuration file. By setting the level to "info", all messages of "info" and above will be written to the log file. Provided that the application does not throw any exceptions, there should be only one "info" message written to the file, which includes timing estimates for all middleware tiers.

Step 5: Implement instrumentation code edits for the PersonServiceSessionBean (see Figure 3). The PersonSessionBean create method receives a serialized copy of the PersonValueObject, sets the estimate into the PersonValueObject and calls the createPerson on the PersonDAO. In the model, the DAO is used to get a connection to the SeeBeyond EAI application server, and the PersonValueObject is not directly persisted into a DBMS. The point is, that in most J2EE applications, the Data Access Object pattern is used to specify how to persist data into DBMS.

Step 6: Implement instrumentation code edits for the PersonDAO class (see Figure 3). The createPerson method on the PersonDAO sends the PersonValueObject to the SeeBeyond application server using a MUX e*Way, a synchronous protocol. For this implementation, the PersonValueObject attributes where sent as a test message, because the SeeBeyond application server only supported text messages. The returning message from SeeBeyond, because it represented a string, not a PersonValueObject, needed to be parsed using a StringTokenizer. This edit for instrumenation code assumes that there are 3 tokens in the order in the format "Id^timeStamp1^timeStamp2." The Id is generated by SeeBeyond and represents the primary key for the PersonValueObject created.

The SeeBeyond application server provided timestamps for integration with the Peoplesoft CRM. SeeBeyond also returned the generated primary key, which would be required for persisting associated value objects, such as Address value objects. This is not modeled in the UML sequence diagram, because the central theme is how to collect timing estimates within disparate computing tiers.

protected IPersonValueObject createValueObject(
   String rs )
   {
       IPersonValueObject valueObject = null;
       try
       {
           valueObject = getPersonValueObject();
           if ( valueObject == null )    // create one
           {
               valueObject = new PersonValueObject();
           }
              StringTokenizer st =
                 new StringTokenizer(rs, "^");
              PersonPrimaryKey pk =
                 new PersonPrimaryKey(st.nextToken());
              valueObject.setPrimaryKey( pk);
              valueObject.setT3( Long.parseLong(st.nextToken()));
              valueObject.setT4( Long.parseLong(st.nextToken()));
                     }
       catch ( Exception exc )
       {
           printMessage("PersonDAO:createValueObject()-" +
                        exc );
       }

       return( valueObject );
   }

Architectural Implications

Ideally, the best design would allow for a ValueObject to be passed to all middleware tiers. SeeBeyond on the EAI tier actually has asynchronous support using JMS (Java Messaging Service) text messages, but not for JMS ObjectMessage type messages. Most implementers would prefer ObjectMessage type messages. For example, with an ObjectMessage type using JMS, the PersonValueObject would not have been parsed into a String object, but could have been sent directly to SeeBeyond . ObjectMessages - messages containing a serialized Java object - make it clear to programmers which data type and attribute they are receiving and sending. With support for JMS ObjectMessages, the PersonEAI object depicted in Figure 4 could have been implemented in SeeBeyond, which could have marshaled directly the PersonValueObject. For distributed object programmers, this is what it is all about -- transferring objects around the network.

Figure 4. View of participating classes for UML Sequence Diagram - Create a PersonValueObject

About the Author

Frank is a Lead Architect specializing in J2EE application design and implementation of enterprise-wide applications. He can be reached at frank_teti@hotmail.com.