The Visual Development Environment


Figure 32.18 shows the VDE and explains its major parts .

Figure 32.18. The WebLogic Workshop VDE.

graphics/32fig18.jpg

The numbers in Figure 32.18 correspond to the numbers in the following list:

  1. Provides a place to add a method or callback for communication with clients and resources.

  2. Displays the source code for the current Web service. As you design a Web service, source code is written to the .jws file.

  3. Provides a place to select controls for access to resources.

  4. Represents a client to request functionality of your service by calling its methods .

  5. The Web service (JWS) you are editing. You can click it to view its properties, double-click it to view source code, and right-click it to add methods, callbacks, and variables .

  6. Displays the properties of an item currently selected in the Design View or Structure pane. Properties are exposed through custom javadoc tags in source code.

  7. Displays a hierarchical representation of the source files in your project and provides a place from which you can save, open , add, and delete project files. Projects group source files as WebLogic Server "Web applications."

  8. Displays information about the currently selected item, including properties.

  9. Updates as you add member variables, methods, and callbacks. You can select an item to view its properties in the Properties pane. You can also double-click an item to quickly go to its source code.

  10. Displays a list of tasks that you can perform for the currently selected item. In many cases, you can click a link to perform a task.

These are the major parts of the VDE:

  • Project tree (upper left) ” Lists all your Web services and components and, like a file browser, enables you to add folders and files as well as select the components you want displayed in the main work area.

  • Structure pane (lower left) ” Like any good Integrated Development Environment (IDE), this pane reveals the structure of your code (the .jws file) and enables you to fast- path to any method in the .jws file; for example, double-clicking on a method name displays that method's source view in the main work area.

  • Main work area (center) ” Displays your entire Web service in this area, with all its interacting components (client and controls). There are two view modes: Design View (graphical) and Source View (textual).

  • Properties (upper right) ” Any Web service element, such as .jws and .ctrl files, methods, or callbacks, has properties that can be configured. These properties result in JWS annotations within your JWS source code. Any time you select an element, its properties are displayed in this area.

  • Description (lower right) ” Displays text documentation on the currently selected component, gleaned from javadocs.

  • Tasks (bottom right) ” Documents miscellaneous tasks that can be performed on or using the currently selected component.

The following sections delve into the few areas that typically get high traffic.

Project Tree

A Project is a collection of Web services or Web service components, much like your typical IDE project. In Workshop, an individual Web service resides in a folder under the Project. That Web service can be self-contained or use components found in other folders. Figure 32.19 shows a Project's logical organization.

Figure 32.19. How a Workshop Project is organized.

graphics/32fig19.gif

A Web service folder should contain only one .jws file, one Web service. The WEB-INF folder is a special location containing JAR files for any back-end code or J2EE resource (such as EJBs) that any Web service in this project can access. The Xmlmap and Controls folders can be used for storing logic shared among multiple Web services. This structure is certainly not the only way to organize components; folders can actually accommodate any kind of files.

Operations

In addition to the usual operations allowed on hierarchy trees, you can also drag and drop files and folders within the project tree and between the project tree and the file system. You can also invoke code-generation facilities in the project tree. Because a .jws file is a Web service, you can request the following:

  • JWS-to-WSDL file ” Generate the service description file for clients that are not JWS Web services.

  • JWS-to-CTRL file ” Generate a service control file for clients that are JWS Web services.

To invoke code generation, select a .jws file and right-click it, as shown in Figure 32.20.

Figure 32.20. Select a .jws file.

graphics/32fig20.jpg

Main Work Area ”The Canvas

This center pane presents a graphical and unified view of a .jws file, including all its interacting partners , such as clients and controls. The following parts of the main work area are shown in Figure 32.21:

Figure 32.21. Contents of the main work area.

