Web services creation made easy

BEA WebLogic Workshop is a combination development/runtime environment, very much in the spirit of IBM’s WebSphere Application Developer. But WebLogic Workshop exclusively generates J2EE (Java 2 Platform, Enterprise Edition) 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 (Enterprise JavaBeans) 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 component or a servlet. 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. Workshop includes a development-server version of the WebLogic application server, so services and clients can be tested virtually the instant they’re created. Workshop includes a kind of test-bed browser that allows you to exercise a service even before a client has been built.

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-generated source code. These annotations are read by the runtime framework prior to application deployment and guide the instantiation of infrastructure plumbing in the form of EJB components (plus an incidental servlet) that support a Web service’s nonbusiness-logic behavior. This instantiation occurs only when you’re developing and testing from within 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 runtime framework, a container riding atop the WebLogic application server and hosting infrastructure EJB components. Each EJB component 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 runtime includes its own internal transactions that guard the information passed among the runtime framework’s EJB components. But it’s all invisible. Similarly, stateful exchanges between a client and a Web service are handled by a stateful session EJB component—again instantiated and managed invisibly.

When building a Web service with the Workshop IDE, you spend most of your time 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.

Workshop’s visual designer graphically reprents controls as blocks with incoming and outgoing arrows to indicate frontend and backend method calls, respectively. A particular method’s static characteristics—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 (Simple Object Access Protocol) 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 execution points, therefore, your code must read and write XML messages. 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. Workshop does the rest; at runtime, XML messages will be unpacked and their contents delivered to the proper object members.

XMLBeans take a more procedural approach. 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 JSP (JavaServer Pages) pages that comprised the Web service’s presentation portion.

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

Initially, I worried that Workshop simply traded one set of problems for another: no J2EE application deployment headaches, but some uncertainty about the quantity and structure (and therefore the performance impact) of any given part of the Web service begotten by 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 advantages well outweigh its disadvantages.