Web services creation made easy

Beta of BEA WebLogic Workshop 8.1 insulates developers from J2EE trials and tribulations

BEA WebLogic Workshop is a combination development/run-time environment, very much in the spirit of IBM's WebSphere Application Developer. But WebLogic Workshop exclusively generates J2EE applications, and it operates at a dizzying level of abstraction compared with similar tools. Whereas J2EE was all about abstracting low-level entities such as database rows and message queues, WebLogic Workshop is all about abstracting J2EE.

The premise is sound. The density of J2EE APIs is daunting, so why not make a tool that allows the developer to concentrate on request/response conversation content, database access, and business logic, then let the tool worry about conversation structure and protocol, EJB deployment descriptor syntax, the ocean of API method calls, and so on? Such is the aspiration of WebLogic Workshop.

It succeeds reasonably well. I found I could build a complete J2EE application without once making face-to-face contact with an EJB or a servlet. The Workshop allowed me to work on the inside -- where everything important was happening -- while it took care of the outside, the interfaces, and the connections. It was a relief to create a J2EE application without having to enter the maze of J2EE documentation.

Zeroing in on Web services

WebLogic Workshop focuses its capabilities on the creation of Web services and Web services clients. The Workshop includes a development-server version of the WebLogic application server, so services and clients can be tested virtually the instant they're created. The Workshop includes a kind of test-bed browser that allows you to exercise a service even before a client has been built.

The Workshop's power derives from two bits of magic: one conjured in the development phase, the other at execution time. In the development phase, the magic is Javadoc annotations -- formalized comments that season IDE (integrated development environment)-generated source code. These annotations are read by the run-time framework prior to application deployment and guide the instantiation of infrastructure plumbing in the form of EJBs (plus an incidental servlet) that support all the nonbusiness-logic behavior of a Web service. This instantiation occurs only when you're developing and testing from within the Workshop. You must perform a separate, explicit compilation to create an EAR (Enterprise ARchive) for deploying on a production server.

At execution, the magic is the Java Workshop's run-time framework, a container riding atop WebLogic application server and hosting infrastructure EJBs. Each EJB is responsible for a specific set of Web service support activities. These infrastructure beans are assisted by a servlet and a message-driven bean, the former accepting HTTP requests for Web services and the latter accepting requests on incoming JMS (Java Message Service) message queues. At all times, the developer is blissfully unaware of this engine running under the hood.

To be sure, the developer is blissfully unaware of nearly all J2EE low-level nuances. Discussion of transactions, transaction management, state, and session management are topics treated lightly -- or not at all -- in the Workshop documentation. The run time includes its own internal transactions that guard the information passed among the run-time framework's EJBs. But it's all invisible. Similarly, stateful exchanges between a client and a Web Service are handled by a stateful session EJB; again instantiated and managed invisibly.

When building a Web service with the Workshop IDE, most of your time is spent dealing with Java controls. Controls are the genetic building-blocks of a Workshop Web service application; you literally lash them together in the visual designer. But they are not J2EE entities -- they have the look and feel of ordinary Java objects.

In Workshop's visual designer, controls are represented graphically as blocks with incoming and outgoing arrows to indicate front-end and back-end method calls, respectively. Static characteristics of a particular method -- such as whether it communicates to other methods via an asynchronous queue -- are specified via associated property windows. You inject business logic into a control by clicking on a source code tab, which reveals the control as being a commonplace Java class, and entering source code into the appropriate methods. (Even WebLogic Workshop can't automate everything.)

The XML lifeblood

SOAP is the lifeblood of a Workshop Web service, and XML forms its corpuscles. All interactions between components of a Workshop-built J2EE application, as well as between clients and services, communicate via XML wrapped in SOAP. At multiple points of execution, therefore, your code must read and write XML messages. The Workshop provides two tools for this: the XQuery mapper and XMLBeans.

The XQuery mapper reads an XML schema on one side, an input method to a Web service control on the other side, and allows you to graphically connect the two. A developer can literally drag connecting lines from nodes of a parsed XML schema view on one side and connect them to Java object members on the other. The Workshop does the rest; at run time, XML messages will be unpacked and their contents delivered to the proper object members.

XMLBeans take a more procedural approach. The Workshop reads the schema, and produces a bean whose methods allow your application to read, write, and modify XML message elements. All the while, the XMLBean maintains the fidelity of the XML message itself.

But when developing with BEA's WebLogic Workshop, are you creating a J2EE application? No and yes.

No, in that you deal with abstractions of activities, rarely touching J2EE directly. When using Workshop, the only direct exposure I had to J2EE denizens were the JSPs that comprised the presentation portion of the Web service.

The answer is also yes, in that the Web service that finally executes is a J2EE application. It's made up of servlets and JSPs and EJBs and JMS queues, all calling standard J2EE APIs. They're there, but you'd hardly know it.

Initially, I worried that the Workshop simply traded one set of problems for another: no wrestling with all the headaches from deploying a J2EE application, but there is some uncertainty about the quantity and structure (and therefore, the performance impact) of any given part of the Web service begotten by the Workshop, simply because it does such a good job of insulating the user from the final code. However, the ease with which complex J2EE applications can be erected means Workshop 8.1’s disadvantages are well outweighed by its advantages.

Copyright © 2003 IDG Communications, Inc.

How to choose a low-code development platform