SOA Infrastructure Blog

The secret is out: We acquired Mindreef

Well, my intrepid investigative reporter friend, Jeff Schneider, broke the news.  We've acquired Mindreef.  You can never time these things perfectly, and we didn't want to have news of Mindreef get lost in all the noise around some of the other acquisition stories.  So, we had been planning to announce it a bit later.  Of course Jeff, never one to let go of a breaking story, couldn't hold off :-)

On the Actional side, we first started partnering with Mindreef back in 2003 or so (long before Actional was acquired by Progress).  One of the first things that attracted us to work with Mindreef was the way their products make working with XML and web services easy.  As Mindreef expanded their product line they added the ability for a team of SOA stakeholders to collaborate, working together to ensuring that services are delivered successfully - something that still separates Mindreef from any other SOA quality or validation product.

In the SOA space, there's often been a clear dividing line between products that focused on design time concerns and those that focused on runtime concerns. But, SOA isn't so clear cut.  When I've built a service that's in production, and you want to design a consumer for that service, is this design time or runtime?  What if I've built a consumer that's in production and you want to change your service, is this design time or runtime? Well, it's both really.  So why then do we have such a divide between design time and runtime SOA governance products?

By bringing together Mindreef and Actional we're doing what's only natural - removing the artificial dividing line between design time and runtime, addressing the complete SOA lifecycle with technologies that are leaders in both.

Are your services dominant or submissive?

A lot of business relationships exist where one side is much more powerful than the other.  Walmart's relationship with their suppliers is a text book example - Walmart is definitely the dominant one: "Here's how you're going to work with us and, if you don't like it, find someone else to sell to."  And, their suppliers definitely do what Walmart wants, no matter how painful: "Thank you sir, may I have another."

What's interesting is that this exact same pattern appears with services. People that build services seem to naturally either take a role of assuming dominance (assuming they are the gorilla) or one of submission (assuming they need to cater to the whims of each of the consumers of their services).  Of course, there's nothing holding back the exact same service provider from going down either one of these paths - in the end it's all a state of mind really.

The important question, though, is whether one is better than the other?

Welcome Iona!

As you've no doubt heard, Progress announced the acquisition of IONA yesterday.

The Actional team has been partnering with IONA since well before this acquisition business started.  It was actually a very good match because a large percentage of IONA's customers run mission critical applications - applications that typically not only have high volume of use, but which are composites of many different platforms and technologies... as most real world applications are.  In many cases, these are applications where revenue depends on the success of the business transactions.  This type of real-world application is something Actional excels at, so the partnership is a great fit and we've generated a significant amount of momentum together.

Of course what made the partnership really work, though, is that both of our teams worked really well together.  The team at IONA have been great to work with all along.  So, let me wish them all a warm welcome. I look forward to working with the IONA team when the acquisition is approved.  'Nuf said!

Never the twain shall meet, eh?

IONA CTO, Eric Newcomer, and I had to laugh when we recalled the panels we've sat on together and (somewhat pedantically) debated the merits of IONA Artix and Progress' Sonic. We shared the religion of distributed systems, alright, but we argued about them like we belonged to different sects. That's because a matter of principle—architectural principle—was at stake. In the highly-distributed SOA environment, what's the preferred approach: smart end-points or smart networks? Like all religious arguments, this one had a lot to do with up-bringing—and the particular tool we were both holding in our hand at the time.

Eric, coming from a CORBA heritage, had a natural affinity for the smart end-point approach, which IONA had successfully commercialized. On the other hand, I saw the problem through the prism of an enterprise messaging background and argued for smart networks—the solution Sonic had chosen to build. The schism, however, proved to be as nonsensical as the RPC vs. MOM religious wars of the early 90's. In our hearts I think we both felt that the argument was a bit contrived. We always knew that both models were valid—like a hammer and a screwdriver they are tools that address different needs. Neither replaces the other and they are rarely interchangeable. When you need the flexibility to put intelligence in the network (and can't or don’t want to change your endpoints), then the smart network approach is great. And, the converse is true too: when the network (or networks, for that matter) is a given, and I'm looking to service-enable a variety of endpoints, then the smart endpoint approach is perfect. The fly in the ointment all along was the decision we baked into our respective architectures at design-time.

Like a tattoo, you had better be sure you liked it—as CTOs, our mission was to defend it at all cost. But that's all changing now that new standards like Spring and OSGi give us the flexibility we need to defer those decisions to deployment time, where they always belonged. And thus a doorway is opened—a doorway to the best of both worlds!

