Tibco takes pop at SOA complexity
Tibco last week announced the general availability of TIBCO ActiveMatrix for service-oriented architectures (SOA). This is the industry's first “service virtualization platform” for the deployment and governance of composite applications based on distributed, standards-based services".
Tibco is in competition with Oracles and IBM and such-like, which will probably say that ActiveMatrix is unnecessary. But we think it could be important stuff. In essence, the ActiveMatrix “service grid” is a virtualisation layer sandwiched between services orchestration and the platforms (J2EE, .NET) the services run on.
So, the deployment of code running on physical platforms can be managed independently of service orchestration. ActiveMatrix addresses a possible issue with SOA scalability and availability - if a service is being heavily utilised, say, you may need to deploy more servers under the hood, but this shouldn't be part of your SOA orchestration. ActiveMatrix lets you separate deployment aspects of SOA, such as configuration, security and availability.
It does this, in part, by extending the idea of the SOA UDDI services registry, which, as standardised, is simply a subset of what is required to manage a SOA environment. ActiveMatrix includes a UDDI Registry but adds a separate "policy manager". This implements runtime governance of the SOA environment, using active agents, which enables reconfiguration/deployment in near real-time. This is a pro-active policy management, based on feedback from the operational environment.
The overall impact is to return control of SOA to the customers, who can now concentrate on thinking about service-oriented business models and business cultures, rather than on how their vendor implements its view of SOA.
With ActiveMatrix, orchestration designers needn't care if J2EE or .NET, or whatever, is underneath. Without it, services must have embedded housekeeping code dealing with security, transactional behaviour and so, which, to some extent, depends on the underlying technology platform. This is a particular issue with legacy applications - especially Microsoft-legacy - enabled as services. ActiveMatrix enables you to manage this code independently of the service and the platform that the service lives on, which should give you greater freedom in the design of business processes.
Endpoint services can, it's claimed, contain as much as 40 per cent less code if they run in ActiveMatrix containers (although ActiveMatrix can also manage full .Net or J2EE services). Pushtotest, for example, reports writing a web service to sell licences to its manuals, in which 465 lines of business logic (order validation, inventory control, credit checking) needed 85 lines of WSDL deployment description etc; 96 lines of security description and 89 lines of Message Provider configuration. That's almost 40 per cen t of the code that could be handled by ActiveMatrix.
However, because ActiveMatrix is standards based, customers presumably aren't locked in to Tibco, although they'll have to write the 40 per cent of extra platform-dependent “glue code” if they want to transfer "pure play" services on Tibco over to the other vendor platforms, of course (which some may see as a form of fairly benign lock-in).
To summarise, Tibco touts a fully managed customer-led SOA platform in which businesses can orchestrate pure vendor-independent services in composite applications, in pursuit of their own business-level SOA strategy.
For developers, ActiveMatrix promises them a chance to move up a level into building composite applications with direct relevance to the business. This won't just look good on their CVs, it may help the business see them as part of the solution rather than as part of the problem - and make use of the CV less necessary. As my colleague Martin Banks says “Yep, and it's a point that needs to be made repeatedly, I feel. Times are changing for developers; they are starting to become ‘business process architects’ or some such title”. ®