BEA lays visual foundation for BPI

Regardless of whether your shop has standardized on J2EE, .Net, or other application paradigms, one of the most elusive and challenging goals remains that of automating business processes that cross application and system boundaries. To achieve success, developers with business process challenges often have to grapple with vendor-specific tools and technologies that don’t factor interoperability, performance, and scalability into the picture.

With its WLI (WebLogic Integration) 8.1, BEA addresses business process integration at sites where J2EE, Web services, and a variety of enterprise assets are used to support core business functions. In addition to addressing business process integration, WLI also strives to make J2EE development easier for junior- and senior-level programmers alike.

BEA’s WLI tools work in concert with the company’s WebLogic Application Server. For existing BEA sites that need a better way to tackle business process integration, WLI is well worth examining. However, for other shops considering WLI, the cost of BEA’s middle-tier technology stack application server must also be factored into the purchase decision.

Particularly innovative are the visual tools WLI provides to support business process integration. Developers (perhaps working in concert with business analysts) can use WLI’s drag-and-drop IDE to visually model business workflows using iconic representations of software components.

The overarching premise of WLI’s approach to business process integration is to enable the creation and use of controls that form the foundation of automated workflows. With this release, WLI supplies some basic controls, such as those that can be used to receive and respond to client requests, send and receive data, and process workflow based on Boolean conditions.

In addition, developers can create their own custom controls, and I found this task to be fairly easy. Nevertheless, until developers can spend more time focusing on implementing business workflow automation and less time concentrating on creating custom controls, the promise of WLI will remain largely unrealized. The more controls BEA and third party providers make available, the more compelling WLI will be.

In addition to basic controls, BEA supplies several adapters based on the JCA (J2EE Connector Architecture). These adapters work with enterprise applications such as SAP, Oracle Applications, and PeopleSoft in workflow automation. Beyond packaged applications, adapters are also available to support database interaction and integration with messaging systems, such as IBM’s WebSphere MQ.

Applying the glue

To gauge the effectiveness of WLI, I built two different business process workflows. The first involved a fairly straightforward set of integration tasks to process orders for widgets at a mythical manufacturer. The second process was a more complex set of tasks, involving the integration of data from multiple sources to process customer credit reports.

In both cases, I began by creating a new application in WLI. After defining the new application, the WLI IDE presented a blank design area along with panes to view my application components, controls that could be used in the application, a property editor, and a palette for defining data interaction.

In the cases of both my widget and credit report ordering processes, I needed to define multiple points of entry into the workflow. I began by dragging and dropping a client request control onto the design pane followed by controls that managed the processing conditions based on whether the customer had ordered via phone, fax, mail, or the Web.

After bringing controls onto the design pane, I was able to right-click on each control and define the actions and integration steps that would happen during workflow execution. For example, I defined processing conditions for customers who might order a single credit bureau report as well as for customers who needed a report that merged data from three credit bureaus.

WLI’s pre-fab controls support a few different types of integration. For example, integration steps in a workflow can read, write, and append to files, generate e-mails based on certain conditions, and interact with databases and JMS (Java Messaging Service). WLI’s application view control can interact with packaged enterprise applications via adapters.

Another feature, the transformation control, helps developers map data elements to support workflow processing. This control effectively pulled together the three different data sets of each credit reporting entity in my test environment. After right-clicking the control and defining the transformation, I used WLI’s visual transformation mapper to drag and drop data elements from the credit entities data set to the data set that I wanted to return to the customer.

Beyond adding basic workflow controls and defining data mapping, I also tried creating my own custom controls. For example, after defining the process to obtain a credit report from a single credit bureau, I saved that process as a custom control. I then reused the newly created control by dragging it into other points in my workflow where processing for the other two credit entities was being managed.

After defining a basic workflow, I right-clicked on my application icon and added some subworkflows. One of the- included the creation and inclusion of a Web service to check inventory as customers ordered widgets from my test manufacturer. Developers can easily expand workflows to include other processing forks, custom Java code, additional data transformations, and more.

Programmers who typically use graphical tools to speed up productivity rather than as an underlying development paradigm will find it easy to switch from WLI’s design pane and drag-and-drop visual toolset to source code by simply clicking on the “source view” tab at the bottom portion of the development workspace. BEA’s source code editor offers the typical features you might expect, such as syntax highlighting.

I also tried WLI’s debugging features from the source view and had no trouble setting breakpoints and stepping into and over code. Neatly complementing the debugging tools, BEA supports on-the-fly test harness creation. While debugging my applications, I tested them within the WLI interface, inclusive of starting the WebLogic application server and working with a generated set of pages to validate my code.

Visualizing J2EE

With this release, BEA makes some good strides toward simplifying J2EE development. BEA has also done a good job of documenting WLI and providing basic tutorials and samples that will help developers get moving. And newsgroup support for WLI is available. However, I found that during my evaluation, it took me a good bit of time to learn the WLI interfaces, tools, and overall working paradigm, which is a radical departure from the tools and interfaces that most J2EE developers are used to. Experienced J2EE developers and enterprise integrators who may be new to J2EE will need time to get up to speed with WLI.

In terms of enabling visual J2EE development, BEA’s closest rival at the moment is M7’s Application Assembly Suite. For BEA shops, WLI’s close ties to WebLogic Workshop and the WebLogic Application Server, together with the strength of its visual and source code editing and the quick Web services generation gives BEA a leg up on M7. However, for sites that want to enable graphical J2EE development for BEA WebLogic as well as other application servers such as IBM’s WebSphere, M7 provides a useful alternative.

Though it did take me a while to learn WLI’s way of doing things, the effort was worthwhile. After developers learn the WLI environment and have a greater number of controls available to them, BEA’s visual approach should significantly boost productivity. WLI’s graphical environment, combined with the level of workflow support that BEA enables, promises to make business process integration less challenging.