At the end of April I’ll return to California, TIBCO, the wonderful world of SOA, and everything else.

Motivate your IT architects and managers to reuse services by making such reuse a part of their bonus program. Reuse is a cooperative thing, and requires that both the provider and consumer are motivated. To further this cooperation, reward IT managers not only for reusing other services but also for having their services reused by others.

Incentive programs like this can go awry, but your SOA Center of Excellence (or Service Steering Committee) will protect your from problems of that sort.

• Who Pays for Reused Services?
• The Definition of ESB as 2006 Ends
• Design for Performance Applies to SOA
• TIBCO ActiveMatrix Press Round-Up
• People are Talking about Service Virtualization

There are many barriers to reuse and to creating a reuse culture. We are all familiar with NIH syndrome (not invested here), connectivity challenges, upgrades tied to dependencies, and potential performance mismatches. Charging for service use adds another challenge. Internal budgets for service reuse don’t exist. Pricing for service reuse will need to be debated and sorted out. And, frankly, the fact that it will cost money to use a given service might just be the excuse folks are looking for to not reuse that service, and to instead write their own version.

Tracking service use is another major challenge. Beyond the organizational changes required to track service use and formally charge other departments, the technology required to do that tracking is major obstacle. Unless you are using a service container or service virtualization platform that provides this functionality out of the box, you will need to adopt a complex service management platform far earlier than otherwise.

Avoid these headaches and start out with a different approach. Create an SOA center of excellence (something you should do anyway) and force each and every department or business unit to share funding for this new group. The center of excellence (COE) should be tasked with:

• building the first SOA projects
• building the infrastructure services
• training other groups who want to build services
• new software purchases required for SOA
• distributing funds to other groups who are building services
• maintenance and scaling of the early services

It is important that services catche on outside the COE, so make sure the funding strategy forces the distribution of funds to other groups who are building out reusable services.

Over time, the funding for this new group should fall off and companies should move to a charge-back model. The first few years an organization builds out services and builds their culture of reuse are very important. Starting with a charge-back model will stifle the adoption of true SOA.

• Pay Your Managers and Architects for Re-use
• Design for Performance Applies to SOA
• The Definition of ESB as 2006 Ends
• TIBCO ActiveMatrix Press Round-Up
• People are Talking about Service Virtualization

I started this blog about a year ago. Initially, I just wanted a place to stick things so I’d be able to share them with friends and so I’d be able to find those things again later. From there, I started posting longer articles on products and services that I was really happy with. In December, at work, we launched TIBCO ActiveMatrix and I wrote about that a few times. Slowly, folks found my site and the traffic grew to about 70 unique visitors per day and 50 feed subscribers. Co-workers found the site and people started to mention it when I ran into them in the hallways.

With all this attention, I took a look at my site. Frankly, I was a little embarrassed. The site was painfully slow, the design was awful, and the content was all over the place. Looking around at some of the other sites out there, I had some ideas. I didn’t have the time or knowledge to do what I really wanted, but I did manage to improve things. The major changes include:

• faster web host
• latest version of Wordpress
• new site design
• separation of content into “sub-blogs”

As a result, things should work properly and I’m happy enough with the site that I’m comfortable posting content here again. Looking at what I was writing about, and looking at what people were interested in, I divided the site into three “sub-blogs”: (1) SOA, (2) Technology, and (3) Random Junk. If you’re interested in my technology related posts, just check out rourkem.com/tech. If you liked the SOA and TIBCO related posts, check out rourkem.com/soa. If you really want to read my food and travel related posts, there’s always rourkem.com/random. Of course, there’s always rourkem.com if you really want to read all of the above.

For each of the above sub-blogs, there’s a corresponding feed. Take a look at the above-listed pages and shift your subsciptions if one of the specific feeds is more appropriate to what you’re interested in. If you’re currently subscribed to the main site feed and only want the latest SOA posts, for example, go to rourkem.com/soa and subscribe to the feed listed in the sidebar on that page.

