Dr.Dobb's journal.2005.12

JSR 208 – Open and Extensible

SOA Infrastructure

Project Matrix is based on the JBI specification which defines four inter-related components that together provide a standardized service deployment framework.

•The Normalized Message Router (NMR) provides a protocol-independent communications backbone that routes “normalized” messages between service requesters and providers. The NMR

•Service engines (SEs) are containers for running services. SEs can exist for code, data transformations, or service orchestration languages such as Business Process Execution Language (BPEL).

•Binding components (BCs) provide a standard way to add protocols into the NMR. BCs bind normalized message exchanges to specific communication protocols like SOAP over HTTP or

Java Message Service (JMS) so services can send and receive messages to and from recipients and senders outside the JBI environment.

•Service assemblies define a standard way of packaging services together as a composite service or application, a single configurable unit for deployment.

Advertisement

TIBCO Readies JSR 208 Support for Java and .NET with Project “Matrix”

By now, most IT organizations recognize the need for a serviceoriented architecture (SOA) to promote the reuse of new and existing application functionality as “services” across their organization.

The key to SOA is a standards-based approach to the development, deployment and management of services—an approach that promotes and supports reuse and portability across multiple technologies and vendors. The industry is responding with widespread acceptance of Java Specification Request (JSR) 208, commonly called Java Business Integration (JBI), as the interoperability standard for SOA. JSR 208 is designed to provide portability, interoperability and greater choice

of services across JSR 208 compliant implementations, similar to what Java EE (formerly J2EE) provided for Java applications.

Presentation

Distributed

Architecture

Normalized Message Router

Enterprise Backbone

TIBCO has been actively involved with JSR 208 since the inception of the standard. Project Matrix is TIBCO’s response to this requirement for SOA interoperability. The release of Project Matrix will be a JBIbased service deployment platform that will enable IT organizations to assemble, deploy and manage JSR 208 compliant services developed by TIBCO, other vendors, and in-house developers. This service deployment platform will be available on a controlled availability basis in the first half of 2006.

What’s unique about this service deployment platform is that it will allow developers to deliver .NET, Java, Java EE or legacy system functionality as JBI-based services on a single distributed platform. As such Project Matrix will provide an extensible and technologyneutral foundation for SOA with the performance, reliability and scalability required for enterprise-class IT infrastructure.

JBI Infrastructure Powered by TIBCO’s Proven Technology

Project Matrix will enable companies to implement a scale-independent SOA by providing a fully distributed NMR implementation. This NMR implementation will be based on a proven distributed foundation— TIBCO’s messaging and Enterprise Service Bus (ESB) technology which is already being used as the infrastructure for SOA by thousands of customers around the world for some of the most demanding distributed systems. With Project Matrix, companies will be able to automatically deploy each service assembly’s services across multiple machines for truly distributed deployment.

Heterogeneous Service Hosting and Deployment

Project Matrix will provide SEs for hosting Java, Java EE or .NET-based code as JSR 208-compliant services. These heterogeneous services will be able to be packaged up as part of the same service assembly for distributed deployment. Project Matrix will also provide pre-packaged SEs, such as an XSLT transformation SE, to improve developer productivity. In addition, TIBCO BusinessWorks™ will be deployable as a service engine for orchestration and integration and will include BPEL support.

Enterprise-Wide Connectivity

Project Matrix will support a broad range of communication protocols including SOAP over HTTP, JMS, SOAP over JMS, and leading vendor messaging implementations deployed across the enterprise. Project Matrix will also enable the reuse of existing packaged and legacy applications by using adapters from TIBCO for over 150 off-the-shelf applications, databases and other software.

Support for Breadth of Technologies Including Portals and AJAX

Project Matrix gives developers their user interface (UI) of choice – including Portals, Java clients or .NET clients – through its support for Java, .NET, Web services and other standards. In addition, Project Matrix will include TIBCO’s rich client interface software called TIBCO General Interface™. TIBCO General Interface is a framework that enables developers to quickly and easily develop rich internet applications (RIAs) using the asynchronous JavaScript and XML (AJAX) capabilities present in Web browsers. TIBCO General Interface lets developers give services and composite applications the functionality and usability of desktop applications without the cost or hassle of deploying client-side software or plug-ins. TIBCO General Interface does this with robust component libraries, visual tooling, step-through debugging, automated memory management and other enterprise grade services.

