Solutions Architect

The ecosystem of integration

There may be good sense for some users to throw in their lot with one of the major 'soup-to-nuts’ vendors capable of providing all elements of a service-based environment that most enterprises might need, but for others this will be far too extravagant and costly. What is more, as Gordon Van Huizen, Sonic Technology’s CTO points out in discussion with Martin Banks, there is a growing trend for the technology required to be effectively 'parcelled’ up into more readily understood and digestible chunks.

Sonic Software had built up a good reputation in the world of messaging before its takeover by Progress, but with new resources behind it the company is now pushing hard to extend the reach of its Enterprise Service Bus (ESB) offering to a new level of abstraction – essentially the ecosystem of the enterprise interconnect. This is just one of a growing number of inter-relating and interoperating ecosystems from which solutions architects will be able to construct the service infrastructures the business processes will require.

Martin Banks: Some companies – and IBM is the obvious example – are creating user awareness without being too specific about what users might actually require. But as SOA starts to develop there seems to be a growing development of modularisation of the infrastructure, the coming together of different companies to build ecosystems – is this welcome?

Gordon Van Huizen: Absolutely, and we see it happening. At the same time, we envision a world with grater interoperability between vendor offerings. Users will pick different vendors for different applications and functions. In future, the need will be to mix and match offerings out of the box.

MB: There is a change coming. It no longer matters so much about which operating system is selected. Compatibility at the infrastructure level now seems to be the important element. So it is likely that pragmatic de facto standards will become the targets to which applications developers then work. Do you see Sonic as one of those standards?

GVH: Exactly, though it will take a few iterations to get there. Our target is to continue to work with other vendors and consortia around that approach.

MB: Does this mean that companies like Sonic will be obliged to stand very still for as long as possible, not changing the technology as often as before, thus removing the easy way for a software company to make money – namely regularly moving the goal posts?

GVH: Absolutely, let me give you an example. When we developed the ESB we also created a development environment that didn’t exist before, so it was by definition, proprietary. But there are some important architectural notions in that development environment that we would want standardised if there is to be interoperability within the infrastructure. For example, there is a need for a normalised way of dealing with messages, a normalised way of configuring and deploying a service, a way of binding between generalised services and a specific protocol.

We felt strongly enough about creating a market around this that we have invested in working with Sun and other to create JSR 208 in the Java Community Process, which is the formalisation and standardisation of those very elements. Sun is the spec lead on this project but much of the architecture comes from what we’ve been shipping for the last couple of years. It is also referred to as Java Business Integration (JBI).

So in the same way that J2EE allowed a market for application servers to emerge by identifying the capabilities that were required, JBI will help shape the future market for the integration environment. There will be a reference Implementation from Sun and we will make sure our offerings are compatible. We think this is fundamentally required if the market is to develop, and we will derive revenue if a market can emerge around these standards, rather than as a proprietary solution. If you have the right elements with your product and satisfy the needs of the architect, the developers and the organisation, then the standards are going to be helpful, though not an equaliser. So that very much is the model we are following.

MB: In a business sense it is counter-intuitive to handing over the crown jewels in this way?

GVH: You have to be careful. There is such a fine line between what needs to be specified for interoperability and what represents your competitive advantage. We’re entering a new arena of collaboratively exploring territory that has always been proprietary. Fast, reliable protocols that can be used across a set of co-operating nodes, for example, have always been proprietary stuff. But by being a smaller vendor we can be a bit more aggressive than others. We’re interested in the overall programming framework becoming standardised – and that is `framework’ as in the way developers define the pipeline component model for message processing, for example. This is largely what JSR 208 represents.

MB: What about involvement in areas such as Model Driven Architecture. Is that something for Sonic?

GHV: Yes, and it’s interesting. There are a number of different ways of co-ordinating services. There are messaging models, intelligent routing etc. It should be possible to have a visual model that abstracts that away from the architect and we are investing in building suitable visual modelling tools. Our products import UML and our visual representations are largely UML based. But MDA is a much less grounded than UML. It is developing artefacts based upon an abstract model and we have yet to see how effective that will be for applications component development or the artefacts that will live in the distributed environment.

MB: For developers, what is the relationship between the infrastructure and the application?

GVH: This is a key debate. A significant portion of the controlling code, the logic and flow, will move into the Enterprise Service Bus. It is going to move from an applications server and be distributed across the infrastructure. Whenever you start co-ordinating the interaction of multiple systems surely you’d want that in a layer that you can configure and manage on its own without introducing hidden dependencies between the applications through the visual tool you’re using or code development. We have found, for example, that the pioneering organisations in SOA have experienced some amount of pain through inadvertently building in hidden dependencies, so they are now looking at what is the right architectural model. It is too easy with SOA to push it all into the application. It is the most comfortable and familiar place for many developers and architects, and a lot of tools and frameworks on the market reinforce that idea. We certainly believe that this will change, but it takes time.

MB: Will the next level of development tool allow code components to be logged by their functionality so as to build up function libraries from which services are constructed to meet specific business requirements?

GVH: I certainly think this is the way it is going to go long term. But there is a benefit in the near term to think about the appropriate interface model. One of the reasons that Object Orientation and component architectures haven’t succeeded so far is because the semantic model has been wrong. There are virtually no plug and play capabilities between objects in different environments, even with the right way of representing them. It isn’t until you reach the right level of abstraction around the interface that you have something that is re-useable. That is why there is the apparent shift to message-driven or event-driven environments. It is a lot easier to understand a business event than it is to study seven or eight different method signatures and how to construct a message flow across them.

It surprises me that it has taken the vendors so long to talk about what is the right interface. It is one of the reasons we evangelise around the event-driven, message-driven model. I think we’ll see some formalism around that in the near term. Then it becomes easier to catalogue what is out there and do something with it.

MB: So it seems the IT industry has got to the point where it knows a vast amount about the wrong things?

GVH: I agree, and we keep doing it. We are still arguing about 'copperplate versus courier’ rather than what is written. There is still not enough discussion about how we tie these things together.

www.sonicsoftware.co.uk