the infrastructure: it takes Web services, puts a series of patterns on them, uses standard interfaces for using server state management, lifetime management, monitoring, and discovery.
What I think you're going to see over the next year is a huge thrust in the community of us included in Globus to start now fleshing out what we call the set of common services. We will use that OGSI base to start filling in standard interfaces for talking about data access and resource management, logging monitoring services, discovery services, and things like that. For really widespread adoption, I think that sort of work is needed. We're working our way up to the point where we can start just deploying Grid components and tying them together.
You're going to see in a small number of months, delivery of the base capability -- from a variety of vendors -- of OGSI. We've been shipping the technology freely for almost a year already. So that gives a very strong basis for doing either experimentation, or if the nature of the application you're trying to build is much more customized, where having all this stock componentry available isn't going to matter as much, great, go for it. You can go with the tools that are there now.
dW: Now on the other side, is Grid development going to start driving J2EE standards?
Tuecke: It's perhaps a little too early to know, but I think it's quite likely that that will happen in some areas.
Let me back up. What does it mean to ship a J2EE-based Grid environment, something that can deliver OGSI-compliant services? It means that you provide a server programming environment that makes it very easy for service writers to implement services that conform to the set of standards that are OGSI. In other words, you're defining containers. You're starting to define standard containers that handle a lot of the lifetime issues -- all of the things that OGSI handles: the lifetime management, the monitoring, all that sort of stuff. So if you look at what we're shipping with Globus as our implementation of OGSI, what we've done is defined a set of containers in Java, in J2EE, that make it very easy to write services. If you follow the J2EE mantra of standardizing the Java interfaces and having multiple implementations of that by multiple vendors, that's exactly what we think needs to happen on the Grid side.
Just as with these interfaces for programming a Grid service; today they're not standard. They're something that Globus, with some help from a few friends, puts together. Over the next year or so, we're going to have to start taking that out of the Globus universe and moving those into Java interface standards, which really pushes us into the JCP process and starts to drive some of the container models.
dW: It's interesting that you have the open source licensing approach, but some people seem to feel that the whole Grid architecture is being dictated from above, which is somewhat anathema to the open source approach.
Tuecke: I know people have that criticism of us, and there's worry that Globus/IBM are driving this path. Maybe the problem is that the open source community really isn't one community. It's a whole bunch of them. So it may be better to speak of particular open source projects as communities. There are certainly a lot of people in the broader open source community who will always chafe at conforming to anybody's anything, and will start again from scratch. With Globus, we're clearly one of the bigger open source communities in place, certainly in the Grid space, and it's critical that we have things like OGSI there as a basis that we can just assume to keep moving up.
One of the problems that we've seen over the last number of years, and one of the things that really motivated us toward OGSI as a basis for all these higher level services is having enough infrastructure in place that we don't have to keep re-inventing from scratch: building up from the IP layer for example, or redoing the entire monitoring architecture for your entire project.
<< 上一页 [31] [32] [33] [34] [35] 下一页