SOA What? Bringing IONA and Progress together means that we can dispense with the pedantic debates and truly offer our customers the best of both approaches. It's a great time to be working in this industry, and fantastic to be joining forces with IONA. But, now what will Eric and I argue over? Well, there’s always emacs vs. vi!

By the way, if you haven't had a chance to hear what Eric Newcomer, CTO of IONA, has to say about the Progress acquisition of IONA,

The Power of the People

As I'm sure everyone is now aware, yesterday we announced that Progress is joining forces with IONA Technologies with a goal of strengthening our position as a leader in independent, standards-based, heterogeneous, distributed SOA infrastructure. The innovative approach to professional open source and strong adherence to standards in the IONA product set really gets a technology geek like me excited about the possibilities that this combination enables. If you are like me, and spend your leisure time digging into OSGi while thinking that the Spring Framework is the best thing to happen to Java since Hibernate (admittedly I try to have a life too), then you too may be salivating over the future possibilities. But I digress…

What I want to talk about is how impressed I am with all of the people that I have encountered at IONA throughout this process. Posts I have read over the course of the day are quick to point out the proximity of our US offices and our mutual 20+ year history in the software industry as similarities, but the alignment goes well beyond geography and highly adopted heritage platforms (the marketing guys have finally driven the word legacy out of my vocabulary ;-)). Rather, we have a remarkably similar way that we think about the problems that we solve for our customers and a passion for the technology and standards that we leverage in our mutual product lines. Technology and strategy discussions I have had with IONA employees (before the acquisition was even contemplated) have been lively, insightful, and very productive. Furthermore, IONA employees have a deep understanding of the requirements around creating mission-critical, high-performance, transactional systems. This pedigree is highly valued in the industry and a core tenet of all of the products that we release at Progress and IONA.

SOA What? Well beyond the product, standards, and open source opportunities that Progress+IONA represents, perhaps the most valuable asset that we are obtaining is the world-class team of technology leaders and innovators. I look forward to working with my new colleagues from IONA and welcome them to Progress.

The past will predict the future

As you have probably read in today's press and blogs, Progress is going to acquire IONA.  This is great news and I welcome my new colleagues from IONA.  But what does this mean to our combined customers?  While I am not going to directly comment on what the Progress and IONA products will look like going forward; I will review some of the past acquisitions to understand the benefits for everyone involved.

If you look at the Actional acquisition, you will see how these products have evolved over the last couple of years to not only stand on their own and compliment other vendors' stacks, but also how they have enhanced products like the Progress ESB.  The same also goes for products from Pantero, now DataXtend SI, where we support full life-cycle of canonical models and the transformations in and out to save our ESB customers many hours of work, but again also provide the same to the application server vendors out there to ensure that we never have to go into XSLT hell again.

As I said earlier I am not going to comment on combining roadmaps, etc., but you can see from the past that not only is Progress Software adding more capability to our SOA infrastructure portfolio by allowing us to help our customers solve larger and more complex problems, but we can equally play as well in combined vendor solutions.

Event-driven SOA vs CEP. What is the difference?

Technology blogs and online communities have been chattering about event-driven SOA and many of our customers have been asking "How does event-driven SOA differ from CEP?" In this podcast, Giles Nelson gives an example of an event-driven style of business, and how today’s SOA infrastructure benefits from an event processing backbone is.

Listen to the entire interview below:

Subscribe to the SOA Infrastructure iTunes channel.

Observations from Management World 2008

Yeah... so I'm a little late posting my observations from Management World 2008, but later is better than never.  My marketing team has been trying to get me to blog about it so instead of waiting, they dragged me into the studio to record a podcast (listen below). 

Overall, it was really a great show.  The Progress Software booth was very busy because we were introducing a new book, Application Integration Using the SID, available on Amazon.com and co-authored by TM Forum's Sr. Technical Program Manager, John Reilly, and John Wilmes, Chief Technical Architect, Communications Sector, Progress Software. I didn't have too many opportunities to attend sessions and visit other exhibitor booths, but based on my many conversations, it is clear that the competition in the telecommunications space is tough and getting tougher! They MUST find ways to reduce costs and operational expenses through system (often legacy) consolidation, reduce the churn of customers by providing "the best" customer service, and sell more services to existing customers. 

Progress® DataXtend™ Semantic Integrator (SI) was really well received because of its use of standards, specifically TM Forum's Shared Information Model (commonly referred to as the SID), and because it makes it possible to create a common understanding of the information flowing between all of their systems - no matter how many different formats that information may be in or how often those formats change. This in turn allows telecommunications companies to get more of their systems to "talk to each other" which lets them introduce new services more quickly, replace existing legacy systems with minimal risk and create a common understanding of their products and customers across all of their application silos. 