Enterprise-Class Service Monitoring and Management

JBI establishes a standardized framework for the deployment of services, but not the ongoing monitoring and management of services. Project Matrix will leverage TIBCO Hawk®, TIBCO’s distributed monitoring and management framework to add key capabilities to effectively and efficiently monitor and manage services

on an enterprise scale. Project Matrix will add the support for monitoring and managing JSR 208 compliant services and JBI infrastructure, enabling end-to-end management of JBI-based services with existing technologies and integration with other system management software such as HP OpenView products and solutions.

Extended Functionality Through TIBCO’s Software

Project Matrix will extend the service deployment environment with functionality based on TIBCO’s comprehensive offering of business integration, business process management and business optimization software. For example, developers will be able to use TIBCO BusinessWorks to orchestrate services with other enterprise assets as part of automated activities and transactions or use TIBCO BusinessEvents™ to identify patterns and trends among streams of seemingly disconnected real-time events. They will also be able to monitor the operational side of service environments using TIBCO BusinessFactor™ for its business activity monitoring (BAM) capabilities, or present service interfaces in a personalized and secure environment using TIBCO PortalBuilder®.

For more information on Project Matrix, visit TIBCO’s developer Web site at: http://developer.tibco.com.

Advertisement

TIBCO Software Inc.

(NASDAQ: TIBX) is the leading independent business integration software company in the world and a leading enabler of real-time business, helping companies become more costeffective, more agile and more efficient. TIBCO has delivered the value of real-time business, what TIBCO calls The Power of Now®, to thousands of

customers around the world and in a wide variety of industries.

www.tibco.com

Global Headquarters

3303 Hillview Avenue

Palo Alto, CA 94304

Tel: +1 650-846-1000

Toll Free: 1 800-420-8450

Fax: +1 650-846-1005

This article contains forward-looking statements within the meaning of the “safe harbor” provisions of the federal securities laws. Actual results could differ materially form such forward-looking statements if demand for TIBCO’s products and services or economic conditions affecting the market for TIBCO’s products and services fluctuate or if TIBCO is unable to successfully compete with existing or new competitors. TIBCO assumes no obligation to update the forward-looking statements included in this article.”

©2005, TIBCO Software Inc. All rights reserved. TIBCO, the TIBCO logo, TIBCO Adapter, TIBCO BusinessWorks, TIBCO BusinessEvents, TIBCO BusinessFactor, TIBCO General Interface, TIBCO Hawk, TIBCO PortalBuilder, and The Power of Now, and TIBCO Software are trademarks or registered trademarks of TIBCO Software Inc. in the United States and/or other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. 10/05

Tackling big data-mining jobs with parallelization

ALEX DEPOUTOVITCH

AND ALEX WAINSTEIN

Data mining is the process of extracting information from large volumes of data. By its very nature, it is a computationally intensive exercise. Be-

