Wrapping Legacy Applications - IT JUST WORKS

A legacy application is not just an 80x24 green screen. It can be;

* A windows Client Server, fat client or thin client application
* A web application plain old HTML
* A web 2.0 Application, script, Java, ActiveX (with embedded widgets)
* A Java applet or Java Application
* A custom application (Salesforce.com, Oracle Forms, Lotus Notes)
* Packaged Applications

You get the point. If it’s deployed live, it’s legacy.

So, for years we have wrapped green screen applications successfully to enable their business functionality to be consumed by other technologies. Heck, many of your ATM transactions are just plain wrappers on mainframe applications and screens. The good thing about this approach is - IT JUST WORKS (my new motto). So, wouldn’t it be nice if we could “wrap” any application like this, not just 80x24 screens but all the "other" stuff. Well, now we truly can. OpenSpan Studio enables virtually anything that runs on the Windows O/S to be wrapped – exposing the deep UI elements, controls and transactions (robustly and securely) to any mid-tier technology. You can even take any of those legacy applications and move them to the server room (thanks to Virtualization) and run them completely without a user ever needing to see them again! SOA enablement of legacy applications - it's here now.

This approach is crucial is 2009 for delivering quick solutions to the business. IT JUST WORKS.

So, whether the application is 5 minutes old, or 30 years old, if it has a UI, there’s a good chance it will be part someone’s SOA / API strategy in the very near future. Thanks to OpenSpan :)

Look at this quote from an Article on SOA in the SDTIMES last year if you needed any further proof.

The survey found that a majority, or 58 percent, of SOA systems contain components that are not designed to be interoperable as Web services. These include components that use non-SOAP messaging, such as IBM WebSphere MQ and Java’s Remote Method Invocation. Further, mainframe applications show up in 47 percent of SOA applications, and packaged applications accounted for 68 percent of components.

OpenSpan partners with IBM

Had quite a few people ping me today since this great news hit the wire.

I was in Orlando this weekend and attended the IBM Lotusphere 2009 event. Whow, that was a big turnout. What we were demonstrating was interrogating components of Windows applications right within Lotus Expeditor and enabling you to wire any of these UI elements to any of the other Lotus API's, portlets and components within Expeditor.

OPENSPAN ANNOUNCES WINDOWS CONTAINER FOR LOTUS

Also, OpenSpan has achieved Advanced Level World-wide Business Partner status within IBM's PartnerWorld.

This continued expansion of the OpenSpan reach through partners like Software AG, Microsoft, IBM and Tibco is proof that the OpenSpan desktop integration technology is not only necessary, but in demand. Broad Integration techniques is key to successfully unifying user applications on the desktop and having them interact with other client applications and server components, regardless of underlying platform technology. We are pleased to have IBM on our team :) And of course, being on the IBM team.

Another useful link talking about the IBM Expeditor product can be found here : Using IBM Expeditor toolkit to extend IBM Lotus Sametime

Of course, I'd be amiss if I didn't point out this news story too : IBM bucks gloom with rosy outlook
.

Creating an API into any desktop application

I blogged today about what makes an application a legacy application (see link Below).

I am fanatical about Desktop Apps needing API's to increase productivity for users. You going to see me write a lot more about this in 2009 because I believe if there was ever a time for people to recognize that desktop API's can provide rapid and massive ROI, it's now.

I started questioning when and why developers stopped building API's into client (Fat or Thin) applications.

HLAPPI was created to enable mainframe applications to have an API and created significant productivity enhancements on the desktop. Around the same time, with similar benefits, Microsoft Office came out with DDE which was an API for Office apps. I am (was) a very experienced DDE programmer (eek). DDE was pretty bad and probably gave Desktop Application Integration a bad name (there was no error checking at all). MS OFfice came out a few years later with OLE which was a lot more robust. Then came Visual Basic Macro's for Office. DDE, OLE and VB are all desktop productivity API technologies that have been very widely used over the last 15+ years and there is no doubt, led the way in Office / Desktop Productivity.

Funny, all of these are in still in wide use today. However, enterprise users use more than just mainframe and office applications developed internally or packaged. Yet few of these other technologies support any other kind of API except POCAP (Plane Old Copy and Paste).

Imagine, any existing (old or new) desktop application being given it's own, "instant-on" API. Even if you don't own the application or have the source code to it! And better, unlike Visual Basic, you create the API yourself with a simple Drag and Drop Visual designer technology and better still, the API can be exposed as an SOA Web Service (REST or SOAP) so any other newer technology can consume and integrate it in minutes.

OpenSpan studio does just that. It opens up all of the 100's of 1000's of desktop applications running in the enterprise today, for integration. Once we give these applications their own API (which can be instantly), the power of integration and automation is yours for the taking. It might have taken over 15+ years to realize that API's in these applications are invaluable and key to productivity gains, but at least we are here now, finally with a working product that enables it.

What makes an application a legacy application?