I’m not very happy with the theme, but it’s an improvement. Given the time, I’d love to build a new Wordpress theme based off Sandbox. For now, though, this should work.

• Category Based Permalinks with Wordpress
• Segmenting My Personal Blog - Why?
• Standalone List Items in IE and Firefox
• Feed to Email Service Roundup
• Feed Hacks: FeedShake and Feedcatch

ESB implementations (ESBis) are manifestations of an enterprise design pattern intended to simplify the interconnection of services in a given environment. Most enterprise architectures today include some form of ESBi. Many SOA reference architectures include some form of ESBi. A few years ago ESBi was purely theoretical, but today there are mature implementations that cover the complexity gamut, from simple to very complex. I’d like to examine the different levels of ESBi in the future.

ESB products (ESBp) are designed to help companies build ESBi. The ESB market is mature and the definition of what makes an ESB product (ESBp) has been made clear over the course of 2006. This year has seen every major SOA vendor release of refine their ESB offering or offerings. Most of the analysts have released ESBp reports that score or compare the products. A number of magazines, including Network Computing and InfoWorld, have released ESBp round-ups and reviews. Folks, as 2006 ends we finally have a clear definition of what an ESB product is.

First, lets eliminate some of the confusion the acronym causes: not all ESBp offerings include a “bus” or messaging technology. Most companies already have some form of messaging technology and are best served by using an ESBp that does not tie them to a specific messaging product, but instead allows them to build out their ESBi using the messaging technology they already have. If you don’t have an enterprise-grade messaging technology already, then either purchase an ESBp that includes messaging, or purchase a best of breed messaging product in addition to the ESBp you select. Do not rely on a sub-par messaging technology simply because it came bundled with your ESBp.

At a minimum, an ESBp must provide for mediation on several levels, as listed below. This allows you to use that ESBp to onboard services to your ESBi. To facilitate collaboration and to facilitate re-use of the services you onboard, a good ESBp must integrate tightly with the version control systems and registry products in your environment. In most cases, registry support just means UDDI support. In order to deal with routing, cross referencing, and exception handling, a good ESBp will also have lightweight process support.

• transport level mediation, at least:
  • HTTP
  • JMS
• message format mediation, at least:
  • SOAP
  • POX (plain old XML)
• security mediation (in the form of SSL and WS-Security)
• message format mediation (in the form of XSLT/XPath)

Performance, scalability, and fault-tolerance are assumed. An ESBp acts as part of your communications infrastructure, and any downtime will translate into service downtime. Any latency issues will translate into service latency issues.

Even an entry-level ESBp must include a complete SOAP stack with support for all flavors of SOAP. If everyone exposed their services via WS-I compliant services there’d be far less need for ESBp’s.

The above requirements are the absolute minimum for a product to be considered an ESBp. In addition, more advanced ESB products (sometimes called ESB Suites or Integration Suites) will also have many of the following features:

• auditing of messages
• logging of messages
• MEP mediation (request reply : pub/sub)
• a rich set of transports
  • TCP
  • MQ-Series
  • TIBCO RV
  • Java RMI
  • SMTP/POP3
  • FTP
  • IIOP
  • COM/DCOM
  • etc
• a rich set of message formats
  • Cobol Copybook
  • EDI
  • fixed format and delimited file formats
  • .Net data marshalling
• rich collection of adapters to provide zero-code access to:
  • application operations
  • application metadata
• advanced monitoring and management
• integrated debuggers

Service composition and service orchestration capabilities are often bundled with ESB Suites and Integration Suites. There are advantages to having these capabilities tightly integrated with your ESBp, as this allows you to easily invoke functionality as well as providing for superior performance due to fewer SOAP hops.

As Rich Seeley points out in this article, the current trend is for people to pile more and more into ESB Suites. Many such suites have grown to include even BPM capabilities. It isn’t clear that buying BPM technology as part of an ESB is a good idea. ESB Suites currently have the best enabling technology for service composition and orchestration, but the best BPM offerings are still the standalone BPM products.