cause data volumes are doubling annually (according to a Winter Corporation survey, http://www.wintercorp.com/WhitePapers/ TTP2003_WP.pdf), it can be difficult to achieve even small performance improvements simply by tweaking known datamining algorithms. Of course, sampling the input data can help, but you pay the price of reduced accuracy, which is unacceptable for many tasks. Increasing the power of hardware doesn’t offer much help; CPU clock frequencies and hard-drive datatransfer rates both have fixed upper boundaries, and no matter how much money you spend, you cannot overcome them.

While you cannot improve the speed of a single CPU, you can increase their

Alex Depoutovitch is the technical team lead and Alex Wainstein is director of technology and production at Generation5 Mathematical Technology. They can be contacted at alex.depoutovitch@generation5.net and alex.wainstein@generation5.net, respectively.

number. This is why multithreaded processor cores, multicore chips, and multiprocessor servers are becoming common. Although this leads to better performance, the total number of CPUs on a single server is still limited. Although today’s dual-CPU server price is reasonable, the cost of the 32-CPU servers can exceed the price of a private jet airplane. Still, there are networkbased alternatives which hold promise for high-end data mining, foremost among them “computing grids” that enable cooperative processing of single or multiple tasks by different computers.

The term “computing grid” designates a group of connected computers that combine resources to work together, appearing to users as a single virtual computer. The main difference between “grids” and “clusters” is that computing clusters usually contain only homogenous computers, whereas computers in a grid may have totally different hardware and software configurations.

There are two ways you can use computing grids:

•To evenly balance incoming requests among individual computers so that each request is served by one computer.

•To speed up the processing time of incoming requests by executing each of them in parallel on several computers in a grid.

Computing grids have centralized or decentralized scheduling. With centralized scheduling, a dedicated computer distributes requests and collects results. Decentralized scheduling, on the other hand, involves a cooperative process

among computers in a grid. Decentralized scheduling provides better availability and fault tolerance, but produces more network traffic, is less flexible, and more difficult to implement.

“Designing parallel algorithms is a complex procedure”

G5 MWM Grid from Generation5 is a data analytics application that lets you build and manage computing grids specifically for data-mining tasks. G5 MWM Grid achieves considerable performance improvements by executing various datamining tasks on a computing grid in multiuser environment.

G5 MWM Grid, which uses centralized scheduling, consists of the components in Figure 1. The Central node is responsible for the scheduling and coordination of processes running on the Calculation nodes. There is only one Central node in a grid. Users prepare “jobs” and communicate with the Central node through grid client software (Figure 2). The client software lets users monitor and control job execution progress and

on each node on which chunks are processed. In this case, data access speed is no longer a limiting factor for scalability. Even when some data must be updated by several nodes, it often is possible to do it without synchronizing access. For example, consider a situation when you need to calculate the average value of some array using a grid of n calculation nodes. You can divide this array into n equal chunks. Each node will be given its chunk and calculate the sum of values in this chunk and report back to the Central node. After all nodes are finished, the Central node sums up all received values and divides by the array size. This way, you avoid any data that must be shared between nodes.

With this in mind, requirements for parallel algorithms include:

•Avoid parallel chunks that depend upon the results of other chunks.

•Shared data access must be minimized (especially write access).

•Message passing between the Central node and Calculation nodes must be minimized.

Parallelization of Data-Mining Algorithms

In data mining, “prediction” is the task of producing unknown data values based on some previously observed data. Input data for prediction is divided into two parts — one containing training data and the second containing target data that you need to predict. Both parts have the same columns (variables). Variables are divided into two groups (Figure 4): independent and dependent. Independent variable values are provided in both training and target parts, while dependent variables are known only in the training part. The goal is to predict dependent variables in target data. There are many prediction methods available, including:

•Decision trees in which you process training data to receive a set of rules such as: “if age more than 30 and income more than 90K and number of children less than 2, then most probable car of choice would be Mercedes”. Using these rules data is predicted.

Figure 4: Data for prediction.

•Linear regression, which is based on training data you build and linear formulas to calculate dependent variables in target data using independent variables.

•Nearest neighbor method. This method, by maintaining a dataset of known records, finds records (neighbors) similar to a target record and uses the neighbors for classification and prediction. This method is memory-based and requires no model to be fit.

The first two methods require lots of preparation time and cannot be parallelized without making big changes in their algorithms. However, the third method is attractive because you can do minimal preprocessing and predict each record independent of others, so no modification is needed. With real-world problems, the number of records varies from thousands to hundred of millions. This method is particularly well suited for scalability.

The algorithm is described like this:

1.Divide the target data into the desired number of nonoverlapping chunks. The number of these chunks must be great enough to take advantage of all the computational nodes available. On the other side, the chunks should be big enough so that the scheduling and preprocessing overheads are not significant compared to single data chunk processing time.

2.Copy training data to each Calculation node.

3.Process training data on each node.

4.Assign a chunk of target data to each Calculation node and perform predictions against the assigned chunk.

Feature selection algorithms are used to determine the minimal subset of variables upon which the variables of interest depend. Currently, we do not know

Figure 5: Workflow in the Central node.

(1) job request from client is authenticated; (2) request is submitted to Scheduler; (3), (4) Scheduler asks Job Splitter for next chunk; (5) chunks are sent to Calculation node; (6) upon chunk completion, chunk results are submitted to Results Summarizer; (7) Results Summarizer checks with Scheduler, and if all chunks are finished, it submits results back to client.

In addition to priority, a job may have the maximum number of PUs available for a particular job, which means that the job will have no more than the specified number of chunks executing in parallel. In this case, if you want some job to finish by a fixed time, you make its priority higher than other jobs and limit the number of PUs available for it. This way, a fixed set of resources is secured for the job.

All communication between the client software and the Central node, as well as between the Central node and Calculation nodes, are done using SOAP. The underlying transport protocol is the Windows implementation of named pipes. It is a message-oriented protocol with guaranteed delivery and integrated authentication. Our original implementation was one named pipe using the “pull” approach. Thus, when the client wants to refresh its information, it queries the server about its current state (from the point of view of the Calculation node, the Central node is the client because it sends commands). But this approach turned out to be inefficient and not too scalable as the number of Calculation nodes increases: The delays with response were dozens of seconds when the number of nodes exceeded 10. Whenever the user needs to see a complete picture of the cluster state, it issues a request to the Central node; and the Central node sends requests to all Calculation nodes, waits for answers, and then sends a summary back to client.

Because of this, we implemented a new “push” approach so that whenever the state of a Calculation or Central node changes, it fires off a notification for interested parties. This proved to be effective and produced no noticeable delays, but required the use of two pipes — one for commands and responses, and one for asynchronous events. These events include completion of a chunk or job, cluster configuration change, and so on.

This architecture resembles DCOM, but it has the advantages of being an open, high-level protocol that is easily extensible and does not require complex configuration. For convenience, the SOAP protocol implementation can be hidden behind COM or C++ classes.

Results Summarizer

The Results Summarizer implementation depends on the data-mining task. In any case, it is crucial to provide shared storage (such as a database server or shared disk). For example, with prediction, the Summarizer uses a database server hosting the target data to update it from different Calculation nodes. With feature selection, the results for each chunk are

stored in the filesystem at a shared location, and after all chunks are done, the results are consolidated into the final report. Because it is not known in advance on which node the job will execute, each should have access to the shared storage.

Because there’s always a risk that one computer in the grid will fail, the G5 MWM Grid provides a way to recover from this situation. In case of a node failure, it removes the defective node from the grid and transfers the task to another node to redo, whenever possible.

The new nodes can be dynamically added to and removed from the grid. Adding is straightforward: After registration through the UI, it immediately becomes available to the Scheduler. The removal is more complex. If the node is idling, it can be removed immediately upon request. However, when some of its PUs are occupied by the task, no more tasks will be assigned to it and it will be removed upon completion of all tasks currently being executed.

Performance

To evaluate performance and scalability of G5 MWM Grid, we executed several prediction projects on a grid with a number of Calculation nodes varying from 1 to 10. We used two different sets of data (Model 1 and Model 2) that differ by size of training and target datasets, and the number of variables. All parameters are listed in Table 1. The speed of execution is measured in predicted values per minute. We calculated it with a different number of Calculation nodes in the grid. Computers that we used were singleCPU 1-GHz Pentium III's workstations running Windows 2000 Professional. The Central node and the database shared one Pentium 4 1.8 GHz. The computers were on 1-GB network.

The results are summarized in Figure 7 and demonstrate the nearly linear scalability. It does not show any sign of saturation. Our measurements showed that the average CPU load on the Central node was around 30 percent and the network utilization under 5 percent, meaning the grid size can still be increased several times, even with hardware that can be found in any office.

Model 3 (see Figure 7) was used for the high-end benchmark. The grid was implemented with six Calculation nodes, each equipped with dual Intel Xeon 3.0- GHz CPU on the 1-GB network. The database server was a 2.4-GHz quad-CPU server. In this configuration the grid was able to predict 15 million values in 5 hours, at the rate of around 50,000 predicted values per minute. Without grid technology, a similar performance can be achieved by using a million dollar’s worth of main-

Figure 7: Scalability testing.

frames. The G5 MWM Grid did that on less than $100,000 worth of hardware.

Conclusion

Computing grids bring many advantages to data mining. This is because data-mining applications are particularly resource hungry; the amount of data available (and so the computational power required to process it) continues to grow exponentially.

In an attempt to improve accuracy, the algorithms become more complex and require even more computational power. And grid computing provides the computational power required. Because many data-mining tasks can be effectively parallelized, the grid is their natural execution environment.

DDJ

“SQL Compare and SQL Data Compare synched 30000 product lines and the 12 associated tables in less than 20 minutes -

a task that takes the best part of a day manually!!! Go try it and buy it NOW”

Paul Cooke, Bortec IT

“I am literally staggered at how much more efficient it is to perform simple data transportation with SQL Data Compare. In some cases, it is up to 10 times faster with SQL Data Compare than it would be with DTS”

Nick Stansbury, SAGE Partners

“one of the best third-party software tools we have ever seen”