| Web services hold great promise for solving many integration and computing challenges; however, the technology must go beyond the simple synchronous RPC paradigm and transcend what typically amounts to tight coupling between the implementation and the Web service contract. BEA's new WebLogic Workshop (WLW) product provides an innovative, best-practices framework for developing world-class enterprise Web services. It provides the following major features for accomplishing this objective: -
Conversations ” Realistic and robust integration solutions must allow for latency to bridge heterogeneous call and response times between systems. WLW allows long-running and stateful interactions to be maintained between a service client and provider, across multiple requests . -
XML Maps ” Provides a clear separation between a Web service contract and its implementation. This separation promotes loose coupling, which in turn provides extensibility and reduces fragility. -
Custom XML Maps ” Enables developers to import XML templates and build Web services that generate business-level documents to be used as units of communication. This feature facilitates the use of coarse-grained interfaces. -
Resource Controls ” Developers no longer need to know the intricacies of J2EE resources to use them, such as JMS, EJBs, JDBC, J2CA APIs, or the details of invoking external Web services. WLW Controls shield developers from such plumbing complexities so that they can focus on writing code that delivers business value. The Primary WebLogic Workshop Components These are the three primary components of Workshop: -
Java Web Service (JWS) application files ” This component embodies your Web service definition, its properties, and the resources it interacts with. This Web service definition file is a regular Java file with a file type of .jws , containing special javadoc-style annotations. A .jws file can access resources (such as EJBs, databases, message queues) via Controls , a metaphor for simplifying and hiding J2EE resource interactions, which exist as .ctrl files. Both .jws and .ctrl files are inducted as standard Web service constructs under the J2EE technology umbrella, via Java Specification Request (JSR) 181. -
Visual development environment (VDE) ” This versatile tool enables you to model your Web service ( .jws files) and its interactions with J2EE resources via controls ( .ctrl files). That is, all your .jws and .ctrl files and their special annotations are generated for you in this environment. An intelligent code editor is provided for developing your business logic. In addition, the VDE automatically generates a test harness for your Web service and generates facilities for use by your Web service clients , such as client proxies and WSDL files. -
Runtime framework (JWS Container) ” This component is the workhorse that makes it all magically happen at runtime. When your Web service is started and invoked inside the Workshop VDE, this container digests your .jws and .ctrl files, generates all necessary J2EE components, and deploys them as standard J2EE Web applications. This process, usually a laborious and J2EE “skill-demanding task, is now automatically done for you. These generated Web applications, a combination of J2EE components and JWS components, can be deployed (and even fine- tuned or customized) in any J2EE-compliant and JWS-enabled application server. This container can also, by working in concert with the Workshop VDE, enable you to run, test, and debug your visually authored Web services. A High-Level Architecture of WebLogic Workshop After you have developed a Web service by using the Workshop VDE to produce .jws and .ctrl files and deployed them to WebLogic Server, the sequence of events shown in Figure 9.22 transpires. Figure 9.22. The WLW component and execution architecture.  When a Workshop-developed Web service is invoked, WebLogic Server receives the SOAP request and hands it over to the JWS Container, which first converts the XML request to a Java request (that is, unmarshaling) by reading the XML Map specification, if any, in the .jws file for that Web service. The request is mapped to the appropriate Java logic in the JWS Container, which might invoke a JWS Control in a .ctrl file. The JWS Container invokes the requested resource via the WebLogic Server J2EE container. When done, execution control and any return objects are then passed back to the JWS Container. If the Web service is asynchronous, a callback method can be specified in the .jws file and invoked. The Java results are then converted to an XML (SOAP) response (that is, marshaling) by using the XML Map specification, if any, and sent back to the service client. Note XML Maps are optional, and if no map is specified, a "natural" mapping is supplied in both the marshaling and unmarshaling process, in which the Java declaration matches the message's contents.
The JWS Container also provides services such as In addition, the container and VDE together bring you an instant, write-and-run testing harness for your Web services. Chapter 32, "Web Services Made Easy ”WebLogic Workshop," discusses this development framework and its features in detail, along with the format of .jws and .ctrl files, step-by-step instructions for setting up asynchronous and loosely coupled Web services, and an end-to-end tutorial for how to develop and test a simple Web service. Remarkably, comprehending this chapter requires no prerequisite knowledge of J2EE (except Java), but in the end you will have created a sophisticated J2EE Web application (Web service)!  |