Rich’s article suggests that people might start using the term “fabric” to describe larger ESB Suites which include BPM. Only Webmethods and the Burton Group have begun to do. Expect this to catch on only after Gartner and Forrester change their language.

A number of people have predicted the impending death of ESBs. These predictions don’t make sense to me, given the fact that the world isn’t 100% WS-I compliant SOAP. Frankly, we wouldn’t want the world to be all-SOAPed up because of the complexity and performance issues that would imply. There are quite a few ESB products on the market today because there is a need for such products, and there will continue to be a need for such products for the foreseeable future.

• Design for Performance Applies to SOA
• TIBCO ActiveMatrix Press Round-Up
• TIBCO ActiveMatrix: One Container to Rule Them All
• Pay Your Managers and Architects for Re-use
• Who Pays for Reused Services?

In traditional application development, architects could get away with ignoring performance concerns when the application in question had very minor load and latency requirements. In the world of SOA this isn’t an option. The service you write today for a low load application will be re-used tomorrow in a high load environment.

In many cases you will discover that there’s a tradeoff between strict architectural elegance and adherence to standards on one side, and performance on the other side. Tradeoffs of this sort will exist at the enterprise architecture level, where you need to consider the highest load scenario your enterprise is likely to encounter. In many cases you will need to have two ways of doing things, the right way and the fast way.

At the service level, you’ll face the same issue, and you should consider how each given service is likely to be used within an appropriate time horizon. Choosing that time horizon is important, as “forever” planning is dangerous and wasteful.

David’s post raised many excellent points, but I’d like to call out two of them and offer specific advice from my experience:

Second, many services are built on top of more traditional legacy APIs, and as such the translations between legacy APIs to expose them as services may cause performance problems.

Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services.

Do not make everything a service. Things that are likely to be re-used should be services, everything else should simply be leveraged as efficiently as possible. For example, if your organization has many applications that need to check a customer’s credit score you should build a service that does exactly that. Let’s say that getting the credit score requires querying a database, checking a mainframe system, making a SOAP call against a partner, and then executing SAS operation. Do not wrap each and every one of those operations in SOAP and then build a BPEL orchestration around those SOAP calls. Simply build a credit score service that natively leverages those other systems and expose your credit score service over SOAP for applications to re-use.

The above applies in all cases, as this is both the fast way and the right way to build composite services that make specific use of existing assets.

• Who Pays for Reused Services?
• The Definition of ESB as 2006 Ends
• TIBCO's Matt Quinn Presents Service Virtualization
• Pay Your Managers and Architects for Re-use
• TIBCO ActiveMatrix Press Round-Up

The quickest mentions to appear were the short, high level articles that provided bit more depth and color than the press releases. These articles included Martin Veitch’s piece in IT Week, Paul Krill’s write-up in InfoWorld, and Antone Gonsalves’ article in InformationWeek. Antone’s article contains a quote by ZapThink that questions the usefulness of SOA related middleware in general. Antone and TIBCO touched base after the article was published, resulting in this blog entry questioning the value to end-users of SOA related standards. Antone makes some really good points, both of which deserve further inspection. In this entry, I responded to Antone’s article, explaining why ActiveMatrix is different from the class of middleware that he and ZapThink were referring to.

In India, ActiveMatrix was mentioned in CIO India and SDA India. These mentions were mostly in the context of some work TIBCO is doing with major Indian systems integration firms, including TCS. There were actually quite a few mentions of ActiveMatrix in publications outside the US, but I won’t mentioned anything that isn’t in English due to a limitation of the poster (I only understand English).

Early the week after launch, an article in Reg Developer took much closer look at ActiveMatrix and what it means to SOA developers. David Norfolk did a really great job explaining what makes ActiveMatrix new, valuable, and different. If you only follow two links, check out the Reg Developer piece and the Computer World article covered below.

