Web services creation made easy

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.