Reporter: Mark Baker
Translator: lhztop@ytht.org, Ancry@ytht.org
Any reprint must be consent to the translator, and mark the election !!!
Ian Foster is a senior scientist in Argonne, distributed system laboratory. At the same time, he is also Professor Arthur Holly Compton, Chicago, ARTHUR HOLLY Compton.
He is known for your knowledge may be with Carl Kesselman, Steve Tuecke as a sponsor of Globus Toolkit. This software is open source, providing a unified framework for distributed computing in the wide area, consisting of several components: security, resource management, communication, data management, etc. In the "THE GIRD (Grid)" book published in 1999, he and Kesslman mentioned several major elements that constitute the grid. Since then, Globus Toolkit has become a pioneer in the realization of many grid software base parts, and the grid truly reaches a key component of usability.
From the first edition, Globus Toolkit has experienced several big changes, but the largest change is to stery the service-based implementation. In July 2003, Globus Toolkit 3.0 is released, it achieves OGSI standards (translator Note: OGSI is a standard for grid service). But the messenger is surprising that at the GlobusWorld meeting on January 20, 2004, Foster and his colleagues raised the OGSI's concept to the Network Service Resource Framework (WSRF, Web Service Resource Framework).
After Foster proposed WSRF, the online editing of the IEEE distributed system contacted him to explore the recent changes and their impact on the grid world.
Question 1: OGSI-based grid services have a big jump with the previous grid construction (Grid Architecture). Built the grid on the WSRF and is another transformation. The current grid service has a trend with the web service, in addition to this, what person, such a big influence, so as to use WSRF?
The WSRF framework actually resolves the concept of OGSI to better meet the Web Services standard. Why do you need a standard and achievement of grid computing? According to FOSTER, although Web Services manufacturers recognize the importance of OGSI thinking, they don't intend to adopt the definition of OGSI 1.0 release. This will threaten the extensive support for grid infrastructure for OGSI norms. Support for widespread infrastructure is the main purpose of initially developing OGSI. Therefore, in this case, it is necessary to renew the OGSI. The Globus Alliance does not want to redesign OGSI (they are more happy to develop high-level services, rather than entanglement in infrastructure), so Globus conclude that doing some re-decomposition of OGSI if it can promote grid service and web services, then This is correct, worthwhile and meaningful. Thus, Globus and Web Service Architects formed a group to study this issue, and the results are WSRF.
Although the evolution of OGSI to WSRF is mainly in the syntax, it also represents some beneficial progress. Split the function of OGSI into six independent specifications, simplifying the use of others, and using WS-AdRessing is a progress, weakened to excessive use of XML Schema and WSDL2.0 will be more convenient to use the current tool . But these benefits are enough to offset the damage caused by the amendments to the grid infrastructure specification? It is very controversial in the perspective of pure technology. But in fact, we have gained a Web service community strong support for grid infrastructure, which is a big achievement for the grid community - which means we will see it in the core Web service product. WSRF support, this is a wonderful message for the grid community. But we should not overemploy this change in this change: Although there are some need to work from OGSI to WSRF, this workload is not very big, and we are trying to alleviate this transition. Question 2: Obviously, WSRF's planning and design work has begun before a while, many people in the grid community are very concerned about why this progress is kept secret, and how many participants have arrived until January 2004 in GlobusWorld Announced WSRF, this plan has not been revealed. Why is it secret to? These processes are public, how is it like the practice of some business commits?
The WSRF's research work begins in the end of 2003, after receiving the feedback from the network service, the feedback from OGSI. Fortunately, we successfully received the participation of advanced web service architects in this work. Unfortunately, they want to do with our cooperation in the case of closed. Fortunately, through a lot of hard work, we quickly ended this process and quickly proposed this norm for your comments.
I don't say this process is ideal. However, we should evaluate it from the results of this process. After a few months of closed door discussions, we put forward a series of regulations for everyone to discuss. These specifications have been accepted by OGSI's authors, and many network services are also accepted. I can imagine a better process, I can imagine a worse result.
Question 3: Developing at least a lot of ways to make the grid service more appetite in the Web Services community. The result of this is that the concept of grid service seems to be completely disappeared. Is this right? So why we need grid services two years ago, and now don't need it?
No, the concept of grid service has not disappeared. OGSI and WSRF are committed to resolving the essence - that is, from a grid point of view, the key function of the Web service is to create, address, check, discover, and manage stateful resources. In OGSI, these stateful resources are referred to as grid services; in WSRF, they are called WS-Resources. A grid service has an identity ID, service data, life-life management mechanism; a WS-Resource has a name, resource property, and life-management mechanism. The term has changed, but the need, the concept and mechanism have not changed. OGSI and WSRF have defined these mechanisms required for these indeed important specifications, which are used to define the build upper-level OGSA. OGSA work will continue, and these changes have little to OGSA.
Question 4: When OGSI first proposed, its basic characteristics have been quite secretly developed, and the Globus project has taken a long time along the OGSI. Most people in the grid world forgive you, invested a lot of energy to understand OGSI, revised their project plans. Will they still do this again?
You start to say: OGSI is not in the secret. From 2000, we found that more and more people are willing to use web services as a grid implementation technology. In response to this, the Globus Alliance and IBM formed a group of OGSI norms in February 2002. Subsequently, after a year and a half of the working group of GGF, the ultimate OGSI specification was formed in June 2003. I think this is an excellent example. The Globus Alliance has seen everyone new request, and pre-developed and develops open standards. The initial motivation of WSRF is also the same goal and is carried out along the same process. The success of the grid needs to be created, addressable, inspected, discovered, and manages stateful resources with a standardized infrastructure that has been widely adopted. OGSI defines the mechanism required. WSRF is slightly adapted to make it easy in the application in the commercial Web service tool. It is a bump on the forward road, but it is not very serious, and the benefits of getting it are huge.
Question 5: Many projects have been closer to OGSI for a while, some already in developing grid services, is these jobs are waste? In addition, I adhere to the web service. I hope that once a widely deployed OGSI base piece is in place, it is no painful, very happy. It seems that the latter waits for WSRF to be more sensible, but for many projects, their life is too short. And there are still many insistence with GT2, and now I can use GT4 directly, but don't pay attention to GT3. Some people are considering whether to use Globus, and use Globus alternatives. How can you persuade everyone, compared with the pain experienced by the steering, will long-term interests? Are we also encountered a fierce reaction that hinders grid development? Like the winter of AI, is it the winter of the grid?
E-Science and E-Business remain continuously:, for example, Oracle, IBM, Sun also has some other companies recently announced their support; the US Cyberinfrastructure project and new Eu project are also in progress. Similarly, people also recognize that middleware plays a very heavy role: ensuring security, reliability, interoperability resource sharing and management. Therefore, I don't care if I have a fierce anti-reaction: the grid has arrived, no matter how much pain we have experienced when building it, we have to accept it.
I don't want to underestimate the "drama", but I think everyone often thinks it seriously. When the Globus Alliance initially includes support for OGSI support in GT3.0, we promise to support the GT's pre-web service part, and many users continue to use them. I do our best to recommend the actual product level service, as the WS-Based-based part has not reached the product level level. WSRF is an increasing change from OGSI, which we will continue to support OGSI in the future.
Developers of distributed systems must carefully examine the available techniques and then determine the most suitable need. Globus Toolkit, OGSI and WSRF are not suitable for all situations. However, we don't want to think about it. "My problem is different or very simple, so I still develop my own middleware." Distributed calculations are very complicated on multiple levels, from security, reliability to credibility management; interoperability is always challenging. There are many advantages in the standard framework, can solve some very pressing problems: login, multiple use; remote deployment; calculation management, data movement, etc. Users with GT can be helpful in this area, and can also be discussed in a global community composed of a developer and user.
Question 6: What is the timetable of your approved WSRF standard? Do you think GGF is feasible as a standard organization? WSRF has been included in the GGF's OGSI Working Group discussion schedule, which will be discussed. These specifications are likely to be submitted to Oasis (Organization for The Advancement Of Structure Standards), in order to ensure the demand of the grid can be met, OASIS is launched a formal contact process with the GGF. This is very simple: WSRF is not a set of pure grid standards, but it happens to be a group of WS standards that are very related to the grid. The WS standard is usually treated by OASIS or W3C. After submitting, what time does it take to complete this standard or unknown, but the GGF's OGSI team has made great efforts, this process will make it faster.
Some people think that the WSRF is submitted to Oasis, and GGF is not an independent standardization organization. I don't think so. GGF has proposed a number of grid standards that are being applied, such as Gridftp and GSI. Other specifications are still in development, such as Dais. Naturally, the grid is also based on other organizations such as IETF, W3C and OASIS. Some GGF participants also participated in other such organizations, for example, OGSI authors as an invited expert in WSDL Working Group of W3C. GGF's CMM and Oasis WSDM WG also have intersection. We expect to see more such situations, which make GGF not only as a meter of the grid standard, but also the grid requirements to integrate the promotion of other standardized organizations.
Question 7: OGSI specification In addition to the Globustoolkit implementation, there are other implementations. However, once the Globus abandoned the boat, turned to WSRF, OGSI will have so many followers?
Due to the reasons I mentioned, the Globus Alliance is committed to upgrading Globus Toolkit into WSRF. As far as I know, other OGSI implementations, such as Pyglobus, OGSI.NET, OGSI :: Lite and Unicore also have the same trend, such as the main designer of OGSA related specification, like WSDM (Management), DAI (Data Access and Integration ) The same as WS-AGreement. Therefore, although there is no reason not to continue in the OGSI framework (we will continue to support the WS component based on GT 3.x for a period of time, depending on our manpower and users), it should be prepared next year to WSRF.
Question 8: Many scientists still use the library-style API, do not understand web services or grid services. Do you continue to support the style library bags like GT2?
Current communities are working hard to provide gathering skills through creating services rather than sharing programs or data, I fully expect the problem of scientific calculations to solve the environment (PSE, Problem-Solving Environment) is increasingly turning to the service. For example, this concept is the core idea of the International Virtual Observatory Initiative (INTERNATIONAL VIRTUAL OBSERVATory Initiative). A slightly smaller US Fusion Collaboion Collaboion project exempts the remote user needs to download and install complex applications from remote users. More general, network service is a powerful framework for establishing a large-scale distributed system, through a strict interface, can be developed unconstrained.
However, many communities and users still need special features (for example, computer or data from access) This is achieved by GT2 style library creation and managing remote computing, delivery data. This is why GT3 and GT4 provide client APIs for these features. As long as there is a similar important need, these APIs will continue to be supported. Indeed, we want GT and this API in GT-based tools will be more, so, more high-level, application-oriented grid tools will be developed. Question 9: A disadvantage of the OGSI specification is that some focus issues are very small, such as how to support two independent but compatible implementations interoperability. For example, the security model in GT3 is a non-standard mixture of GSI and WS-Security. WS-AdRessing should help avoid repeated resolution of the handle. Whether the GLOBUS Alliance has also taken measures to avoid repeating the same mistakes, such as interoperability?
The OGSI specification focuses on the WSDL interface of the grid service. Interoperability involves many other problems such as security and reliable communications. We maintain close contact with other OGSI / WSRF researchers, hoping to perform interoperability testing as soon as possible. This work should help to draw an interoperability of the OGSI / WSRF.
Finally, interoperability requires a wide range of WS and grid standards. Only when these criteria are in place and meet the grid needs, the value of the WS as the grid can be fully achieved. Therefore, we must be necessary to participate in a broader web service community and organizations like the WS_I Forum to ensure that our WSRF standard service has complete interoperability, whether it is provided by the grid or by the web Service middleware is provided.
Question 10: How to build a information service from the WSRF grid? Is there a specified mechanism (such as monitoring and discovery services)? Or will you use an existing registration technology?
A new feature in OGSI / WSRF is a high integration of the information service mechanism. Any grid service (called WSRF resources in WSRF) can declare service data (resource attributes in WSRF), which can be found, removed, put in the standard mechanism. WSRF's WS-Notification Specification allows us to take an important step. By establishing some interfaces that have been widely used, information services that have been widely adopted based on messages can be provided. For an alteration, a programmer develops a file transfer service, just define some appropriate service data (resource properties), and then the service can be discovered and monitored. On this basis, it is possible to define a wider range of information service components to discover, monitor, get them, and you can capture, and so on. The Globus Alliance is developing the prototypes of these components, including a archive service and registration service, and status providers can update status information more quickly. The first version will appear in GT3.2, and more complete will be in GT4.0.
A new feature in OGSI / WSRF is a high integration of the information service mechanism. Any grid service (called WSRF resources in WSRF) can declare service data (resource attributes in WSRF), which can be found, removed, put in the standard mechanism. WSRF's WS-Notification Specification makes us an important step, and more widely uses messages-based intermediates to provide more robust and more rich information services. For an alteration, a programmer has developed a file transfer service, which only needs to define some service data (resource properties), which is visible to others and can be monitored. On this basis, it is possible to define a wider range of information service components to discover, monitor, get them, and you can capture, and so on. The Globus Alliance is developing the prototypes of these components, including a archive service and registration service, and status providers can update status information more quickly. The first version will appear in GT3.2, and more complete will be in GT4.0. Question 11: What advice do you have for developers before the WSRF's reliability is available? When can we see WSRF components in other languages, not just Java?
Let's talk about Globus Toolkit. GT3 includes reliable implementation of the PRE-WS components of GT and early implementation based on WS components. The upcoming GT3.2 is greatly improved to WS components. While continuing to support the PRE-WS components, it emphasizes the availability, robustness and performance of network services. GT4.0 may be released in the third quarter of 2004, which will introduce the support of WSRF, while continuing to improve the availability, robustness and performance of WS components based on WS components, support PRE-WS components.
Other OGSI implementations also plan to evolve WSRF, but I don't know the specific timetable. Stephen Pickles recently announced that he has almost completed the transformation of OGSI :: Lite to WSRF.
With this occasion, I made a few suggestions:
If you work very well with pre-ws, just like a lot of product, then continue. They will still be supported in GT3 and GT4. As long as there is still a need, we will continue to support the Pre-WS components, we have human support to 2005.
If you are using GT3.0 network-based GT components, in order to get better performance, turn to it when GT3.2 is released. Further, if WSRF is meaningful, turn to it. We will continue to support GT3.x components, we have human support to 2005.
If you have just started to be familiar with the network service and grid, use GT3.2 first, then turn to GT4.x at some time next year.
Question 12: The last problem comes from the United Kingdom, I know that the UK's E-Science project has started from 2002, and many of its infrastructure is closely related to Globus technology. It seems that the UK's e-science project is not too early?
no. The Timetown of the UK's E-Science project is very good, making the British play a clear role in the development of the grid. For example, if there is no funding of the UK's E-Science project, Ogsa-Dai's work will be started or not at all, and the UK will not play a pilot in data services. The Globus Alliance will not join the University of Edinburgh.
For this issue, I want to clarify a misunderstanding associated with it. E-Science work is about the environment you need to create science in the 21st century. Naturally, similar to architecture, we are more willing to move into a built-in house, and some users seem to want Globus to be a house. However, as its name, Globus Toolkit is just a series of tools, not a complete solution. For skilled developers, you can develop good results as long as you apply these tools to resolve authentication, discovery, remote access, and other distributed computing challenges. But success is not only completed after having a scientist and globus toolkit, it naturally. It requires the cooperation of scientists and grid technology, and / or available high-level faces to specific applications, like Griphyn / PPDG virtual data kit, Access grid, and some portal tools. Therefore, from the whole, the development of the grid needs to be creative and understood. With the accumulation of experience, we are also constantly deepen our understanding, know how to better build a robust, reliable global grid. As a good example of cooperation, let's take a look at the Network for EarthQuake Engineering Simulation Grid, which is the earthquake simulation grid to be completed this year. Neesgrid established a mature, distributed experimental control and collaboration system with GT3 OGSI software. Some of these tasks need to turn OGSI software to GT4, but Neesgrid designers believe that the cost of changes in changes in the integrated collaboration tools that have been deployed on each NeesGRID node and are still small compared to everyone's training. In July last year, NeesGrid completed a multi-site earthquake test. Test equipment in Colorado and Illinois, the simulation system in Illinois, data files, and humanity participated in 12 sites. If there is no NeesGrid, this new science will not be completed.
The second example of me is the US GRID3 system. Starting in November 2003, the PRE-WS components that have been used in the United States and South Korea have continued to operate 500 to 2000 data analysis tasks on the 27 grid nodes of the United States and South Korea, covering a series of physical, biological and computer science projects. Better and Griphyn / PPDG Virtual Data Toolbox (Virtual Data Toolkit) developers unfolding, using the GT mechanism to synergist of data-intensive workflows on multiple sites, currently this plan has achieved great Application results. In addition, for what you need to create and run a operable grid, you have also accumulated a lot of experience.
postscript:
Thanks to Ian to take a valuable time and answer the questions I proposed. Undoubtedly IAN will consider the issues raised in this talks, and he will consider issues raised in GGF10 held in Berlin, Germany in March 2004.
Mark Baker is a senior lecturer of a Portsmouth University of Portsmouth University, a high-level lecturer of a distributed system of the Westminster University, a computer science visiting professor at the Cavendish Computer College. Contact: mark.baker@computer.org.