That same week, there was a bit of buzz in the blogosphere around service virtualization. Computer World kicked things off with a great article discussing what Delta is doing with TIBCO’s ActiveMatrix product — Delta is an early adopter of ActiveMatrix, using it as the heart of Delta Nervous System 2. Joe McKendrick, on the SOA in Action blog, made the connection between the concepts Delta was talking about and some of the scaling related concepts that Todd Biske had just blogged about. Over at ZDNet, Joe summed up the talk about service virtualization in his blog post.

Joe’s post quoted a representative from IBM’s grid group who said that virtualization had nothing to do with SOA. On that same day another IBM rep gave a webinar entitled, “Virtualize Application Server Resources to Handle Spikes in Workload Demands.” The webinar expounded on the need for virtualization technologies in an SOA world. IBM even used the term “service virtualization”, but IBM was referring to dynamic addition of servers to an application server cluster based on load. TIBCO’s technology allows you to scale at the service level based on load on that service. Further, The ActiveMatrix technology doesn’t limit you to Java, while IBM’s approach certainly appears to.

Previous to my current role, I was the product manager for TIBCO’s BusinessWorks product. It was nice to see Andrew Binstock award BusinessWorks the highest score InfoWorld has given an ESB in his recent review. There’s a brief mention of ActiveMatrix at the end of the article, but the focus is on what makes BusinessWorks the best ESB available on the market.

A more general post that’s certainly related is Eric Roch’s article entitled, “IBM and TIBCO Dominate SOA Software.”

All in all, quite an exciting two weeks.

• TIBCO ActiveMatrix: One Container to Rule Them All
• People are Talking about Service Virtualization
• TIBCO's Matt Quinn Presents Service Virtualization
• TIBCO Presents ActiveMatrix at Gartner Summit Event
• The Definition of ESB as 2006 Ends

Todd Biske posted an article on his blog that eloquently explains the need to scale services differently from web applications — the load characteristics are not the same. Todd refers to BEA WebLogic Server Virtual Edition as a tool that can help quickly bring up extra instances of services hosted in a traditional application server to meet load spikes, but ActiveMatrix Service Grid is an even better option. Last week TIBCO’s Matt Quinn talked about service virtualization at a Gartner event and specifically addressed the value in scaling services at the service level, rather than scaling an entire application server instance. ActiveMatrix Service Grid is the only product on the market today that allows you to do that.

Todd finishes his article by comparing SOA to a “virtual” or “distributed” mainframe. The analogy is interesting, because service virtualization eliminates quite a bit of the complexity that comes from smearing applications out across services, containers, languages, and geographies. On a mainframe you could invoke any functionality by making a function or procedure call. With ActiveMatrix you have ability to do that once again, even if the service you’re invoking is on the other side of the world, running on a different operating system, written in a different programming language.

On a mainframe you can control how much processing power goes to each component without having to deploy extra instances of those components on other machines; this gives you the advantage of co-location even while scaling the power given to that component. ActiveMatrix allows you to deploy many instances of a highly loaded service to scale that service, but you can deploy some of those instances co-located with the other services it needs to communicate with the most. In this way you get the in-proc collocation while still getting the scaling flexibility.

Of course, mainframes aren’t the desired end state. There are plenty of good reasons we moved away from mainframes, but if we can get back some of what we lost by making that move, all the better. Everyone wants to have their cake and eat it too.

Scaling aside, the abstraction that you get from virtualization appears to be the main reason Delta chose ActiveMatrix. Joe McKendrick mentions this in his SOA in Action blog. Joe also refers to Todd’s article but doesn’t specifically mention that you can solve both the scaling and abstraction problems with service virtualization.

• TIBCO ActiveMatrix Press Round-Up
• TIBCO ActiveMatrix: One Container to Rule Them All
• TIBCO's Matt Quinn Presents Service Virtualization
• TIBCO Presents ActiveMatrix at Gartner Summit Event
• Pay Your Managers and Architects for Re-use

