I was goofing off this weekend, trying to figure out what would be the best topic to write about for this month's architecture column. And, like any good columnist, I procrastinated until Sunday night (the article was due on Monday morning).

Right on time! While sitting at my computer, I couldn't help but wander off to random Web sites and all the while I was instant messaging a complete stranger, Andrea. In my angst to write a great column, I turned to Andrea and asked her what this month's topic should be. She responded with, "flying monkeys and plastic brains."

Hmmm. Although an appealing topic to write about, I was concerned about how appropriate it would be for this audience. And, even though I can't write about monkeys and brains, there is a metaphor here: understanding flying monkeys and plastic brains is like WebLogic Workshop's architecture - everyone is initially confused by it.

BEA has invested a lot of marketing and engineering effort into WebLogic Workshop. It was launched with a bang at our eWorld conference in February. I even had the pleasure of doing a launch demo as part of Alfred Chuang's keynote. But, despite all this launch hysteria, there hasn't been much information about Workshop's architecture. This column dives into this.

High-Level Architecture
Figure 1 details the high-level architecture of what WebLogic Workshop has to offer.There are two portions: a runtime framework and a visual development environment. The value and complexity is located in the runtime framework. At the core of WebLogic Workshop is a Web service definition. The Web service definition is located in a JWS file that is a pure Java file residing in WebLogic Server. The runtime framework manages JWS files and converts them to J2EE applications at appropriate times. Additionally, the runtime framework provides debugging services to the development environment. And, it adds Web services support by providing SOAP protocol and WSDL mapping services.

The Workshop IDE is a visual development environment developers can use to create JWS files. The visual development environment provides a graphical representation for the Web service, a code editor, and the ability to interface with the runtime framework. Since the runtime framework is open and extensible, other IDEs, such as WebGain Studio and Borland JBuilder, can interact with the runtime and provide their own structure for managing Web services and JWS files.

Is This Really New?
The WebLogic Workshop architecture isn't actually a new approach to application deployment. Even though the JWS file format is a new concept, the deployment model is very familiar. The JWS deployment model is very similar to the JSP deployment model. Figure 2 provides more information about this process.

At the core of the architecture, a JWS file is created. A JWS file is a Java file with a standardized set of Javadoc tags that are used to mark up attributes, methods, and inner classes. JWS files are placed into a Web application directory on a J2EE server that supports JWS. This would be the same location where JSPs are located.

Similar to JSPs, each JWS file can be referenced through a unique URL. For example, the URL may look like http://server_name:port/application_name/ JWSFile.jws. Any program that can generate the right protocol requests to this URL can then invoke a message for this URL. This could be a browser, directly from the Workshop IDE, or from another IDE. When a URL request is received by the server, the server parses the JWS file and creates a new J2EE application that consists of EJBs, JMS destinations, JCA adapters, and servlets. These files are packaged into an EAR file and deployed into the same server as a new application. This new application is exposed as a Web service and immediately made available to external clients.

What About Control Files?
WebLogic Workshop control files are used to integrate with enterprise resources. In this first version of Workshop, there are timer, EJB, JMS, JCA (AppView), and service controls. A control file is similar to a JWS file: it's a Java interface that contains Javadoc annotations for indicating how the integration should occur.

When a JWS file is created, it contains a reference to a control file for each instance of a resource that is going to be used in the implementation. When a JWS file is initially converted into a J2EE application, the JWS translator parses the JWS file and discovers all of the control dependencies for that application. The translator then takes each control file and creates an implementation for that control. For example, for an EJB control file, the translator would create a Java proxy from the JWS file to the EJB. For the timer control file, the translator would set up a timer queue with a message listener to receive timing messages. For all of the controls that are used by a single JWS file, their implementations are bundled as part of the application created for the broader JWS file.

So, whereas a single JWS file will get converted into a complete J2EE application, a single control file will be converted into an implementation that is hosted as part of a J2EE application defined by a JWS file.

Conclusion
In a nutshell, that's the core of the WebLogic Workshop architecture and how the runtime engine works. There are other aspects that the runtime engine provides to WebLogic Workshop, such as low-level Web services protocol support, data type encoding, XMAP translation, and others. Also, IDEs can add on a variety of value-add services as well: configuration management support, support for adding controls fluidly, support for integrating other Web services (how do you locate and import these things?), different graphical representations of JWS files, and so on. If you haven't played with Workshop yet, I suggest you try it. You can download it today at http://commerce.beasys.com.