Integrating applications -at least at the enterprise level- is today generating the same amount of work, or even more than building new ones. In fact, it can be argued that as far as corporations keep exposing their business processes as cohesive and autonomous services, integrating them in new configurations is a way of producing new applications.

However, Service Oriented Architecture adoption is still timid and it is primarily been adopted in new development, whereas just a small portion of old corporate solutions are wrapped with a service layer than can be exposed by using standards. In many scenarios, making applications interoperate takes more work and means rewriting parts of the applications. Let's take a quick look at the several approaches that are available to integrate them.

While most of the time we try to integrate at the back-end, at the business-logic or database levels, sometimes this is too difficult to do, mostly with old-style applications that doesn't have properly isolated components or tiers. This may sound like heretic after so many years of talking about n-tier development and even SOA, but consider how many core solutions running on mainframes are working since decades, before the idea of separating the logic from the UI came along.

For this cases, there is a series of well-established patterns by now for front-end level integration. Indeed, several toolkits or frameworks are available to make easier to automate UI to be able to use it programmatically. In this cases, a framework allows to do screen-scrapping and input injection for old TTY consoles, adding a layer that allows to automate menu selection, data entry, and then screen reading, even contemplating error or warning messages, so you can expose a service for some operations that are actually performed by using the old terminal interface running on a non-visible server emulator.

Sounds sloppy? Well, it is, but you know the distance between what's ideal and what's possible can be really large. Sometimes you don't have access to the code of these legacy systems, or they are running on platforms where the technology to isolate and expose services from the core -not from the UI- is not readily available.

While you have to be careful about this idea, properly dimensioning the usage load to avoid hogging the legacy systems, the benefit of this approach is that you don't need to touch it at all. Actually, the system is never aware of been used from a non-human consumer.

Indeed, this approach is also extended to improve efficiency in multi-application scenarios like -typically- call centers. There the typical user interacts with customers and has the need to access many different corporate applications depending on the task. They could need to access the CRM, a sales order entry system, a claiming or trouble-ticket application, account balances, statistical or historical information, or related systems owned by subsidiaries or even merged companies not yet unified.

In such scenarios we are seeing an increased adoption of composite desktops, where the user can host several different applications (from terminal consoles to windows to web interfaces) into a unified (generally tabbed) container. The advantage of using this kind of container is that it can react to specific UI events, like messages, alerts, refreshes and so on, and make them converge into a unified experience.

