 | Level: Introductory John Rooney (rooney@us.ibm.com)IBM
Elias Torres (eliast@us.ibm.com), Senior Software Engineer, IBM
01 Jul 2001 This article provides a brief overview of Web services and introduces a new technology, Sash, that is currently under development within IBM. Sash provides an innovative foundation for building and deploying desktop applications. When combined with Web services, Sash promises to deliver a new class of network-based applications integrated directly into the desktop environment.
For those who develop and deploy e-business and Internet technologies, the past decade has
certainly been one of rapid change. The shifts in technology over this period have had an incredible impact on the ways we conduct business, gather information, and connect with others. Recently, two trends have emerged that can further increase the pace of innovation. Over the past twelve to twenty-four months, a new architecture model, Web services, has begun to take shape. Web services allow application functions to be easily called remotely using Internet protocols. In addition, during this same period, we have seen the slow proliferation of desktop applications that incorporate access to Web-based resources outside of the Web browser. While the browser has been the key trigger behind the explosive growth in e-business activity, most would agree that it is a less than ideal application delivery platform.
Web services
In simplest terms, Web services are implementations of application functions so that they are accessible over Internet protocols such as HyperText Transfer Protocol (HTTP). Web services make application functions callable over the network without the consumer of the service, whether it is a client or a server, requiring knowledge of the platform or language used to build the application.
For example, let's suppose you are building an application and would like your users to have access to the status of a pending package shipment. If the shipping company provided the capability to access this data from a Web service, you would only need to know how to create the proper message to call that service and the location of the service on the network. The shipping company's application would unpack the message, perform the appropriate task, and respond with a formatted envelope containing the information you requested. To a large degree, this is akin to how many Web sites have made data available through the Common Gateway Interface (CGI). With Web services, however, there is a growing coalition of companies actively working on standards, protocols, and implementations that help define this space. This article includes brief details on some of the key technologies that currently define this area.
Technologies
- Simple Object Access Protocol (SOAP) is a
lightweight, Extensible Markup Language (XML) based protocol for exchanging
information in a networked environment. The SOAP specification defines the XML
message format, the bindings to HTTP, and how remote procedure calls can be
represented in SOAP. Currently, the most commonly used function of SOAP is to
provide a mechanism for enabling remote-procedure calls through an HTTP POST.
- Web services Description Language (WSDL) is an
XML-based format that describes the methods and parameters a given Web service
accepts and the format of the response that it returns. WSDL is highly useful
for developers building applications that consume Web services. Developers can
expect that the creation and interpretation of WSDL are handled by development
tools.
- Universal Description, Discovery, and Integration (UDDI) is both a registry through
which service providers can list their implementations and a specification for describing
the service and searching the registry. Think of UDDI as the Yellow Pages that allow
developers and businesses to locate other Web service providers.
It is also appropriate to make a note here of Remote Procedure Call through XML (XML-RPC). XML-RPC is the forerunner to SOAP. Like SOAP, XML-RPC is an XML-based protocol for making remote procedure calls over HTTP. While a good portion of the industry is working on SOAP and driving it toward standards adoption, there are a growing number of XML-RPC implementations available.
What is Sash?
Sash is an early-stage technology from the IBM Internet Technology group and IBM Research. Sash is currently available from the IBM alphaWorks site. Sash allows developers using standard Web technologies such as HTML, XML, and JavaScript to build and deploy applications that leverage the power and resources of the client machine. We call these applications weblications. Sash is currently available for the Win32s platforms and for Linux. This article focuses on the Windows version of Sash.
Most, if not all, organizations today are building browser-based applications. In this model, an application's functions are performed on the server; and the results, including the user interface, are delivered to the user through the network. Some Web application developers pass a portion of the processing down to the client, either in the form of JavaScript in the HTML page or through a Java applet. While these have proven to be effective models for application delivery, they miss the opportunity to leverage the power of the desktop as a part of the architecture. Slowly but surely, more and more applications that rely on the network for infrastructure and information delivery are moving away from the browser. Applications such as AOL Instant Messenger or Windows Medias Player are incorporating the delivery of Web-based resources directly into the client applications. These applications are capable of delivering richer, more intuitive user experiences that can typically be presented in a browser.
Sash effectively opens the functions of the desktop to Web application developers. Building client-side, native applications for Win32 is the domain of developers working with C++, Visual Basics, and Java technology. Using Sash, however, Web developers skilled at building browser-based applications can now build applications that run outside the browser and integrate directly with the client desktop. This can have a significant impact on the user experience and the responsiveness of an application. Sash, for example, allows the developer to store the application user interface (UI) on the desktop, reducing the load on the server, which now only needs to present application data. Additionally, Sash provides the developer with the ability to manage data in a local cache. Utilizing that cache can improve the overall performance of the application on the network and allow the developer to build the application so it runs in a disconnected state.
Sash components
Sash consists of two components: a runtime and a development environment. Largely, the Sash runtime is analogous to a browser plug-in, such as the Macromedia Flash plug-in. Like a plug-in, the Sash runtime enhances the basic facilities provided by the browser. A core function of the Sash runtime is to provide the environment that allows the application's HTML and JavaScript code to be mapped to the presentation layer of the operating system. This allows the Web developer to build an application that looks and feels like a native application, such as might be built on Windows with Microsoft's Foundation Classes (MFC). In addition, the runtime provides a secure environment that allows the developer to access many of the underlying functions of the operating system. On Win32 systems, this includes access to the Registry, File System, and COM ports.
The Sash Weblication Development Environment (WDE) is a feature-rich Integrated Development Environment (IDE) that allows a developer to manage the full life cycle of a Sash Weblication. Among the many features of the WDE, it provides WYSIWYG editing, JavaScript syntax highlighting, and syntax assistance. Additionally, it contains a debugging environment for testing the weblication code, as well as tools to manage the packaging and deployment of the finished applications. As we walk through the development of a sample weblication, we highlight many of the WDE functions.
One of the key factors behind the push toward browser-based applications is the cost associated with the development and deployment of desktop applications. Sash addresses these concerns by enabling a Web model for application delivery. Weblications built with Sash are deployed directly from a Web page. They can be built so that they regularly check for updates and notify users when new client code is available. Updates to the application occur over the network and directly on the client. This eliminates the need for distributing code to end-users on CD or having machines installed by desk-side support teams.
Sash and Web services
Sash is an ideal environment for building client applications that consume Web services. While much of the activity in the Web services space is performed on the back end with servers exchanging data through SOAP, there are huge opportunities to leverage Web services directly in a client application. Using Sash, application developers can add references to SOAP objects simply by linking to a WSDL file. Sash uses the WSDL to generate stub code that can then be scripted into the remainder of the application. This function is demonstrated in the sample weblication below.
Sample application
Let's move on to a sample application that demonstrates the power of using Sash to build client applications that leverage Web services. For our sample application, we build a simple language translation client. Though the client leverages Sash, it is built entirely of HTML and JavaScript, so the code should be understandable for developers experienced in both technologies. Additionally, we tie in a Web service for the translation. That Web service is hosted by www.xmethods.com, and the translation is provided by the AltaVista BabelFish service.
A developer begins a new weblication simply by choosing
Create a New Project from the Welcome screen in the WDE, as shown in
Figure 1. This launches a wizard that steps the developer through some basic settings to configure the project environment.
Figure 1. Main Sash WDE screen
Weblications consist of Web pages built with HTML and JavaScript. A weblication is made up of a collection of actions, each of which consists of a Web page that runs in a specific part of a user's desktop, its location. On Windows, typical locations include:
- Windows Taskbar
- Windows Explorer
- Standalone window
Once the project environment is configured, the user is
presented with New Action wizard, as shown in
Figure 2. This wizard allows you to choose from a number of potential locations in which to implement your Action.
Figure 2. WDE New Action dialog
Once complete, the wizard generates the base HTML that you modify to
implement the functions of your weblication. It is important to note that a
weblication can consist of any number of different actions. This means that a
weblication can expose user functions in multiple locations, such as in a
standalone window and in the Windows Taskbar. Additionally, these actions can
dynamically communicate with each other or with other weblications. This creates
a foundation for some interesting applications that is unachievable in a
browser. For our translation client, we are going to limit ourselves to a single
standalone window. This window appears and acts like a typical Windows
application. Once the base code is in place, we add the HTML and JavaScript that
defines the user interface and function of our application. Our application's user interface is nothing more than a Web page. The various
components of the page, tables, text areas, and buttons are all defined the
<body> of the page and are utilized in the same way as if you were
designing for a browser. When the weblication loads, the contents of the
<body> are loaded in the window and rendered according to the same rules
that a browser enforces. Because we are building for Windows, Sash relies on
Internet Explorer Web browser to render the HTML. If you are familiar with HTML,
the UI is very familiar. The key difference, however, is that instead of the
code being used to generate a page in a browser, it is used to create the UI of
a Windows Desktop application. Listing 1 shows the content of the HTML page before we add any of the functional code or Sash
calls. Figure 3 shows HTML rendered by Sash.
Listing 1. HTML before Sash
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html"; charset=windows-
1252">
<style type="text/css">
body,select,textarea,input
{
font:messagebox;
}
</style>
<script language="SashScript">
</script>
</head>
<body vlink="blue" bgcolor="#ffffff" leftmargin="15" topmargin="0"
scroll="auto" rightmargin="0">
<fieldset style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px;
PADDING- BOTTOM: 15px; WIDTH: 100%; PADDING-TOP: 15px">
<p><legend>WebService provided by: <a target="_new"
href="http://www.xmethods.com">XMethods.com</a></legend><br>
1. Select a translation mode: <select name="Mode">
<option value="en_fr">
English to French
</option>
<option value="en_de">
English to German
</option>
<option value="en_it">
English to Italian
</option>
</select><br>
<br>
2. Enter some text or Click <a
href="javascript:OpenFile()">here</a> to open an existing
text file. ( 5K Limit )<br>
<br>
3. Click to <input onclick="Translate()" type="button"
value="Translate"><br>
<br>
<textarea id="Source" style="WIDTH: 100%; HEIGHT: 115px">
</textarea><br>
<br>
Results from WebService:<br>
<br>
<textarea id="Result" style="WIDTH: 100%; HEIGHT: 115px">
</textarea></p>
</fieldset>
</body>
</html>
|
Figure 3. HTML rendered by Sash
WYSIWYG and syntax assistance
The WDE has a very powerful WYSIWYG editor for building the application interface. It also includes a toolbox from which the user can drag and drop common HTML controls into the UI development pane. In the WDE, a developer can quickly switch between views of the UI as work progresses, which allows the HTML source to be edited directly or through the drag and drop palette. The editor also provides context menus and property boxes, which eases the modification of objects on the page.
Sash.WindowApp.MainWindow.TitleText = stringvar; |
We have defined the UI for our application, and now it is time for us to add the function. Because the actions of a weblication are defined by HTML, the developer is able to add functions simply by adding script to the page. Sash exposes an additional set of calls that allows the developer to access the extensions and operating system application program interface (APIs) exposed by the runtime. Think of these additional calls as a superset of JavaScript. The underlying functions and semantics of these extensions are the same as the code that you would write in a browser-based application. However, if you wish to make use of the added functions of Sash, you need to make use of the Sash extensions. For example, to set the Title Text of a standalone window, you need to make the following Sash call:
Figure 4. Sash WDE syntax assistance
That call is extremely intuitive, even if you have never
written a Windows application before. All calls that are specific to the
functions of Sash begin with the keyword Sash. On Windows, there are
approximately 300 API calls available in Sash, so it can be difficult to get
familiar with all of them. To ease the developer's efforts, the WDE provides
syntax assistance. When you type Sash. (with the period), you are presented with
a menu of available options (Events, Properties, and Methods) for a given
object, as shown in
Figure 4. Once you have the menu, you can type the first letter of the call you are interested in or scroll though the available calls to find the one you need.
Sash does not have a main function per se, but the event Sash.Core.OnLoad fires once the HTML code for a given location has loaded. You can use this event as a hook from which you can call functions to set up your environment. These might include defining the properties of your window and initializing variables. This is similar to using the onLoad event in the body of an HTML page.
Here is the Sash.Core.OnLoad event for the translation
client, along with two functions, as shown in
Listing 2. :
Listing 2. Sash.Core.OnLoad event code
// Always set a function to be executed
// on the OnLoad event of Sash.Core.
// This function will only be called after
// Sash has created the WindowApp frame and the page
// has been completely loaded.
Sash.Core.OnLoad = main;
// Put all application initialization
// code in this function.
function main()
{
// function call to modify display settings
// such as frame size, position, status bar display
// etc.
SetupDisplay();
// function call to create menu band ( File, Edit, etc ).
CreateMenu();
// Set our TEXTAREA fields values.
Source.innerText = "Look how easy it is to write fast and great
looking applications using Sash.";
Result.innerText = "";
// Show Main Window
Sash.WindowApp.MainWindow.Visible = true;
}
function SetupDisplay()
{
// Set up Main Window
Sash.WindowApp.MainWindow.Width = 600;
Sash.WindowApp.MainWindow.Height = 500;
// Short function to center window in the
// center of the user's screen.
Sash.WindowApp.MainWindow.Left = Math.round((screen.width -
Sash.WindowApp.MainWindow.Width) / 2);
Sash.WindowApp.MainWindow.Top = Math.round((screen.height -
Sash.WindowApp.MainWindow.Height) / 2);
// Set the title of Weblication.
Sash.WindowApp.MainWindow.TitleText = "Sash Translation
WebService Demo";
// make status bar visible and set its text.
Sash.WindowApp.MainWindow.StatusVisible = true;
SetStatus( "Ready." );
}
|
- The function main is called by the OnLoad event and
contains calls to other functions that create the primary UI state.
- The function SetupDisplay instantiates the window and set its initial properties.
The comments in the code fragment in Listing 2 are intuitive. Take note of the combination of Sash calls and typical JavaScript calls within functions. Because the code for Sash is semantically JavaScript, there is no need to write separate code blocks to handle different applications' functions. For instance, when setting the innerText attribute of Source and Result, we are setting properties of the HTML page in the same manner as if we were building a Web page. When setting the Left and Top attributes of Sash.WindowApp. MainWindow, we are using calls to the Math and Screen functions of JavaScript to calculate the starting position for the window frame.
Adding a SOAP reference
The only thing left to do to complete our client is to wire a call to the translation service. For our client, we access AltaVista's BabelFish server as a Web service through SOAP. There are a number of sites on the Internet that act as hosts for early Web services activities. One of those is XMethods, accessible at www.xmethods.com. On their site, XMethods provides an RPCRouter, in effect the gateway to the services, and the WSDL files to describe how to call the services they host. One of the nice things about SOAP is that it hides all the complexities of the back-end implementation. We have no idea if they are running their services in Perl or as Java Servlets, nor do we need to know if they are interfacing directly with a database for content or if they are acting as a proxy between our request and a target Web site. The application developer only needs to know how to call the SOAP object and the format of the response envelope. This is where WSDL comes into play.
WSDL is really just a consistent way to describe the interface of the Web service. Some argue that this could be done simply with documentation, but providing a standard format can yield great benefit to the developers of applications. For instance, in Sash, we only need to know the Uniform Resource Identifier (URI) of the WSDL file, and Sash handles much of the pain for us. Let's quickly walk through an example.
Because the WDE has an embedded Web browser, we can
navigate to the XMethods Web site without leaving the environment. On their home
page, XMethods has a list of services that are currently available. Locate the
listing for BabelFish, which connects to a page with details about BabelFish and
links to the WSDL files. Because we are browsing the XMethods site from within
the Sash WDE, we can simply right-click on the link to the WSDL file to open a
context menu that includes an option to Add SOAP Reference, as shown in
Figure 5
.
Figure 5. Add SOAP Reference from WSDL
Choosing Add SOAP Reference launches a dialog box that allows Sash to connect to the WSDL, parse the file for available methods, and add references to the defined binding directly into the development project.
Once the reference is in the project, we can add an
object based upon that reference. Choosing Source \ Add SOAP Object from the
menu launches a dialog box that contains a listing of the SOAP services
currently available. We simply choose a given binding and supply a variable
name, as shown in
Figure 6
.
Figure 6. Add SOAP object
When we click OK, Sash adds a global variable to the code and automatically generates the code required to call that Sash object. We can drop the code into the source by choosing Drop Here from the menu.
Final application
To finish the application, we create the function that
calls the translation service, wire it to the button and the input box of the
UI, and we are done, as shown in
Figure 7
. This wiring is done in the onClick event of the Translate button and passing the value of the input area to the function calling the service. To enhance the weblication, we have added some menu items, as well as the ability to read a document from the local file system directly into the input area. These are straightforward, and you are encouraged to have a look at the source code of the application to get a sense of how it is accomplished.
Figure 7. Final Application running under Sash
Sample files
This article contains additional sample code and files that
are available from the DeveloperToolbox download catalog.
After you accept the license agreement, select the custom HTML, Java, or HTML catalog to view our approximately 1000 products, tools, and information resources.
Go to the Sample Code category and you'll find this article listed under the DeveloperToolbox Technical Magazine heading.
Conclusion
That's all there is to it. With Sash and a bit of HTML and JavaScript, we have created a standalone Windows application that leverages a Web service as part of its core functionality. The application development effort was no more complex than developing a Web page, but we have an application with a rich, native user interface. Additionally, we were easily able to tie a Web service into the application flow. While this was a relatively simple example, the opportunity to leverage Web services in client applications is clear. The trend to Web services has the promise to deliver the kind of integration between desktop applications and Web content that has been predicted since the Web burst upon the scene. Imagine the many ways you can turn your spreadsheets or desktop database tools into live applications that grab data from Web services and integrate that data directly into the environment. In addition, with Sash, Web developers can leverage their skills and abilities in new ways and present users with rich, intuitive applications that enhance the user's overall experience.
Resources - Categories: Java tools, Web Services, XML Tools
- Sash Weblications for Windows
- IBM XML and Web Services Development Environment
- WSDL Toolkit
- Web Services ToolKit
About the authors | | |
John Rooney is a Software Engineer on the IBM Internet Technology team building next-generation application prototypes and technologies for use within IBM and with customers. He recently joined the business development team working on Sash and driving customer interest and adoption of the group_s work. You can contact him at rooney@us.ibm.com.
|
| | |
Elias Torres is a Software Engineer on the IBM Internet Technology team building application prototypes and technologies for use within IBM and with customers. He has been a member of the IBM Sash development team for over a year and has a great interest in scripting, XML, and other key Web technologies. You can contact him at eliast@us.ibm.com.
|
Rate this page
| |