One of the sessions that I was able to attend was presented by Thomas Norberg, CIO, Nordisk Mobiltelefon.  He shared his experiences in deploying the SID and DataXtend SI. By relying on industry standards and a common model, his company is now able to be much more reactive to customer demands. 

Listen to my more detailed summary below:

Than a Speeding Bullet—Are You Ready for Event-Driven Business?

Progress Software sponsored webinar will examine the impact of event driven SOA

Hub Vandervoort, CTO of SOA Infrastructure products, will participate in an InfoWorld webinar titled; "Faster than a speeding bullet—are you ready for event-driven business?" on June19th, 2008. During the webinar, Mr. Vandervoort will discuss how event-driven SOA infrastructure can be used to streamline businesses' provisioning and visibility.

When: Thursday, June 19th, 2008 at 2:00 p.m. EDT
Where: To register visit: http://www.infoworld.com/5266

What: In the "Faster than a speeding bullet – are you ready for event-driven business?" webinar hosted by InfoWorld, Hub Vandervoort, CTO of SOA Infrastructure products, Progress Software, shares strategies businesses can implement today that will keep systems ahead of the increased business velocity. He will discuss how event-driven SOA infrastructure—from the enterprise service bus (ESB) and real-time data services to complex event processing (CEP)—can be used to streamline provisioning and visibility.

Why: "Faster than a speeding bullet" doesn't just refer to superheroes anymore; it's the velocity businesses need to compete. Financial trade settlement has accelerated from three days to two hours in just a few years. This trend is repeating itself in almost every industry. The result: current systems can't keep up with the ever-increasing velocity of business processes.

Connected but not Communicating

Modern SOA infrastructure is analogous to our global telecommunications infrastructure. These days, just about everybody (my teenage daughter included) has a cell phone that they can use to connect to someone in Berlin, Bangkok or Beijing. The infrastructure is highly reliable, interoperable, and easy to use. However, unless the individual placing the call can speak German, Thai or Mandarin, they won’t be able to communicate with the person on the other end of the line.

Systems in an SOA have a similar challenge. They may be able to connect using highly reliable and standards-based infrastructure, but that doesn’t mean that they can communicate. They have connectivity interoperability, but they don’t have data interoperability. And without data interoperability, your applications and services are not communicating.

SOA is being widely adopted as a means for getting heterogeneous systems to interact and the appeal is obvious. SOA promises productivity through reuse and the adoption of standards for interfaces between systems such as WSDL, XML, etc. It promises a central point of visibility for governance where all business processes can be managed through a common set of infrastructure components. Perhaps best of all, it promises agility in that systems can be changed at a much lower cost because of the use of standard interfaces.

SOA What? For all the significant benefits cited above, the promise of SOA comes up short because it is focused on connecting systems together but does not address the challenges of data interoperability. For that, one needs to look past the promise of SOA to the practical concern of communicating using a data interoperability layer. Use a common model to facilitate communication and now you're really talking.

Why should you deploy an ESB?

An enterprise service bus (ESB) provides you with interoperability across many distributed, heterogeneous services and systems. Watch the video below and hear Hub Vandervoort tell you more about the power of an ESB and the industry's 1st ESB - Sonic ESB.

A Note On Policy Portability

Today, I write like my colleagues. No humor. No funny title. No family stories. Just boring technology evangelizing.

I apologize.

But, I have something to say, and it can't wait until I think of a funny, but related personal story.

People often ask about policy portability. In particular, something along the lines of:

"Is there a way to create an XML representation of the policies configured/applied to services so that we can store them in the registry and share them with other policy enforcement points?"

Policy would only be truly portable if there were a standard that defined how policy should (could) be written. It would have to define a lot of things that we take for granted, like how to define semantics of policy constructs (defining something as simple as response time can vary greatly from vendor-to-vendor today). That in itself would be difficult, but perhaps not impossible.

The larger challenge becomes the "value added features" that vendors enable in their products that differentiate them from one another. From Progress® Actional's perspective, these value added features include Service Stabilizers, Dimensions, and Message Fields - all aspects of our product that add to the flexibility, scalability, and overall power of the platform. These are powerful features that provide detailed insight into service usage and control in a shared environment.