Moreover, applying different interaction techniques for different applications, the container can replicate certain actions, saving manual synchronization effort to the user. One implementation fo this concept is found in the Customer Care Framework from Microsoft. Based on the foundation of the Composite UI Application Block (CAB), it provides a hosting environment for different types of applications and allows scripting to orchestrate the user interfaces by means of the appropriate mechanism in each platform. Thus, when the user enters a customer code in the application having focus (let's assume it is a windows CRM), the container can forward this code (even translating it if the underlying systems have different codes) and search the same customer in a second application (using the HTML DOM for a web app, for example) and do the same for a third one (using the keyboard buffer for a console app, for example).

These kind of tools provides all the abstraction to read or write from several different UI sources (screen scrapping, DOM, windows handles and controls, even Java applets), and then they build on top of that, providing higher level services like single sign-on, where the operating system credentials are converted into the proprietary user/password combinations needed and send trough the different clients in a secure way, plus messaging, state saving and forwarding, and so forth. It also allows to easily integrate the contained applications with devices like a PBX or other caller-id mechanism, and more.

Of course, this is a mid-term solution, and it should never been taken as a replacement for real systems integration, which is better done on the back-end. But when you are automatic the user experience rather than clearly-defined business processes, this is an option to take in consideration.

Integration is such a broad topic that I hope to go back to it and talk about other part of the problem soon. By now, I just wanted to comment on an often overlooked alternative, which can be faster and cost effective, although it is usually a short-term solution while you work on the longer plan.

We seem to be in the verge of an important change on computer interfaces. The mighty keyboard dominated the human-to-computer interaction from the last 50+ years. Indeed, since its beginning, in the form of a teletype first, then in a more direct way. Output was more complicated, and moved ahead a bit faster with the jump from cards to printers and finally to the still dominating (but slowly fading) Cathodic Ray Tube.

Anyway, computer history is not linear, but logarithmic, and while the mouse started shaking its tail just a mere twenty-something years ago, it became so ubiquitous as his cousin keyboard, and certainly more fashionable.

But in the last years we are seeing a lot of wanna-be interfaces trying to win over this dynamic duo. Technology declared obsolete the CRT and it is being replaced by LCDs, which are maybe in the process of being replaced by OLEDs, but the important thing is that this sparked a myriad of new screen formats, from 19" notebooks to 2" portable video players. In one corner, multi-monitor setups are gaining adoption, while many of us have several tiny screens where we keep up with our schedules, calls and videos.

Pointing at screens with a stylus first and then with a finger is so common, than many are pushing for the next step which is allowing you to use as many fingers as you want, as in the talked-about-ad-nauseam iPhone to the still niche Microsoft Surface. But really, if you try any of this devices (I played with a prototype) you see there is a lot of great uses it can enable.

Still, I can't see touch screens of any kind wining over the mouse any time soon. I can't imagine having to touch my notebook screen all the time. The small arrow has the nice property of not hiding anything, and your hand can move the mouse over the table, so you don't get tired too soon. But someone smarter can figure out a better way than the mouse, maybe...

The keyboard seems a more difficult rival to me. Even if voice recognition improves a LOT, and even if you are a lousy typist as I am, I guess the keyboard is more practical. For people who mostly write prose document voice can be a great complement, but I can't imagine how to edit text easily with voice commands. And definitively, I can't think of programming with voice... can you? Just try to read a piece of code aloud...

In any case, these innovations and additional input and output devices will be increasingly common, if they still can't beat old Querty and Mickey. And we as developer have to start thinking on them more seriously. I guess the days of the pop-down menus are over. Even desktop application interfaces are sliding off them. Look at Office and their ribbons. Even if you don't like them too much, I think they are more effective than the previous polluted menus.

Well, maybe what we have to think more and more about is separating the interface from the logic, but this time for real. While we got accustomed to tiered applications, we still have a tendency to think in menus and data entry screens as the UI when we think in our domain model. It noticed that some time ago when I had to provide an IVR interface (phone-based, with a mix of voice and button commands) for a system. My team have to make some changes to the business objects to make them more usable from something different than a windows or a web page.

Windows Presentation Foundation, and now Silverlight, as Flash is doing from some years ago, makes the need for this separation more clear, and we can see separated tools, with some capabilities in the middle, for both interaction designers and programmers. And I avoid saying "graphic designers" on purpose, because there the web was full of graphic designers producing nightmarish interfaces because they were not prepared. Interaction design is much more than that. I guess this could be the next hot area for the upcoming generations, together with our now old profession.

Some time ago I wrote about some limitations still blocking the scope of things like web applications. I was seeing how many different players in the industry were taking a new look at the problem of disconnected browser-based programs, which is one of the main shortcomings in this space. In the last month or so several important announcements has been made public, and some basic support for this scenarios are actually working right now.

For once, Google just released Google Gears, its browser extension that adds offline support for applications. This is in a very early stage and thus it is just adding basic functionality like a local web server to serve locally cached content, a small local database to hold data, and a little thread pool to ease the handle of asynchronous tasks. As several people noticed, there is a bunch of stuff that's still missing, mainly more features to handle different synchronization scenarios, which is something that the current implementation leaves to the developer. But for the first release, this API looks really promising.

On the other side of the fence, Microsoft recently released Silverlight, which has planned offline support although it is in an even early stage in this particular area. However, the scaled-down version of the .NET Framework runtime is a perfect sandbox strategy to provide this kind of services in a safe and easy way, and this is something they definitively ave in their roadmap.

At the same time, Silverlight brings another push to other area where web applications were often turned down: rich applications. While it is true that Flash is a well-established platform, so far it has been mostly used in areas like marketing, games and other niches. Microsoft is trying to push Silverlight and its promised simplified programming model to a wider audience, including business applications and other typical markets where Flash didn't penetrated much yet.

In the meantime, another huge trend both competitors are heavily pushing now is mashups. These are web applications built out of parts, much like you could build with components before, but in the lousy-connected scene of the web. Microsoft has PopFly in Beta, while Google has its own Mashup Editor.

What's interesting in this space is that you can built a valuable service out of already existing services and sources by adding very little code or configuration on your part, usually just connecting outputs with inputs. But of course, this poses a new series of challenges, like the need to store this configuration and data somewhere. As it is usual in the mashup style, you may not own or control the server where you are hosting your creation, so finding a store for your data is not that easy. Also, as this kind of strategy evolves, there is an increasing need to have a standard way to access some specific information which has a more complex structure than what RSS or Atom supports.

Microsoft came up with a very interesting approach to help in this issue with a project called Astoria. What they are trying to provide is data services over the web, and this really captivated my attention. I had always discouraged people to try to use web services as a data service, in the typical sense of exposing a "query" service over HTTP. This something I reconsidered in certain cases once we arrived to the point where we were talking about XML Services (without the "web" emphasis). My main concern was always the high-latency nature of the whole SOAP-HTTP combo. Providing data access over the web means that you need to add to the actual database access a lot of overhead in the form of packaging, connection and disconnection, etc. This can decrease once you use SOAP over TCP, etc, but still SOAP is not designed to handle this kind of situation.

Astoria take a more RESTful approach (basic background on REST architecture in Wikipedia). It is based also on the ADO.Net Entity Framework (another piece of yet-unreleased software) that provides a conceptual model over a given physical database schema (to follow me, just think of it as sort of Object-Oriented Database). An Astoria service provides an entry point to this model, where you can start by querying its content (like "http://host/vdir/northwind.svc") and get an XML with the entities (kind of tables). Then you can refine your URL based on this information, to access a specific resource. I won't make this into an Astoria overview, but what's important is that this allows you to get the equivalent of select, insert, update or delete operations over the web, with a fairly good throughput, and -more importantly- with a single consistent mode that allows tools to be very generic. For example, there are some sample controls for ASP.Net that will figura out the whole structure of an Astoria service and allow to navigate trough its data by using grids with sortable columns, filters, paging and editing without any other configuration than the entry point (again, this "http://YourServer/YourModel.svc").

The point I'm trying to make is that we are starting to see some forbidden territory explored. I guess that sooner than we expect we will witness how cities are built over there. Convergence is happening really fast, and the traditional lines we take for granted today between desktop, web and mobile applications are finally starting to fade. New technology and faster communications are accelerating it.

I'd just want that the level of quality of the produced solutions evolved as fast as its reach... What do you think?

Programming languages have gone a long path, as you can see in this nice diagram by Éric Lévénez. Throughout its history, programming was always searching for the perfect balance between several forces like expressiveness, productivity and correctness. While the first two evolved with object orientation, higher abstraction and an increase in composability (as more and more reusable algorithms and even executable code accumulated), correctness was somehow slower, maybe because it is a more complex problem, and maybe because for a relatively immature industry, the competitive advantage seemed to be more productivity-related.

As software became more pervasive in our daily lives, however, predictability and safety in execution started to be bigger concerns. Also, software lives more and more as part of an ecosystem, where dependencies on other services its crucial, and minor mistakes or errors get quickly magnified.

Verifying that a program is correct is a tricky task. For once, intention has to be clear to be able to know what to check. Then, inputs and outputs have to be clearly defined, allowing to detect any misbehavior. Even at a lower level, some operations over the platform have to be validated to avoid problems in the hosting environment (like memory leaks, drying resources, locks, etc).

From an academic and mainstream perspective, so far, the tendency has been to solve these issues by strengthening the runtime environment (like the Java Virtual Machine or the .NET Framework), and letting it handle dangerous operations instead of the languages, and also making the compilers smarter to detect as many problems as early as possible.

To enable this many languages (like Java and C#) followed the C++ path of strong typing. The focus of type safety helped to make compilers much better, but also helped with many other levels of checking, like static analysis, which allows to provide a higher level overview of a system and detecting more subtle things like compliance to specific practices or conventions.

Strong typing also helped providing better contextual information within IDEs, greatly improving features like Intellisense and refactoring tools, but until recently, it also added some verbosity.

While this mainstream approach captured most attention in the enterprise market, a grass roots movement with a noticeable mix of open source initiatives and communities pushed in a different direction: toward dynamically-typed languages.

This is indeed a complex terrain, as there is not a strict definition of what makes a language "dynamic". Some of their attributes, however, are things like runtime evaluation and dynamic creation of types and objects, and many times, dynamic typing, although this is not a requirement. Generally speaking, they are perceived as simpler to program and more functional in nature.

I personally feel very happy about all this renewed language explosion because I love this field, but I still see a greatest reward in static languages, coupled with some features that are usually perceived as "dynamic".

Type inference for example, arriving in C# 3.0, allows developers to avoid declaring variable types in many situations, by using the var keyword. This is handy and nice, but it is also great in the sense that strong typing is still there, because the type is inferred from the value been assigned.

Functional programming is making its way also in the form of lambda expressions support, but without the need of been checked at runtime. I really prefer lambda composability over runtime expression evaluation, as it provides a much safer experience and fastest feedback.

But dynamic languages (and the DLR) will provide a good complement to strongly-typed languages, like a good way to handle scenarios where late binding is a need, or contributing some interpreter environment for checking short snippets of code without the need to have projects, compilation, etc. This is great to quickly instantiate stuff and play around, then getting code into a program.

I guess that convergence is here, and the will be no real static vs. dynamic fight in the end, but a great leverage of all the languages strengths. This will boost productivity and safety at the same time, and I hope programming would be able to make a quantum leap as a discipline pretty soon.