Calling all integration experts!

Remember the old Universal Translator as modeled here by the late Mr. Spock? One of the first (or perhaps future?) examples of integration solutions, and certainly one of the most fondly remembere! But at its heart, it is also an almost perfect representation of the integration challenges today. Many years ago, there was EAI (Enterprise Application Integration) which was all about integrating homegrown applications with purchased package applications and/or alien applications brought in from Mergers and Acquisitions activity. The challenge was to find a way to make these applications from different planets communicate with one another to increase return on assets and provide a complete view of enterprise activity. EAI tools appeared from vendors such as TIBCO, SeeBeyond, IBM, Vitria, Progress Software, Software AG and webMethods to mention just a few.

Then there came the SOA initiative. By building computer systems with applications in the form of reusable chunks of business functionality (called services) the integration challenge could be met by enabling different applications to share common services.

Now the eternal wheel is turning once again, with the integration challenge clothed in yet another disguise. This time it is all about integrating systems with completely different usage a resource characteristics such as mobile devices, IoT components and traditional servers, but also applications of completely new types such as mobile apps and cloud-based SaaS solutions. In an echo of the past, lines of business are increasingly going out and buying cloud-based services to solve their immediate business needs, or paying a third-party developer to create the App they want, only to then turn to IT to get them to integrate the new solutions with the corporate systems of record.

Once again the vendors will respond to these user needs, probably extending and redeveloping their existing integration solutions or maybe adding new pieces where required. But as you look for potential partners to help you with this next wave of integration challenges, it is worth keeping in mind possibly the most important fact of all; a fact that has been evident throughout the decades of integration challenges to date. Every single time the integration challenge has surged to the top of the priority list, the key differentiator contributing to eventual success is not the smarts built into the tools and software / appliances on offer. Rather it is all about the advice and guidance you can get from people with extensive experience in integration challenges. Whether from vendors or service providers, these skills are absolutely essential. When it comes down to it, the technical challenges of integration are just the tip of the iceberg; all the real challenges are how you plan what you are going to do and how you work across disciplines and departments to ensure the solution is right for your company. You don’t have the time to learn this – find a partner who has spent years steeped in integration and listen to what they have to say!

Why enterprise mobile applications need an mBroker – part 2

mobile marketingThis is the second in a series of posts about the mBroker, an essential component of enterprise mobile application deployments.

The previous post discussed the general need for broking services to handle differences in mobile and corporate application environments. In this post we will look more closely at the security issues that mBrokers address.

Mobile applications are often written in the REST style using JSON as a format, because these mechanisms are simple, lightweight and perfect for the limited resources available to mobile devices. However, when these applications need to use corporate applications and APIs it can open a number of security holes. For starters, in the corporate SOA world integration is usually addressed through SOAP-based messages and web services. SOAP messages are usually encrypted, and there are extensive security protocols built into the web services standards specifications such as WS-Security. But the REST style of programming has little in the way of security protection; after all, REST is basically calling up URLs in a similar fashion to when you are surfing the net. This means that data may be ‘in the open’ and therefore exposed to prying eyes, and also intercepting the data and injecting malicious content is relatively easy.

The mBroker security services address these issues. For example, policies can be put in place so that sensitive information can be detected and secured, and the traffic can be scrutinized on entry to the corporate network for any injected threats or attacks. For example, content might be restricted to a small set of QueryString parameters, headers may be inspected to identify the type of data expected, and so on.

The other tricky aspect of securing enterprise mobile applications is the authentication and identity management area. As touched on in Part 1, OAuth is a loose standard providing a mechanism for delivering a level of authorization in the mobile world. In essence, resource owners authorize other services to use only that set of resources required for the task. The idea is that instead of having to log in everywhere, exposing your userid and password to different third party systems, the OAuth mechanism enables you to share a token with the service providers that restricts access. However, OAuth is quite new. OAuth was a typical web-based user-driven project which has now been developed, with OAuth 2.0, into a wider reaching standard specification. Not all of the web community are in favour of this wider direction, and the fact that OAuth 2.0 is not backward compatible with OAuth has not helped the situation at all. As a result different third party environments may not support OAuth at all or may support different levels.

Again, this is ideal territory for the mBroker. The mBroker can provide consistent OAuth implementation across all services, as well as bridging between OAuth and non-OAuth forms of authentication as required.

So mBrokers provide the mechanism to ensure that mobile enterprise applications do not compromise your corporate security goals.

Why enterprise mobile computing needs an mBroker – part 1

mobilephonesMobile computing is all the rage, with employees, consumers and customers all wanting to use their mobile devices to transact business. But how should an enterprise approach mobile computing without getting into a world of trouble? How can the enterprise future-proof itself so that as mobile enterprise access explodes the risks are mitigated?

mBrokers are emerging as the preferred method of building a sustainable, governable and effective enterprise mobile computing architecture. The mBroker brings together ESB, integration broker, service gateway, API management and mobile access technology to provide the glue necessary to bring the mobile and corporate worlds together effectively and efficiently; for a summary of mBroker functionality see this free Lustratus report. In this first post in a series looking at mBrokers, we will look at the fundamental drivers for the basic broking functionality offered by mBrokers.

Integration brokers have been around for many years now. The principle is that when trying to integrate different applications or computing environments, some form of ‘universal translator’ is needed. One application may expect data in one format while another expects a different format for example. A trivial example might be an intenrational application where some components expect mm/dd/yy while others want dd/mm/yy. The broker handles these transformation needs. But it plays another very important role apart from translating between different applications; it provides a logical separation between application components, so that requestors can request services and suppliers can supply services without either knowing anything about each other’s location/environment/technology. In order to achieve this, it provides other functionality such as intelligent routing to find the right service and execution location, once again without the service requestor having to know anything about it.

Enterprise mobile applications face a lot of the same challenges. When crossing from the mobile device end to the corporate business services end, the same problems must be addressed. For example, mobile applications often rely on JSON for format notation and use RESTful invocation mechanisms to drive services. But many corporate networks employ an SOA model based around XML data and SOAP-based invocations of services.  In addition, the same sort of abstraction layer offered by integration brokers is beneficial to avoid the mobile device needing to know about locations of back end applications. It is therefore not surprising to find that integration broker technology is one source for mBroker technology.