As many of you know, OpenSpan began making a big push into SOA technologies last year. We even came up with a new marketing slogan: “OpenSpan the last mile of SOA.” While we’ve always had the capacity to consume web services, we wanted to add the ability to expose our automations as services. This culminated in the announcement last week of the OpenSpan Platform SOA Desktop Edition, which allows you to create an automation within or across applications and then expose that automation as a service deployed on the desktop (we call this desktop service enablement). While many of our customers are very excited about this new capability, I have been asked by others “that’s cool but what’s the point?”

I have to admit this reaction makes me want to jump up and down screaming: “What’s the point! What’s the point! Are you kidding! This isn’t just cool! This is totally freaking awesome!”

But… after taking a deep breath, I realize that this is really our fault for not explaining ourselves clearly. As anyone who’s read my blog knows, I think the software industry has treated the desktop environment like some provincial backwater for a quite a while now. Sure you need it to keep your empire running but you sure don’t want to go there if you can avoid it. Even though most of us spend most of our working lives in the Windows environment, the desktop is just the place everyone’s applications happen to end up. All of the cool stuff happens on the server.

Gradually, that opinion seems to be changing. ClickOnce, JNLP, WPF, Adobe Flex and other emerging desktop technologies are using the web as a delivery mechanism while using the power of the desktop to create rich interactive applications for users. Even Web 2.0 and AJAX are examples of this trend. The server delivers the HTML and JavaScript for the site once. After the initial delivery, all of the presentation and interaction logic runs on the desktop, only calling the server when new data is required. However, one thing hasn’t changed, once these applications get to the desktop they are still running in silos, usually isolated from the rest of the desktop for security purposes and unable to interact with the desktop environment.

OpenSpan desktop service enablement is the platform that allows these applications to integrate with the rest of the desktop. With OpenSpan services exposed at the desktop, these applications can now call services on the local machine just like they would their own backend services. What if your AJAX portal could now display not just data from your backend, but from your soft phone running on the desktop, the host system with your billing data, and your Java email application? What if your users could click a link in the portal and generate calendar invitation in Outlook? What if they could click another link and start an automated billing process?

OpenSpan desktop service enablement allows you to integrate any server delivered application with the rest of your desktop. Now, instead of using OpenSpan windows forms, you can create a user interface using the technology of your choice but still use OpenSpan to pull and push data, invoke automations and respond to events. Instead of being a “dumb” application that OpenSpan automates and monitors, your application can be a “smart” application that interacts and controls OpenSpan. That’s not just cool, that’s totally freaking awesome.

Over the next few weeks I’ll be writing some articles to spotlight new features in our 3.2 release. For many of our users, the most exciting new feature is debugging. For the first time, you now have the ability to debug OpenSpan automations in real time using paradigms familiar to users of Visual Studio, Eclipse and other IDEs such as breakpoints, step functions, and watch, call stack and thread windows.

Breakpoints

The essence of debugging is giving the developer the ability to stop execution and examine the state of an application. Stopping execution is referred to as breaking. By breaking execution a developer can find flaws in his logic, scenarios he did not anticipate, or invalid data. The most convenient way to break execution is a breakpoint. A breakpoint is simply a way of telling an application to “stop when you get here.” When the application is run, the debugger will break execution when the breakpoint is reached.

To set a breakpoint in an OpenSpan automation, simply highlight a link, right click and select “Toggle Breakpoint.” A red dot will now appear on the link indicating that a breakpoint has been set. If you right click on an existing breakpoint, you can select “Disable” to temporarily prevent the debugger from breaking when the breakpoint is reached, or “Delete” to remove the breakpoint entirely.

When a breakpoint is reached within an automation, the executing link will become a dashed, animated line. The blocks on either side of the link will also be outlined. The executed block will have a solid blue outline whereas the executing block will have a dotted blue outline.
You can view all of the breakpoints you have set within a project in the “Breakpoints” window. The Breakpoints window lists each breakpoint by automation. You can double-click on a breakpoint to go to that automation. You can also enable or disable a breakpoint using the checkbox next to it. If you right-click on an automation, you can also enable, disable or delete all breakpoints within that automation.

Step Functions

Once a breakpoint has been reached, you can begin “stepping” through an automation. By using the step functions, “Step Over” or “Step Into”, you can walk through your logic at your own pace. The “Step Over” function moves the automation to the next yellow execution link. The “Step Into” function moves the automation to the next blue data link, or if there are no blue data links, to the next yellow execution link. Once you have finished stepping through your automation, you can select “Continue” to resume execution until your next breakpoint is reached. The “Step Over”, “Step Into” and “Continue” options are available within the “Debug” menu and toolbar, but most developers simply use the F10, F11 and F5 keys respectively.

Watch Windows

When debugging, you can view the value of any property by hovering over its data port in the automation. If you want to “watch” how a property value changes while you step through your automation, you can right-click on the property and select “Add Watch.” The property will now be displayed in the “Watch Window.” Anytime the property changes, the watch window will update to reflect the new value. The watch window can display properties utilized in any automation, even ones that are not open or executing. OpenSpan studio also provides a special type of watch window called the “Locals” window. The “Locals” window will automatically display all of the properties in the currently executing automation.

Call Stack and Threads Windows

In addition to the “Watch” and “Locals” windows, OpenSpan Studio provides the “Call Stack” and “Threads” windows to help debug automations. The “Call Stack” window shows the previously executed blocks within an automation. This allows you to see what path was executed within your automation to get to your breakpoint. The “Threads” window shows all of the currently executing automation threads. This allows you to debug complicated multi-thread scenarios within your project.

Future Directions

With the 3.2 release, OpenSpan has for the first time provided automation developers with integrated debugging. We are already discussing additional debugging features for our future releases such as runtime match rule debugging. Let me know what other debugging features you would like to see.