HP, IBM, Intel and Microsoft recently announced their plans to jointly "develop a common set of specifications for resources, events, and management that can be broadly supported across multiple platforms." This month, the Globus Consortium Journal had the opportunity to speak with Matt Haynos - program director for Grid computing strategy and technology at IBM - to learn about the significance of this announcement for the grid community, and to check in on some related issues.

GCJ: Ian Foster expressed his view that this joint standards push by IBM, HP, Intel and Microsoft is good for the grid community. Any additional thoughts that you'd like to point out here about how IBM sees the continued evolution of web services standards, and what it means for the greater industry?

Haynos: We definitely agree with Ian's perspective. One of the main reasons why we did this as a company was so our customers would have a consistent and converged set of specifications for information management, eventing, notification, and Web services management.

IBM is working to align both WSRF and the WS-Notification specifications accordingly with the new specifications. So we'll work with the standards bodies to re-factor WSRF to clearly delineate any extensions beyond WS-Resource Transfer. And we expect to work in standards organizations to better integrate the WS-Notification set of specifications with both the WS-Resource Transfer and the WS-Event Notification specifications.

That doesn't mean that WSRF or WS-Notification are going away. They'll continue on their roadmap. So we're going to do a lot of work in WSRF and Notification, to make sure that they're factored appropriately with the new specifications.

Another thing I would add is that a lot of the differences between WSDM and WS-management were attributable to the differences in the lower-layer information management specifications, like WS-Transfer and WSRF and WS-Eventing and Notification. So the reconciliation of those makes it easier and facilitates being able to work towards a common management specification.

And it's really what we announced with Microsoft. It's a roadmap. Again, in WSDM and WS management, we'll continue to proceed on their roadmap, we'll rectify some of the differences in the underlying lower layer specifications, and then move forward towards a converged management specification. And we hope that the basic specifications, WS-Transfer and Resource Transfer and the metadata exchange will make their way to the open standards bodies fairly quickly. We want them to move pretty quickly so that organizations like the GGF and DMTF can begin to base their work on them sooner rather than later.

GCJ: One of the challenges with grid applications is making them consumable across a range of platforms and environments. This is one of the key capabilities of SOA ... so do you see any synergies between grids and SOA, and how do you see the trend playing out?

Haynos: Yes, there's a tremendous amount of synergy between SOA and grid, as I discussed recently with GRIDtoday.

The pace of business continues to quicken, and the companies that are able to deliver and get to market quickly are the companies that are winning. The cover story on BusinessWeek a month or so ago ("Is Your Company Fast Enough?") declared that speed to market is now the ultimate competitive weapon. And they gave an interesting example of Virgin. We think of Virgin as planes, megastores, and music. But they're in so many other businesses that they've launched, from health clubs to credit cards. To do that, you have to be incredibly efficient with your business processes, and that's where SOA is driving the innovation today.

How does this get back to grid? In today's world IT infrastructures are fairly tightly coupled, and they're function-oriented. So the architectural thought behind SOA is being able to break down the tight coupling, introduce loose coupling between paths, understand your business processes and understand your workloads. Dynamic service management and service lifecycle management is something that's very inherent in grids and that's where we think the synergy between services-oriented architectures and grid lie. SOA is really a business thought and an application thought. Decomposing your processes into their constituent parts, understanding your processes, and managing them more effectively. grid allows you to run such an infrastructure in a very dynamic manner. There's really no other way to do it.

And SOA is here to stay, because people are realizing that the loose coupling, the separation enables flexibility. To support this, we're seeing the virtualization of communications protocols, and we're seeing workload and information virtualization that eliminates the coupling between the different applications, users, data and workload from the underlying infrastructure.

GCJ: How do systems / resource management requirements look different in SOA environments? Is grid well-suited to handle those new resource management requirements?

Haynos: So you look at that and you look at the IT infrastructure and say, OK, what do I need now? And that's where we see very strong synergies between grid and virtualization. Services in SOA environments are dynamic, they move around, they need to be started up and stopped on-demand - these requirements are met perfectly by grid environments. You can't manage all of the requirements for dynamic operations without intelligent middleware, and that's where grid comes in.

This movement towards SOA does facilitate a grid infrastructure, because you are talking about decomposition of applications into services that can more easily be deployed and provisioned on the fly. So this may ultimately make applications that aren't purpose-built as grid enabled programs easier to put on the Grid.

At IBM, our strategy for systems management really revolves around IT Service Management (ITSM) and the associated IT Infrastructure Library (ITIL) processes. We focus on three layers. At the lowest layer, it's resource manageability, or IT operations management. And then resource management at the next higher layer, which is based on a service management platform. And then at the top layer, IT process management and automation. So one of the things that our Tivoli business unit concentrates a lot on is ITIL and the processes, and then at the lowest layer are things like instrumentation based on WSDM.

The interesting thing here is that because the grid community has adopted a lot of the same protocols and specifications that systems management suites, like Tivoli, are basing their manageability and instrumentation on, therefore grid is very well-suited to handle the new specifications. And so it's aligned pretty nicely.

GCJ: IBM has been a big proponent of the LAMP stack, and the scripting languages (Perl, Python, PHP). We're hearing that the LAMP application infrastructure is often the preferred platform for writing "mash-up" applications. Is that how you're seeing it? And what are your thoughts about what the mash-up application development trend means for grid?

Haynos: The reason why the LAMP stack and PHP in particular have really gained incredible traction is because they're very lightweight. When you look at mash-up application development, it requires choreographing, creating workloads, and utilizing existing services in interesting ways.

So when will the mash-up concept come into enterprise? Some people say 'oh no, it's not controlled enough, too tough to manage well.' But as you're able to break up your applications, really what's important is understanding the granularity of both services and composite applications and business processes. It's not hard for business processes, but how do you know you have the right granularity in your services?

As companies are moving towards SOA and they're more comfortable, you're going to start to see mash-up application development. We're at the very early stages, but it's sort of in the outside communities where developers are taking these well-exposed services and developing the innovative new composite applications. Once you have all of these services created, you can much more easily write applications that utilize these services and do interesting things and choreograph these services in interesting ways. So I'm a big believer that as SOA continues to mature to a services-based view, running on a virtualized infrastructure - we're going to see a lot more mainstream enterprise mash-ups being developed.

Now, that raises a lot of issues. How are these apps controlled, how are they deployed, how do the service providers plan for capacity? And you look at Amazon or Google Maps or eBay, one of the questions that they have to ask themselves is how do I know how many users are going to use my services? And how do I plan appropriately for capacity? And even if I have a virtualized infrastructure, it could be overwhelmed very quickly. So there are a number of new considerations.

GCJ: It seems like one of the criticisms of grid so far, for enterprise grid, is that the killer app has not arrived, etc. What exactly is the application that you can only run on a grid in enterprise that makes it so attractive?

Haynos: The idea of a "killer app" for grid is a bit of a red herring. Infrastructure is never very glorious. What's happening is that grid is becoming ubiquitous in the enterprise architecture. It's part of the natural evolution for distributed computing, from an infrastructure perspective. It's virtualization, it's the loose coupling that's facilitated by Web services. We're seeing it in ESB and we see it in grid from an infrastructure standpoint through the separation of workload and information from the underlying infrastructure.

I'm not a big believer in associating a killer app - because we're talking infrastructure. But you want killer grid apps - look at Google, look at Amazon. Those guys would say that the only way they're running is based on a distributed grid infrastructure. Those companies are facilitating a lot of cool things in the world today. So I guess you could call them "killer grid apps," if you wanted to.

close window