graphics/32fig21.jpg

  • The center box is the canvas on which you create the JWS Web service (the one titled "Investigate").

  • The left box has a CLIENT icon representing an entity that can invoke operations on the Web service. Arrows pointing from CLIENT to Investigate represent callable methods on the service (these methods are underlined ). Arrows pointing from Investigate to CLIENT represent callbacks from the Web service. A circled letter decorating an arrow indicates that the method participates in a conversation, and the letter signifies whether it starts (S), continues (C), or finishes (F) the conversation. A coil-like icon indicates that buffering is enabled. The fat arrows indicate that a default or custom XML mapping is in place for the method.

  • The boxes on the right labeled DATABASE, EJB, JMS, and so forth represent enterprise resources that are accessed by controls added to the Investigate Web service. Each mini-box that straddles the right edge of Investigate represents the control that interfaces the Web service to the resource. A right-pointing arrow is a potential API call to the control. A left-pointing arrow is a control callback that allows the control to invoke a method in the .jws file, informing it of some event (these callbacks are underlined).

Note that the Web service “to “control arrows do not indicate that the Web service business logic invokes the control method, only that it is available and can potentially be called. Note that callbacks (client or control) are rendered in a darker shade .

A JWS Web service can be rendered in two possible views:

  • Design View ” This is the view shown in Figure 32.21.

  • Source View ” This view shows the textual code listing behind the Web service or control.

These two views are not two separate objects; they are just two possible renderings or views of the .jws file.

The Test Harness

The WebLogic Workshop Test Harness enables you to test and debug your Web service. To start it, click the Start icon (the right-pointing green arrow) on the toolbar.

By default, the Test Form is displayed (see Figure 32.24). The following sections go through each section of this Test Harness.

Overview Page

Click the Overview tab to see the Overview section shown in Figure 32.22.

Figure 32.22. Overview section of the Test Harness.

graphics/32fig22.gif

Think of the Overview section as the "home page" for your Web service, where a potential client can come to get information and tools for invoking your service. It contains the following information:

  • Complete WSDL ” The service description is in standard WSDL format so that your non-Workshop clients know how and where to access your service.

  • Callback WSDL ” Because Workshop Web services can invoke callback methods to the client, this is the callback service description. It tells a client how it might implement your service's callback methods.

  • Workshop control ” What if another Workshop Web service is interested in invoking your Web service? This link downloads code for a Service control to your Web service.

  • Java proxy ” Java proxy code comes in handy if you need to write a Java client that invokes this service. The proxy can be made into a class that your Java client imports, allowing it to call your service methods without needing to create the SOAP request or parsing the SOAP response manually.

  • Proxy support JAR ” Other code needed by the Java proxy.

  • Service description (for each method) ” Links to the Test Form for each operation in your service.

  • Useful links ” Links to various industry specifications (not visible in Figure 32.22).

Console Page

Think of the console page as the administration page for your Web service, much like the WebLogic Server Administration Console, except much simpler. Figure 32.23 shows the Workshop console page.

Figure 32.23. The WebLogic Workshop console page.

graphics/32fig23.gif

This page contains information pertaining to your Web service implementation and configuration (hence, non-public information), such as the following:

  • Historical records of the time this service was built

  • The back-end components and resources involved in your Web service

  • The WebLogic Workshop build label

  • Log settings to specify how much logging is needed and how many old messages to keep around

  • Persistence and caching settings to reset log records and force component redeployment

Test Form Page

The Test Form page, shown in Figure 32.24, is where you get to test-invoke methods in your Web service.

Figure 32.24. The Test Form page of the Web service Test Harness.

graphics/32fig24.gif

There are two sections in this page:

  • Message Log (left section) ” As you invoke the method and as any long-running conversations unfold, a list of methods being invoked (method traffic), including callbacks, is built and displayed in the Message Log section. You can click on any call that's listed to reveal its input XML and output XML in the Method Details section.

  • Method Details (right section) ” This section starts out as a list of methods that can be invoked, with input fields for call arguments. As a conversation unfolds or a method call ends, this section automatically switches to display input and output XML. The section "A Short Tutorial" later in this chapter illustrates this process in more depth.

Note

If a custom- requested XML Map is present for a method, the custom XML string is displayed instead so that you can fill in the actual values.


Test XML Page

The Test XML page (see Figure 32.25) is similar to the Test Form, except all inputs to method calls are specified in the actual XML request to be sent. All responses are also shown in XML format.

Figure 32.25. The Test XML page.

graphics/32fig25.gif

Warnings Page

The Warnings page displays messages that the compiler generates when you compile and run your Web service. These warnings are not errors, but information about problems your Web service might encounter as it is currently implemented and suggestions to remedy those problems.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net