Functionality designed to reduce complexity of communication, location and control as service networks increase in size.

Service Virtualization, a key feature of TIBCO ActiveMatrix Service Grid, is a technology meant to help companies deal with the complexity that comes with doing large-scale heterogeneous SOA. Period. Matt spent some time at the beginning introducing some of the problems companies with large service networks are beginning to face, including communications management and service scaling challenges. Matt then talked about how TIBCO’s approach to Service Virtualization helps to solve these problems.

So, what is service virtualization? If you deploy services using ActiveMatrix Service Grid (AMSG) then those services can be invoked by other AMSG services via a single line of code. That line of code doesn’t need to change, regardless of where the service is, what language it’s written in, and how it is load balanced. Further, any or all of those details can be changed between one invocation and the next without downtime or a loss of service. Once a service is “on the Service Virtualization Platform (SVP)” or “on the grid” (which rolls off the tongue easier?) it can be discovered by other grid services via the Asset Manager or by non-grid services via a UDDI registry. Either way, the invoking service doesn’t need or have any knowledge of where the service is or how it is implemented.

This approach even helps with service versioning, a major pain point for early adopters of SOA. A proxy that translates a service call from the old version’s interface to the new version’s interface isn’t a great solution when you need performance. At least not when a proxy means SOAP serialization and de-serialization. Enter AMSG, which allows you put a “version proxy” in front of new services without that proxy performance penalty.

Matt spent some time at the end of his presentation talking about service scaling and dynamic provisioning of services. Looking back, both runtime UDDI and ESB technologies promised us the ability to truly decouple service invocations from their endpoints. Despite the hype, both failed to deliver on this promise to the point where they could enable dynamic service provisioning.

With respect to service scaling, the key difference between using AMSG and using an app-server based technology is the fact that your systems administrators — independent of the developers — can choose how best to deploy your services and can change that deployment topology dynamically. For example, if two services are generating the bulk of the load on your application you can deploy extra instances of those two services without deploying duplicate instances of all the other services that make up the application. Further, you can do all this without regard for what language those services are written in. You scale all services using the same mechanisms.

There has been talk about dynamically provisioned services for years now. The problem is that even ESBs bind the service invocation too tightly to the service implementation. Reality never lived up to the hype. Service virtualization finally delivers the goods. Deploying extra instances of a service deployed on the ActveMatrix Service Grid (the SVP, if you will) can be done easily via JMX invocations. As soon as that new service instance is up and running the grid discovers it and starts to share load. How do you know when to deploy those extra instances? Load information is also available in real time as events on the grid, and those events can be monitored with CEP software that can take action when it sees the potential for SLA violations.

So, Service Virtualization helps mitigate the complexity that comes from wholesale adoption of services. It does this by truly decoupling the service invocation from the service implementation regardless of language and without the performance implications of a proxy-based (as used in an ESB) approach. The decoupling is so complete that it put deployment decisions in the hands of systems engineers and enables dynamic service provisioning. Further, AMSG even decouples deployment, management, and monitoring from the development language used which allows for scaling to be done using a single methodology. The feedback from Gartner attendees was very positive — there is a definite need for this technology out there.

(Disclaimer: I am employed by TIBCO Software, Inc. , the company referred to in this posting. Further, this article was written and published without the approval or explicit knowledge of TIBCO Software, Inc. )

• TIBCO ActiveMatrix Press Round-Up
• People are Talking about Service Virtualization
• TIBCO Presents ActiveMatrix at Gartner Summit Event
• TIBCO ActiveMatrix: One Container to Rule Them All
• Design for Performance Applies to SOA

I’m in Orlando this week at the Gartner Application Integration and Web Services Summit as part of TIBCO Software’s launch of TIBCO ActiveMatrix. Our booth has been mobbed with people asking questions about ActiveMatrix and Service Virtualization. Response to this new technology has been very positive, though there has been some confusion. Explaining what ActiveMatrix does in 90 seconds isn’t easy, but we (in the booth) have all gotten better at it in the course of the last day.

