Turning Web Sites into Web Services

by Jesper Jørgensen


Today the promise of Service Oriented Architecture (SOA) is to help enterprises achieve faster time to value. These are fine words, but without action, words often achieve nothing, and in the case of SOA, one cannot ensure reuse of IT assets unless these assets are accessible. A way for SOA to achieve this is through Web services, yet if the assets are not exposed through Web services, and the work of exposing them is demanding and expensive, then achieving faster time to value may become an unreachable goal.

But what if the assets that you want to expose are accessible through a Web interface (for example, a legacy application on a company's intranet), and what if there were a very simple way to expose these assets as Web services?

This article presents a full example of a Web site turned into a Web service through the use of a product called RoboSuite WebLogic Edition. The Web service contains several operations that together encapsulate the entire functionality of the site. The construction of the Web service does not require any traditional programming such as writing Java code.

About RoboSuite

Kapow RoboSuite, a Web integration platform, lets you easily integrate data and functionality from any application that has a Web interface. RoboSuite creates Web integration components called robots, which may take inputs and return output (just like a Java method). Robots are executed on a server called RoboServer.

RoboSuite comes in a special edition for the BEA WebLogic Platform that includes several features to ensure tight integration with BEA WebLogic Workshop. One of these features is an extensible control called the RoboSuite control. This is accessible from the controls menu in WebLogic Workshop and can turn robots into control methods within minutes and without any programming. In the example here, I create a control (JCX-file) with the RoboSuite control and use it to create a Web service.

Figure 1 shows an overview of the RoboSuite architecture from a WebLogic perspective. The figure shows the components of RoboSuite and how they interact with WebLogic Workshop. RoboSuite contains code-generation tools that know about WebLogic Workshop's application and project structure and can produce ready-to-use portlets and Web services ( .jws files). To learn more, take a look at the Additional Reading section.

The RoboSuite architecture
Figure 1. The RoboSuite architecture

Downloading and installing RoboSuite

  1. Go to www.bea.com.
  2. Open the Products menu and select the item Third Party Tools from this menu.
  3. On the Third Party Tools page, locate the tool Kapow RoboSuite, BEA WebLogic Edition, and click the More Information link.
  4. Click the link Download Kapow RoboSuite, BEA WebLogic Edition.
  5. Locate the product, Kapow RoboSuite, BEA WebLogic Edition, Version 8.1, and click the link corresponding to the operating system of your choice.
  6. Follow the instructions provided on the site.

The current version of RoboSuite is 5.5 SR1.

About the Example

The example is a simple phone record application in which you may look up, add, and delete phone numbers. To preserve a working example, I am using an application I have developed explicitly for this purpose, but the idea is that this closely resembles features that will be present in most CRM, CMS, and HR systems. Hopefully, you will be convinced that the example demonstrates a realistic scenario. I have written three robots covering the following actions: searching for phone numbers, adding phone numbers, and deleting phone numbers. This article does not describe how to write these robots. There are several reasons for this: First, it would make the article much longer than it already is. Second, it is a perfectly realistic scenario for someone else to write a bunch of robots, and then you must create controls out of them. The skills needed to write robots and to work with applications in WebLogic Workshop are not necessarily the same. Third, the RoboSuite documentation describes in detail how to write robots.

This article will concentrate on the process of creating a RoboSuite control that contains a method for each of the three actions that the robots perform, and then will show how to use this control to create a Web service with the same methods. The point is that after you have learned to use the different tools involved, the process of getting from the robots to Web service operations methods can be done in minutes. The entire process of writing the three robots, creating the control, creating the Web service, and finally performing a simple test took about one hour. With traditional integration methods this would have taken much longer.

The Robots

Although this article does not focus on how to make robots, a short description of a robot is necessary. A robot is written with a tool called RoboMaker, which is part of RoboSuite. Robots are similar to programs, but the programming language for robots is entirely visual (that is, there is no direct textual representation of robots; robots are actually saved in XML format in a .robot file, but the format is for internal use and is undocumented). Figure 2 shows one of the robots from the example in RoboMaker with the steps of the robot at the top. To the left is a browser view showing the state of the Web document at the current step (shown in green) and to the right are configuration panes for the robot and the current step.

The add robot in RoboMaker
Figure 2. The add robot in RoboMaker (click the image for a full-size screen shot)

Robots are designed to interact with one or many given Web sites (or part of these). They may have some robustness toward changes on the sites but are not general crawlers that just crawl the sites for information. Robots can navigate the sites, perform logins, fill out forms, iterate over tables, extract information from pages, and more. In short, they do just about anything you can do with a browser. A robot may take specially designed objects (created with a tool called ModelMaker) as input and output. Robots may use input objects to fill out forms, and output objects may contain data extracted from Web sites.

Robots are executed by a server called RoboServer. Clients (in this case, the controls) send requests to RoboServer to run a certain robot, and RoboServer will run the robot and return a response. The request may contain input objects, and the response may contain output objects, depending on whether the robot requires input objects and will return output objects. When a robot is turned into a control, the control will contain a method for calling the robot. The method will contain input parameters corresponding to the attributes of the input object to the robot. The return value of the method contains either a list of the objects returned by the robot or part of this list (for example, the first object, an attribute of the first object, and so on).

Table 1 summarizes the robots used in the example.

Robot Function Input Object(s) Output Object(s)
delete.robot Deletes a phone number from the registry. PhoneUpdate contains a name and a phone number. Name and phone number is the unique key. PhoneStatus containing a status field (Boolean) and a message text.
add.robot Adds a new phone number to the registry. PhoneUpdate contains a name and a phone number. Name and phone number is the unique key. PhoneStatus containing a status field (Boolean) and a message text.
search.robot Searches the registry for phone number of person with a name containing a given search string. PhoneSearch contains a search string. Zero or many PhoneNumber objects containing name and phone number.
Table 1. Summary of the Robot

The robots and corresponding models are packed in a zip file called a robot library file, in the example called phone.robotlib. Often the engineer constructing the robots and the engineer creating the controls are not the same, and a robot library may then be seen as the deployment unit used to exchange robots between these two.

Pages: 1, 2, 3, 4

Next Page »