Genesis II Wiki
|June 29, 2017, at 08:18 AM||Genesis II Wiki / Main / Standards|
Grid computing is all about connecting resources that are spread across wide distances and disjoint, sometimes even untrusting organizations. In such an environment, one cannot rely on any central authority to mandate any particular software or hardware solution. Therefore, interoperability between grid computing components is absolutely critical if grid systems are to have any chance of growing beyond small or localized deployments. The VCGR is committed to providing leadership and helping to drive forward grid computing standards for the community because we feel it is both our duty as a research institution to lend our experience to the process as well as an enabling step in our effort to push grid systems to the next level of size and scope.
Several VCGR members have been or are currently actively engaged in leading standards efforts within the Global Grid Forum (GGF) - the premier grid systems forum and standards body. Andrew Grimshaw is currently a member of the GGF Steering Committee acting as the architecture area director and is co-chairman of both the Open Grid Services Architecture (OGSA)- Basic Execution Service (BES) group and the OGSA- Naming Group.
OGSA - Basic Execution Service
Basic Execution Service (BES) is a service to which clients can send requests to initiate, monitor, and manage computational activities. The specification defines an extensible state model for activities; an extensible information model for a BES and the activities that it creates; and two port-types; BES-Management and BES-Factory. BES-Management defines operations for managing the BES itself. BES-Factory defines operations for initiating, monitoring, and managing sets of activities, and for accessing information about the BES. An optional unspecified BES-Activity port-type indicates an extension point for operations relating to the monitoring and management of individual activities.
The ByteIO Specification is a description of a set of port types that give users a concise, standard way of interacting with bulk data sources and sinks in the grid. The purpose of these port types is to provide the means for treating such data resources as POSIX-like files. At the same time, clients will be able to leverage these port types to provide users with a convenient way of interacting with these grid resources. The purpose of this specification is to address a common case and common requirement in the grid community. Other applications may choose to provide more application specific interfaces for accessing and modifying bulk data in their own resource endpoints, however it is hoped that they will choose to additionally support ByteIO as a means of providing a common interface to which arbitrary clients can speak.
ByteIO is divided into two port types and each addresses a unique set of use cases. The first of these port types supports the notion that a data resource is directly accessible and that clients can handle the maintenance of any session state (such as file pointer, buffering, caching, etc.). The other port type presents a more stream-like interface to clients and as such contains implicit session state. In this latter case data resources with this port type dont represent that bulk data source/sink directly but rather represent the resource of the open stream between the client and the data source/sink.
While WS-Addressing has not yet completed its course through the standards process, the general shape of the specification is relatively stable. Given the almost universal acceptance of WS-Addressing as a de-facto standard in the web services community, targeting this addressing mechanism for use by WS-Naming is a reasonable and obvious choice.
Rather than target unreasonable or unlikely changes in the WS-Addressing specification itself, we have chosen the alternative route of presenting WS-Naming as a profile on top of the WS-Addressing specification. Neither web service clients nor web service endpoints need to be aware of this profile and either are free to fail to generate or understand the WS-Naming elements described within. In such a case, the normal WS-Addressing behavior still works exactly as described in the specification. However, should a client (which is aware of the WS-Naming profile) encounter WS-Naming elements in a WS-Addressing Endpoint Reference, it will have the option to take additional actions with its communication to that web service endpoint in the event of certain communication failures.
WS-Addressing describes an Endpoint Reference type with a single required element (the Address element) and a number of optional elements. WS-Addressing Endpoint References allow for extensibility elements to be added (via an xs:any declaration in the schema) without changing the specification. Further, the specification also notes that this information is not authoritative and may be stale or incoherent. This allows for a WS-Naming profile to use WS-Addressing extensibility elements for various pieces of naming and rebinding information . Clients choosing not to participate in the WS-Naming profile communicate without modification as per the WS-Addressing specification.
|Validate the XHTML and CSS of this page.||Page last modified on November 01, 2011, at 01:20 PM||Edit History Print Recent Changes|
Powered by PmWiki