Most of the initial questions have been about ActiveMatrix, but TIBCO’s award winning General Interface product has also generated a lot of excitement. The RIA (rich Internet applications) space is hot right now, and UI level products definitely demo better than middleware products. The picture at the bottom of this post shows the size of the crowd around the product manager for General Interface — that was typical during show floor hours yesterday.

Who’s talking about ActiveMatrix so far? InfoWorld was first out of the gate with a short article yesterday.

Antone Gonsalves published article in InformationWeek today. His article focuses on the fact that ActiveMatrix Service Grid removed the need to write transport code to interconnect services. Antone is right, Service Virtualization eliminates the need to write transport code and therefore allows you to go back to focusing on writing your application. The parts of your application simply work together as one applications. At first glance, at a high level, this smells like an ESB. ActiveMatrix Service Grid is not an ESB. Note this section of the article where Anotone quotes ZapThink:

“The challenge Tibco will face is that a middleware approach to SOA will fundamentally be challenged by the problem that has always plagued middleware approaches to dealing with heterogeneity: over time, companies implement multiple different containers, middleware approaches, and other technology systems for dealing with change,” Schmelzer said. As a result, companies could end up deploying middleware for their middleware, which could reintroduce more complexity.

It sounds like ZapThink is talking about the proliferation of ESB technologies in large companies. I disagree with the quote, but I disagree even more with the implication that ActiveMatrix is an ESB — ActiveMatrix Service Grid is not an ESB. ActiveMatrix Service Grid is a new container (or grid of containers) that allows heterogeneous services to live together and communicate seamlessly. If companies adopt multiple such technologies they will still be in a much better situation than they are today. Yes, they’ll need to connect the different “grids” together, but that isn’t so hard because AM Service Grid is built to be easy to connect to other systems. Other such platforms, when they appear, will likely also be easy to interconnect.

Better still, ActiveMatrix is built on standards. One of those standards, JBI, specifically addresses the issue of interoperability. As long as other vendors comply with the JBI standard then we should be able to interconnect multiple such “grids”.

As far as the issue of multiple ESBs in large enterprises is concerned, I agree with Gartner. Several key analysts with Gartner have come out recommending use of an “enterprise” level ESB as the master “bus” in your enterprise architecture (for more detail, consult your Gartner contact). Connecting local ESBs from different vendors to that main, enterprise ESB is going to be much easier than connecting things like ERP systems and mainframe systems to an ESB in the first place.

(Disclaimer: As indicated at the beginning of this article, I am employed by TIBCO Software, Inc. , the company that just released this product. Further, this article was written and published without the approval or explicit knowledge of TIBCO Software, Inc. )

• TIBCO ActiveMatrix: One Container to Rule Them All
• TIBCO ActiveMatrix Press Round-Up
• People are Talking about Service Virtualization
• TIBCO's Matt Quinn Presents Service Virtualization

Forget the marketing terms and high level messages — what do the products that TIBCO released today really do?

TIBCO ActiveMatrix Registry is a UDDI registry product powered by Systinet’s award-winning technology. The real value in TIBCO’s registry product comes from integration with other TIBCO products. If you don’t know what a registry is, READ THIS.

TIBCO ActiveMatrix Policy Manager allows you to rapidly deploy security, logging, and routing logic in front of SOAP-based services without modifying those services’ actual code. The creation and management of those “policies” is done graphically, further increasing how rapidly one can create or modify such policies. TIBCO’s offering doesn’t offer any new policy types, but instead derives its advantage from incredibly tight integration with the core technology that powers the third product launched today: the TIBCO ActiveMatrix Service Grid.

What is TIBCO ActiveMatrix Service Grid, other than a mouthful? TIBCO is calling it a “Service Virtualization Platform”, but this product does more than those words imply. In brief, ActiveMatrix Service Grid:

