A pre-release of GRIA demonstrated the feasibility of the WebServices approach by supporting a business tender process modelled on real commercial practice (“invite-tender-contract”). The first full release of GRIA in 2003 introduced accounting of usage and invoicing. The financial model again reflected standard business practice, with a requirement to establish a supplier account in advance of any contractual relationship and invoicing typically at month-end. The tender process also supported quality-of-service negotiation and the additional feature of a ‘pre-approved supplier list'. Evaluation inside the project by end-users identified a wide spectrum of different requirements for the user interface. At one extreme were users that expected a command-line interface, while at the other extreme the users requested an easy-to-use graphical interface. GRIA v1 used a ‘wizard’-type interface which could not accommodate these widely different requirements – the application workflow enforced proved to be much too restrictive. To provide maximum flexibility a client-side API was designed to allow user partners to write their own client-side programs for GRIA user applications.
In our programs we make use of the Dispatch event interfaces of the PowerPoint application, connectable object, connection point technology and event sink to catch and deal with these semantic events. For some reasons, in Microsoft PowerPoint, one can only get the hexadecimal codes of these events instead of meaningful string name descriptions as in the other applications of the Microsoft office suites. With codes like this, one can not know the meanings of them and can not figure out which is which. We have done logical analysis according to the input / output of presentation processes, and, finally map each of the code to its corresponding meaningful string name in the event interface of the PowerPoint. We call this process a translation.
Abstract. We review the emergence of a diverse collection of modern Internet- scale programming approaches, collectively known as Web 2.0, and compare these to the goals of cyberinfrastructure and e-Science. e-Science has had success following the Enterprise development model, which emphasizes sophisticated XML formats, WSDL and SOAP-based WebServices, complex server-side programming tools and models, and qualities of service such as security, reliability, and addressing. Unfortunately, these approaches have limits on deployment and sustainability, as the standards and implementations are difficult to adopt and require developers and support staff with a high degree of specialized expertise. In contrast, Web 2.0 applications have demonstrated that simple approaches such as (mostly) stateless HTTP-based services operating on URLs, simple XML network message formats, and easy to use, high level network programming interfaces can be combined to make very powerful applications. Moreover, these network applications have the very important advantage of enabling “do it yourself” Web application development, which favors general programming knowledge over expertise in specific tools. We may conservatively forecast that the Web 2.0 approach will supplement existing cyberinfrastructure to enable broader outreach. Potentially, however, this approach may transform e- Science endeavors, enabling domain scientists to participate more directly as co- developers of cyberinfrastructure rather than serving merely as customers.
adaBrokering has been developed as the messaging frastructure for collaboration, peer-to-peer and Gridapplications. It has undergone extensive functional testing in collaborative sessions and extensive performance measurements have been made in a variety of configurations including cross-continental applications. The value of NaradaBrokering in the context of Grid and Webservices has been clear for some time. NaradaBrokering provides a messaging abstraction that allows the system to provide message-related capabilities in a transparent fashion. These capabilities include message-based security and associated encryption, time and causal ordering, compression, virtualization of transport protocol and addressing, and fault tolerance related functionalities. NaradaBrokering – combined with further extensions to, and testing of, its existing capabilities – can also take advantage of the maturing of Web Service standards to build very powerful general mechanisms to deploy and integrate it with general Webservices.
nnection point technology and event sink to catch and deal with these semantic events. For some reasons, in Microsoft PowerPoint, one can only get the hexadecimal codes of these events instead of meaningful string name descriptions as in the other applications of the Microsoft office suites. With codes like this, one can not know the meanings of them and can not figure out which is which. We have done logical analysis according to the input / output of presentation processes, and, finally map each of the code to its corresponding meaningful string name in the event interface of the PowerPoint. We call this process a translation.
The application layer reliability is not unique to Webservices. There have been reliable messaging schemes in the application layer for XML-based collaborative applications. Among the earlier works, there have been efforts such as RosettaNet PIP model  and the BizTalk framework  which provide business-level reliable messaging. Both of them exchange positive or negative acknowledgement messages within their business architectures. A more general approach was specified by ebXML with its ebXML Message Service (ebMS)  which is the first reliability scheme binding with SOAP message and the antecedent of WS-Reliability. The reliability in ebMS is from the exchange of ebMS Message Service Handler (MSH) responding to a message with an Acknowledgment message.
The history of Internet and Web technology saw the evolution of Webapplications with architectures dominated by centralized client-server system with traditional point-to-point (unicast) connection, decentralized self-organizing peer-to-peer (P2P) system that evolved to overlay network with application level multicast mechanism, and RPC-model (e.g. CORBA) derives from method-based system calls for tightly coupled single CPU system (e.g. desktop applications) but with remote procedure calls to support the distributed objects. Client-server and P2P models are suitable for solving problems with features applicable to their patterns but real world problems can be arbitrarily complicated. Examples can be seen in parallel applications with decomposition in high dimensionality. On the other hand, RPC-like model deals well with distributed objects or components for reusability but do not scale well. Message-based Web Service model provides a unified approach that incorporates messaging flexibility with components distribution. It accommodates to the diverse and scaling nature of the Internet and also promotes Webapplications development with WebServices for reusability, interoperability, and scalability.
5.6. Gridservices benefits. Several benefits already stated bellow and several others mentioned in  motivate the migration to the WSRF standards and exposing CAS functionality using Grid service technology. SymGrid-Services complies with the WSRF standard for Gridservices. While Gridservices have different goals from pure webservices (sharing computing power and resources like disk storage databases and software applications, versus sharing information), a Grid service is basically a Web service with some additions: stateful services, service instantiation, named service instances, two-level naming scheme, a base set of service capabili- ties, and lifetime management. These supplementary capabilities allow improved user interaction with remote symbolic computing services: previous computations performed by a service can be stored as service state, personalized services are possible due to the instantiation facilities, services can be easily modified due to the naming schemes, standard search facilities can be implemented due to the standard service data elements, and resource management can be easily done due to the transient character of the services. Complying the WSRF standard imposes not only that the interface is offered to the user, but that it preserves the original specified behavior.
We may view it as a collection of capabilities provided by different organizations that have banded together to form a “Virtual Organization” . A capability is just a Web Service, and Grids may be built from collections of WebServices. A Grid service is just a Web Service, although it may follow more restrictive conventions defined by OGSA. It is actually better to define a Grid by how it is used rather than how it is built. In this section we investigate some of the issues involved in building Grids of Grids. We recommend two sets of services to facilitate such a scenario. Services provided within the substrate constitute the Internet-on-Internet (IOI) services. It is referred to as IOI since it enables us to build an application-level “Internet” of services connected by a messaging substrate that replicates in the application layer many of the desirable features (security, guaranteed delivery, optimal routing) that are normally found in the TCP/IP stack. See Ref  for a discussion of why TCP/IP is not enough, and thus why IOIs are necessary for SOAP messages. These services have been described in detail in sections 2 and 3.
Grid application frameworks have increasingly aligned themselves with the developments in WebServices. WebServices are currently the most popular infrastructure based on Service Oriented Architecture (SOA) paradigm. There are three core areas within the SOA framework: a set of capabilities that are remotely accessible, communications using messages, and metadata pertaining to the aforementioned capabilities. In this paper, we focus on issues related to the messaging substrate hosting these services; we base these discussions on the NaradaBrokering system. We outline strategies to leverage capabilities available within the substrate without the need to make any changes to the service implementations themselves. We also identify the set of services needed to build Grids of Grids. Finally, we discuss another technology, HPSearch, which facilitates the administration of the substrate and the deployment of applications via a scripting interface. These issues have direct relevance to scientific Gridapplications, which need to go beyond remote procedure calls in client-server interactions to support integrated distributed applications that couple databases, high performance computing codes, and visualization codes.
It should be noted that more recently there has been an effort to factor the OGSI  functionality to comprise a set of independent Web Service specifications. These specifications align OGSI with the consensus emerging from the WebServices Architecture working group of the World Wide Web Consortium. The specifications that comprise the new proposed framework – the WS- Resource Framework (WSRF)  – can co-exist with other specifications in the WebServices area such as authentication, transactions, reliable messaging and addressing. The WSRF specification also includes WS- Notification  which models notifications using a topic based publish/subscribe mechanism. Similarly, the WS- GAF  effort in the United Kingdom provides a framework for building Gridapplications using existing WebServices specifications while adhering to the
This white paper summarizes the current state of Grid Systems [Foster99A] [GGF-A] [Berman03A] [GapAnalysis] with particular attention to their possible relevance to HPCMP applications. We particularly wish to emphasize in this report a comprehensive view of Grid technologies and research: as we describe in the next sections, so-called “(meta)computing grids” are a subset of a much broader international research and development trend. In Section 2, we describe different types of Grids and contrast their use and implementation with clusters and massively parallel systems. Section 3 is a brief review of DoD opportunities stressing data services, portals and application integration rather than the “utility and metacomputing” areas where Grids were first proposed. The technology itself is summarized in section 4 in terms of different services linking Grid and Web Consortium approaches. Section 5 enumerates several possible DoD
NaradaBrokering [8, 9, 13] is a messaging infrastructure that is based on the publish/subscribe paradigm. The system efficiently routes messages  from the originators to the consumers that are interested in the message. The system places no restrictions on the size and the rate at which these messages are issued. Consumers can express their interests (or specify subscriptions) using simple formats such as character strings. Subscriptions may also be based on sophisticated queries involving XPath, SQL, or regular expressions. Support for these subscription formats enables consumers to pre- cisely narrow the type of messages that they are interested in. The substrate incorporates support for enterprise messaging specifications such as the Java Message Service . The substrate also incor- porates support for a very wide array of transports (TCP, UDP, Multicast, SSL, HTTP and Paral- lelTCP among others), which enable the infrastructure to be leveraged by entities in a wide variety of settings. To cope with very large payloads the system leverages ParallelTCP at the transport level and services such as compression and fragmentation to reduce individual message sizes. The fragments (compressed or otherwise) are reconstituted by appropriate services (coalescing and de-compression) prior to delivery to the application.
In fact Gridmessaging is more naturally related to message oriented middleware (MOM) [Bernstein1996] [MOM] and software overlay networks [Doval2003] than to MPI or PVM style messaging. The rich MOM infrastructure support messages that are self-describing and as well capture semantic intent. Depending on the application these messages can be made to encapsulate system conditions, method invocations, resource sharing, data interchange among others. Messages may also describe their correlation, dependency and causal relationships to other messages. The SOAP messaging used by WebServices illustrates this richer structure with a body containing the “real message” and separate headers corresponding to systems services including security, notification, virtualized addressing, fault tolerance, notification and special operations and relationship to resources. Processing this additional information typically takes a millisecond or so and adds significant functionality at insignificant fractional cost. In designing systems and algorithms for distributed systems it is important to understand this additional functionality and incorporate it into your architecture. Another difference between SOAP and MPI is that MPI only specifies interface and so interoperability between different MPI implementations requires additional work [IMPI]. SOAP however specifies both interfaces and message structure so broad interoperability can be achieved. This is a achieved at a performance cost that we return to in Sec 6.5.
In this article we discussed the problems that will likely arise as the number and complexity of services increases along with the interactions that exist between these services. Our proposed solution addresses most of these problems. This is a large area of research the scope of which may have far reaching implications. This is a complex problem the complete solution to which may take a significant amount of time. The underpinnings to this substrate and some of the core functionalities are being added to the messaging infrastructure NaradaBrokering [6,7], which is an open source project at the Community Grid Lab at Indiana University.