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.

Well a few interesting updates from my last Blog!

First, I have turned over to the dark side and brought my self an Apple MacBook Pro (my first Apple since about 1985 !). Of course, I have VMWARE on it and running both XP and Leopard at the same time. My first integration problems were human (aghast, no mouse right-click). I also tried to move my Apple Itunes music from my XP but Apple assumes I am a thief and won’t let me migrate most of my music or even my pictures. My 16 year old son assures me there is a way to do it but likely it will not involve integrated Apple software :)

Second, I am finally hip as I have added a song to my verizon phone (which you’ll hear when you call me!). Thick as Thieves. A little biased because the single of this track from the Dashboard confessional album is out next month and my son made the video (and is the star doing the magic – in one take…).

OK, so now onto business. This month saw OpenSpan release it’s version of Studio that enables existing and new automations to be turned into consumable web services with just approximately 10 clicks of a mouse and a few property settings. I show a Microsoft Excel function calling a web service to extract information out of an old VB billing system (hidden), on the fly. It is so fast and robust. What’s really cool too is that Excel and the automation are running in different virtual machines so it is fun to see MS Office and legacy applications work together over virtual machines. I’ve been tracking analysts who started to pass on that enterprises are finding the lack of Virtual-Virtual machine integration a stumbling block! Not any more!

I also have a server, running automations in VMWARE sessions exposing web services to the world. The VMWARE / OpenSpan sessions are integrating into previously closed applications and presenting a web service API (in this case as a REST function). Who would have thought some idiot (me) would web service enable the win32 windows calculator – just to prove a point – LOL – but wickedly cool.

Going to be announcing two other major enhancements in the next few weeks so watch this space. This technology gets more exciting by the minute and judging by the new customer and partner wins we are not alone in this excitement.

Signing off (next post will hopefully be from the Mac ;) ).

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.

One of the questions we frequently get asked is “When should I use client-side integration instead of server-side integration?” Typically, we provide a list of scenarios where client-side integration is the only viable option:

1. You’re planning to deprecate the application and don’t want to spend money on it anymore.
2. You didn’t write the application, but it doesn’t have an integration layer or it’s integration layer doesn’t provide access to the functionality you need.
3. You wrote the application, but you don’t have anyone with the skillset to modify it or you don’t have the source code.
4. The application doesn’t have a backend. It’s client-side only.

Today, however, I’d like to make an argument I don’t think we make enough. For many scenarios, client-side integration is the best option, even when viable server-side options exist.

When?

When you’re trying to make your users more productive.

Why?

Because you’re spending your money making what they do easier.

You’re not spending your money exposing integration points for user oriented tasks. You’re not spending your money writing a new user interface that wraps or embeds older functionality. You are automating tasks. You are eliminating errors. You are making your user experience better.

In our industry we are accustomed to thinking that there is only one way to solve user productivity problems: a new user interface. Typically, this means jamming as much functionality as possible into a single window using mashups, portlets, frames, tabs, etc. Now you’re users don’t have to switch between different windows to do their job.

But was that really the problem? Instead of multiple windows, they now have everything in one place, either smashed together or separated into tabs or frames. They now have a new user interface to learn rather than the one they were accustomed to. Moreover, you’re application developers are now spending their time creating portlets, web services, etc. rather than adding new functionality.

But what if the user interface you already have is the best one for that particular business function. It was designed for that specific function. It has been through multiple improvement cycles. It does what you need it to do. Were you really unhappy with the user interface or were you unhappy that you have to switch back and forth when you copy and paste? Or that your workflow requires you to look up the user in three different applications? Or that it takes too long to place an order because the wizard was designed for the public website?

Why are there still so many host systems in the enterprise when windows alternatives have existed for thirty years?

Because their faster than windows systems so your most productive, expert users don’t want to let go of them.

Why are there so many windows systems in the enterprise when web alternatives have existed for 10 years?

Because their user interfaces are more rich than web systems so your most productive, expert users don’t want to let go of them.

When you’re trying to make your users more productive, server-side integration is a sledgehammer when you just need a hammer. Your server-side architects and developers should focus on the big integration problems: synchronizing data, backend transactions, exposing web services for your partners. User productivity is a different kind of problem that requires a different kind of solution.

OpenSpan allows you to improve user productivity without changing all of your applications. It allows your users to be more productive without having to be trained on an entirely new system. It allows your users to do what they always did, but faster and with fewer errors. It allows your application developers to focus on new features instead of integration. It not just the only solution, it’s the best solution.