• allows you to deploy services written in myriad languages (.Net and Java today) to one container (a node)
• enables deployment of those services using the same mechanisms regardless of language
• allows you to write only the code that does something, letting the container manage communications with other services (regardless of the node the service is deployed to)
• makes it possible for services to communicate in process if deployed to the same node
• does all the things application servers do for Java, but does those things for all supported languages in a standardized way (including resource pooling, transaction management, and monitoring of deployed services)
• allows all communication related details to be changed ad-hoc (late binding of transports, etc)
• integrates policy management deep within the container so you don’t need to think about during development of your services
• links all nodes into a grid, handling all communications between nodes behind the scenes

That’s a lot to think about. Let’s take on a concrete example: you’re building an new application. A couple of years ago, you might have built that application as a bunch of Java code and deployed it to JBoss. Today you’re supposed to break the application down into re-usable services and then “compose” or “orchestrate” those services into the application you would have just built before. Enter AM Service Grid.

You break your application down into four pieces, or services. You decide to build one of those services in .Net and the other three in Java. You deploy all four the same way, using AM Service Grid. Your application can now run as one OS level process with all the services communicating in-process even through one of those services is .Net. You have an XA level transaction that spans all four services and you didn’t need to do anything fancy to make that work. Database connections are shared across all four services. When your .Net service invoked one of the Java services it did so with a single line of code, as if it were simply invoking a function.

Four months have gone by. Another department in your company wants to re-use your .Net service as part of a new application they are building, but they don’t want to host their application on your server. No problem here — they still invoke your service with one line of code, but now that call flows from their node to your node, and the response comes right back. Time to put their new application into production. Maybe the sysadmins decide that this new application should be deployed to the same node as your application. No problem, no code needs to be changed, and now the communication is in-process again.

Two years later your company’s compliance officer tells you that all the social security numbers flowing between the application services must be encrypted and a log must be created with a dump of all updates to a certain list of employee records. Still not a problem. You purchase the ActiveMatrix Policy Manager, create a policy that does exactly what you’ve just been asked to do — but graphically, without writing code — run through a quick test cycle in your QA lab, and then deploy this policy to your applications without changing a single line of your service code or redeploying your services.

Even cooler: the list of languages TIBCO plans to support includes scripting languages like Ruby and Python. Why? Because sometimes scripting languages really are the right choice. After all, most of TIBCO’s customers are large IT shops building business applications and not building software packages.

Sometimes you don’t even want to write your application in a scripting language because you’d rather graphically mash-up a few services to create a high level business service. Again, no problem. The technology at the core of the ActiveMatrix Service Grid is being added to all of TIBCO’s existing software so those other products can run on nodes and make their resources available as services on the grid. This also means you will be able to easily orchestrate ActiveMatrix grid services using TIBCO’s award-winning BusinessWorks product. You’ll even be able to use BusinessWorks to easily expose “legacy” systems as grid services using this mechanism.

There’s more, of course. You get all the stuff you’d expect from a company like TIBCO: fault tolerance and load distribution features, standards compliance (JBI and SCA are two big ones), message translation, built in management and monitoring, and all the rest.

Have your cake and eat it too. TIBCO’s ActiveMatrix products allow your to build applications as re-usable services without losing the ability to rapidly create applications that deliver real value today. ActiveMatrix does this with some truly new technology. Is it a Service Virtualization Platform? A Distributed SOA Container? A Grid of SOA Servers? That’s the problem with something truly new; no matter what you call it, no one knows what you’re talking about.

(Disclaimer: As indicated at the beginning of this article, I am employed by TIBCO Software, Inc. , the company that just released this product. Further, this article was written and published without the approval or explicit knowledge of TIBCO Software, Inc. )

• TIBCO ActiveMatrix Press Round-Up
• People are Talking about Service Virtualization
• TIBCO Presents ActiveMatrix at Gartner Summit Event
• TIBCO's Matt Quinn Presents Service Virtualization
• The Definition of ESB as 2006 Ends