Realize, that this might sound like I'm trying to defend my product's value-add, but in fact, this is one of the real differentiations - how powerful can a governance solution write policy? How flexible can the policy be? How can it be applied creatively, to make sure everything is managed, even services you don't know exist? (Yeah-  you got that. We can write policy, and have it be inherited by services we don't even know exist. And, the policy automatically kicks in, when appropriate, without having to restart services, app server, or management platform).

I'm not sure I think these things could never be standardized. But, perhaps it might happen. And, we'd be all for it for those of us who work on and with Actional products. But in an emerging market, in many ways, the market is still trying to figure out what works and what doesn't. That's why many of the WS-* standards efforts (including WSDM, which I think in some ways might have indirectly led to policy standardization) have faltered. I think the standards got a bit ahead of the market and actual implementations.

Back to my point. It's very useful to visualize, in a way that scales to the enterprise, performance by customer, business process, or whatever arbitrary business characteristic a business manager wants. It's powerful to see this information without any a priori knowledge of the set of information to view things by (e.g. you don't need to pre-configure the list of customers, we can discover them live, and as the list changes, dynamically adapt and instantly start collecting new customer stats). None of that would be possible if policy were delivered as the lowest common denominator across vendors. Delivered as a standard, we'd all have to agree on how to define these things first... and in my opinion, that's too much to ask of a standards organization at this point in the maturity of SOA Governance.

SOA What? From another point of view, it seems to be a growing need. That is, for a policy written in one place to be stored centrally and then pushed to various (policy) enforcement points.

Of course, that's expressed as a feature, not as a benefit. The benefit is to be able to govern policy better, and have consistent policy deployment across the SOA.

One way to solve this problem is to only deploy solutions that embed Actional agents! Then, you can use our policies everywhere. Policies can be attached to the WSDL and stored in registries using WS-Policy standard (we do this today). Before you discount this as a "sale pitch," take a look at the breadth of platforms supported.

Actional Agents are available for a broad range of platforms, including:

1. BEA
2. Microsoft
3. IBM
4. Oracle
5. Sonic ESB & SonicMQ (Progress Software)
6. Tomcat
7. IBM DataPower
8. TIBCO BusinessWorks
9. JBoss
10. Lombardi Teamworks (see my recent webinar on this topic)
11. Cisco ACE XML Gateway (formerly known as Reactivity)

And, there are platforms that we support that have not yet been announced (and probably some I've overlooked) so ask your account manager for the complete list.

Why have these partners chosen to embed the Actional technology? Simple. We perform and scale orders of magnitude beyond any other solution out there. And, the Stabilizers, Message Fields, and Dimensions mentioned above add an abstraction layer that makes cost of ownership really low through a really flexible policy implementation.

In other words, our Agents can be embedded in places where performance and scalability are critical. Places where other technologies simply couldn't live because of their footprint or intrusiveness. Imagine how the very powerful XML accelerators that embed our technology would behave if each time an XML payload needed to be processed, the management solution had to send the message back to the central management server?

But, I digress into hitting my competitors for poor enterprise scalability. We've just been removing so much of their stuff lately...

The downside of putting Actional everywhere would be the perception of our policies being proprietary and being locked into Actional. Well, I tell you what... any solution you choose, that'll be the case. The advantage to Actional is that if you choose one platform, say BEA, and all of a sudden, they get acquired by another vendor, say Oracle, you can easily migrate to the new platform without having to redo your policies. You can easily plug-replace, or amend, you infrastructure with an instrumented platform, and not have to re-design your policy infrastructure. At that point, you need to decide three things to choose the right policy infrastructure (Actional!):

1. Does the solutions scale to my needs?
2. Is the policy authoring power sufficiently robust?
3. How many partners consistently support the policy infrastructure?

In fact, the argument against us being proprietary is to look at the alternatives (considering that any solution today is really proprietary)... one alternative is to have weak policy authoring (through a lowest common denominator policy language) or, point-to-point vendor integration to work around the lack of standards. Point-to-point integration has the weakness that usually each integration is done differently, and not all features are available everywhere.

I think a single vendor solution that doesn't compromise policy flexibility or power, or solution scalability or performance, while enabling a broad selection of policy enforcement points (and for that matter, policy repositories via WS-Policy) and technologies/protocols, is a desirable, and in fact, preferred alternative.

Implementing SOA during a Recession

By now we all know that service-oriented architecture (SOA) isn’t something you buy out of the box. It’s also a long term initiative that involves planning, implementation and fine-tuning. But when budgets are tight, many companies may slow down or even stop their SOA initiatives. Listen to the podcast, Implementing SOA during a Recession, presented by Dan Foody, VP of Actional products at Progress Software. During this podcast Dan talks about the importance of maintaining your initiatives during an economic downturn by looking for the quick wins and hits that will allow you continually enhance your SOA infrastructure. He talks about business-critical issues such as security and compliance, and SOA governance that can’t be ignored even during a recession.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

What Makes a Good Policy?

Anyone ever see David Letterman's stupid pet tricks? I think we should have a tech show called stupid IT tricks. I recently heard that one CIO's strategy for meeting user requirements was to forbid users to submit feature requests. Software would be installed, and the way it works out of the box is what the users get. His policy of "no more user requirements" ensures a 100% success rate of meeting his IT policy. I applaud his brilliance.

As silly as that sounds, check these two policies out...

• Please don't ride the subway if you have a cold. These signs are posted throughout the NYC subway system.
• Don't drink and drive.

These sound like pretty good policies, right? The former benefits everyone by preventing sick people from getting others sick. The latter, well, it saves lives.

But let's take a closer look... This first policy is totally unenforceable and really doesn't reflect user's realities. Whoever thought of this "marketing campaign" did nothing but waste tax-payer dollars. Most people would love to not come into work when they're sick, but that's just not a reality. If we wanted that policy to work, we'd have to make a realistic alternative for sick people. After all, what's their motivation for following a policy if it's not enforceable, especically when they may not have any direct benefit from following the policy?

On the subject of enforcement, let's look at the second policy. Clearly, this is an enforceable policy. Why then do people continue to drink and drive? There are realistic alternatives to drinking an driving, and would-be drunk drivers benefit directly. A sick person is already sick so not riding the subway doesn't help them, but a drunk who doesn't get behind the wheel is stopped from hurting themselves, or worse, others.

Unfortunately, as Mayor Rudy used to say, "common sense is, unfortunately, not all that common." I think, in part, it's because enforcement is subject to "user interpretation."

But apparently, people are more worried about being embarrassed by having their names/photos published if they are caught drunk driving, than they are about hurting someone, losing their license, or jail time. A new policy started on Memorial Day in Long Island that stated that people arrested with blood alcohol levels over the limit will have their names and photos published on Monday mornings. It's an effective enforcement procedure but has been called "controversial" - probably because it's a government program that works.

SOA What? I commend the person at the MTA who is trying to instill manners on subway riders (though I still think that they should be fired for wasting money/time). But it's a noble cause doomed to fail. And, for those officials on LI willing to risk controversy and continue to publish drunk's names and photos, you set a good example for those of us trying to police our SOA infrastructure.

What can we learn here? Again, it's about the carrot and the stick. Both need to be in place organizationally in order to make policing the SOA practical. You've heard it before, SOA (and SOA Governance) is as much about people and process as it is about technology.

1. Carrot. Enforcement depends upon user behaviors. You can threaten to cut off access to a service if an application doesn't follow policies, but... if that application is mission critical, you probably won't be able to do that. What you'll have to do is adjust your governance policies! It may not be obvious, but there are probably low cost ways to encourage user behaviors without making them political battles. How about posting a list of insecure applications? You may not be able to cut them off, but perhaps users will think twice before depending upon the application. Put the onus back on the developer rather than being the bad guy yourself.
2. Stick. Policies need to be enforceable. And that simply means watching what's happening. Let's compare our SOA to the subway... When we create a list of policies stored in a registry and then test our application against those policies once, when it comes time to place the application into production, it's like making sure we only sell metrocards* to healthy people. Once you have a metrocard (once you're app is in production), you can get sick and ride the subway (you can violate your governance policies), but we have no way to tell because you have no visibility into your run-time environment. If you laughed when you read the policy above, and do this in your SOA, I suggest you rethink your approach to SOA governance.

Gain Better Enterprise Visibility of Your SOA

What if you could gain better visibility of business systems and services across your SOA infrastructure? At Progress Software, we believe that you can achieve the promise of SOA without compromising your architecture or getting locked into a single-vendor approach. Listen as Giles Nelson, Director of Technology at Progress Software, presents his observations on the challenges that you and other enterprises face when trying to identify business requirements, deploy smart solutions that will support these requirements, and how - at the end of the day - you'll be able to monitor and analyze operations so that you can make smart decisions that will improve ROI and reduce risk.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

Learn more about SOA Infrastructure products from Progress...

• Enterprise Service Bus - Sonic ESB
• SOA Management - Actional
• Complex Event Processing - Apama
• Data Interoperability - DataXtend
• Mainframe Integration - Shadow