GSIP – An Alternative Web Service Invocation Protocol

Ondrej Krajıcek, Petr Holub

Institute of Computer ScienceMasaryk University Brno, Botanicka 68a, 602 00 Brno, Czech Republic

{krajicek,hopet}@ics.muni.cz

Abstract

Generic Service Invocation Protocol (GSIP) aims to providean alternative communication infrastructure for applicationsbased on the Web Services technology. It is designed for en-vironments where traditional SOAP based approach imposesdrawbacks on performance and scalability, leads to wasting re-sources and/or processing power. Such problems may emergein various environments, e. g. large-scale information systems,Grid computing, high-performance or mobile computing ap-plications. The GSIP is designed to address the shortcom-ings, by introducing service-specific invocation model and cor-responding infrastructure and by using alternative data encod-ing schemes. This allows for extensibility and implementationof several more advanced modes of operation as well, such aspublisher/subscriber, producer/consumer etc. We present theGSIP design and architecture, some performance studies andsome implementation and deployment scenarios.

1 Introduction

Today the Web Services are becoming more and more estab-lished technology in the area of multi-tier applications, mainlyin middleware [6] tier. The initial technical specification hasbeen proven to be open and scalable enough for most applica-tions of moderate complexity in various fields of computing.However, for the large scale applications, such as universityor enterprise information systems, Grid or high-performanceComputing applications, the current Web Services technologymay impose significant bottlenecks in terms of both perfor-mance, scalability and robustness.

The traditional Web Services architecture also enforces pullmodel which is clearly not suitable for a whole class of ap-plications. A publisher/subscriber model is often more appro-priate as already implemented by Grid services as specified inOGSA [1].

To address real and potential drawbacks in Web Services tech-nology, and especially those introduced by the SOAP messag-ing protocol [2], we are designing an alternative communica-tion infrastructure for Web Services, namely GSIP – GenericService Invocation Protocol. The GSIP is meant to be an al-ternative Web Services invocation infrastructure and protocolin environments, where using XML-based SOAP for commu-nication means intolerable limits in scalability or wasting net-working resources and processing power [3]. GSIP protocoluses binary encoded messages and is designed from the scratchwith existing performance and scalability problems in mind.

The rest of the paper is organized as follows: Section 2 briefsrelated approaches, Section 3 gives overview of the GSIP ar-chitecture, Section 4 highlights GSIP advanced operation sce-narios that are supported by GSIP, Section 5 describes proto-type implementation and gives prototype performance evalua-tion results, Section 6 summarizes directions of future devel-opment, and Section 7 finishes with some concluding remarks.

2 Related Work

In last four years, we have witnessed a broad adoption of WebServices technology. However, in various applications, poten-tial and real drawbacks (mainly performance issues) emergedas the technology deployment base grew. This lead to develop-ment of several projects/technologies aiming to provide a solu-tion. We show some examples and their brief description, withreferences to relevant sources.

First group of approaches tries to optimize SOAP manipulationto make it as efficient as possible. For example, the gSOAP is ahigh-performance SOAP toolkit for C/C++ [8] used in high-performance and Grid computing applications. It generatesSOAP parsers based on deterministic finite state automata gen-erated specifically for each application.

Second group comprises other approaches that are not boundto SOAP any more. REST (REpresentational State Transfer)architecture is an example of this approach as it is based solelyon existing WWW technologies, such as HTTP protocol. It hasbeen created by Roy Fielding and published in [7]. CommonLanguage Infrastructure (CLI) Remoting is a toolkit for remoteobject invocation. It is standardized in [9]. However function-ally similar to Java RMI, it allows for use of multiple communi-cation protocols and message encoding schemes. CLI remotingcan be used for Web Services invocation. DIME – Direct In-ternet Message Encapsulation is a new binary format for mes-sages and their encapsulation similar to MIME. DIME standardwas proposed by IETF draft1, which has expired. Nevertheless,several implementations of DIME are available.

3 GSIP Architecture and Design

GSIP design is object oriented, centered around the service in-vocation model concept. Service invocation model identifiesthe components which take part in service invocation, clearlystates their interface, interaction and responsibilities. The ser-vice invocation model is service specific, by design, neverthe-

1http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft-nielsen-dime-02.txt

less the fundamental parts are common to all services. Serviceinvocation model is generated by the specialized tool whichshould be part of the GSIP implementation.

For implementation, GSIP neither dictates nor requires partic-ular (object oriented) programming language, environment orlibraries. Our intention is to provide standard invocation infras-tructure which may interoperably implemented in majority ofexisting environments.

GSIP is designed with the following goals:

• Simplicity – An architecture of the GSIP should be keptsimple, as CORBA is available for more complex cases.

• Performance – The GSIP is designed for high perfor-mance, and thus efficient data representation, low trans-mission overhead, as well as low memory requirementsare priorities.

• Extensibility – The GSIP design and architecture has to beeasily extensible.

• Scalability – The GSIP implementations should scale wellin terms of number of requests and concurrent users.

• Smooth coexistence with other technologies – The GSIPshould coexist effortlessly with other technologies (par-ticularly SOAP) and used only where appropriate.

The GSIP architecture is divided into logical layers, as shownin Fig. 1. The design is inspired and motivated by traditionalservice-oriented architectures which employ remote invocationof services (such as Web Services, Remote Procedure Call, CLIRemoting, etc.) to enable easy integration into and interoper-ability with existing applications.

Web Service Application

WSDL

Service Invocation Model

Communication Channels

HTTP[SG]?,...

TCPUDP

IP

TCP

Figure 1: GSIP Web Services Architecture

The design of the service invocation model is based on the webservice operation scheme as shown in Fig. 2. The flow of con-trol and data between service invocation model components isshown in Fig. 3.

Client Serv ice Container

Proxy Request Request

ResponseResponse

Serv ice

Figure 2: Traditional Web Service operation

Session

Invocation Message

Channel

Data Unit

0..* 0..*

0..1

0..*

0..*

1

0..1 0..* 1..* 0..1

Data Units

Data Units

Data Units

Figure 3: GSIP Service Invocation Model

3.1 Service Interaction

GSIP provides message based communication infrastructure,service consumers (clients) and services (servers) interact byexchanging messages from predefined set. Service interactionis implemented by means of Service Invocation Model, theclient stub and server skeleton.

3.2 Service Invocation Model Components

Service Invocation Model defines the following components:Service Proxy, Service Dispatcher, Session, Invocation, Chan-nel, Message and Data Unit. At runtime, the components ofService Invocation Model naturally form a tree structure. Byusing this tree-based approach to service invocation, more pre-cise and robust error handling and recovery may be imple-mented in easy and convenient way.

Session. Session component represents a particular interactionbetween service consumer and a particular service instance.We may see such interaction as a sequence of messages (re-quests and responses) exchanged between the two entities. Thesession is usually initiated by the consumer, but it is not com-pulsory.

Invocation. Invocation component represents a particular re-quest (service invocation), done by the consumer. It is used toconstruct GSIP messages (via Data Units and Message compo-nents) and to handle received responses.

Invocation component (class) exists for each operation the ser-vice provides (as specified in its WSDL contract) and it is in-stantiated for each particular call made to it; this means that aparticular Invocation instance is bound to exactly one Sessioncomponent.

Message. Message component represents a transmission unitand the communication between the two parties is done solelyusing Messages. Whole information contained in a Message isrepresented using Data Units.

Data Unit. Data Unit represents a particular piece of data, suchas data from messages, but also e. g. digital signature informa-tion, in-band control data etc. Data Unit component (class)exists for each service message definition (as specified in itsWSDL contract) for instance. All Data Unit classes have con-sistent data encoding implementation, which defines the mes-sage encoding scheme.

Channel. Channel component is an abstraction over trans-portation mechanism. Channel provides services to send andreceive messages and hides all other implementation dependentdetails. The Channel interface cohesion is high, so that it isgeneric enough for various transportation mechanism, such asTCP/IP protocol family, higher-layer protocols (such as SMTP,HTTP), etc.

Multiple communication channels may exist in Service Invo-cation Model for particular Session. Also, the underlying (net-work) connection is not required to be persistent (e. g. it maybe established on demand and closed when idle).

Service Binding. Service Binding reflect the fact, that theclient is bound statically to a particular type of service (i. e.client expects certain service interface). However, at the ap-plication design-time, it is not important which particular in-stance of the respective service will be invoked and where itruns. At runtime then, the client may (and often does) obtainthe service reference dynamically and then connects to this par-ticular service. By introducing Service Binding component tothe Service Invocation Model, GSIP could handle transparentlyservice reachability problems and completely hide such errorhandling logic from the application logic itself. However, thiscomponent is not available in current prototype (Sec. 5).

4 Example Operation Scenarios

To demonstrate various advantages of GSIP design comparedto the traditional Web Services approach based on SOAP, sev-eral possible operation scenarios are provided in this section.

4.1 Migration Transparency

GSIP design allows implementation of systems based on theWeb Services which are capable of the migration transparency.The protocol stack with its Service Invocation Model is nat-urally able to detect or negotiate service migration (by meansof Service Binding and Session components) and to reconstructthe invocation tree up to the appropriate service consumer bind-ing. Such reconstruction may be directed by the service or con-trolled using client configuration information.

4.2 Disconnected Operation

The same mechanism as in migration transparency scenario al-lows implementation of disconnected client operation. Whenthe client and server operate in disconnected mode, they storethe messages locally, instead of attempting to deliver them im-mediately. The locally stored messages are transmitted from

the client to server (and vice versa) when the network connec-tion becomes available. The disconnected operation may bean elegant solution for distributed applications in environmentswhere bandwidth/network connectivity is expensive, limited,unstable or not available at all – such as mobile computing en-vironments.

4.3 Publisher-Subscriber Model

Traditional Web Services operate in pull model—a client sendsa request to a server, the server processes the request and sendsa response in return. This is communication model is also usede. g. in traditional World Wide Web. However, it may not besufficient for all applications. GSIP protocol design allows im-plementation of pull or push communication models, such aspublisher/subscriber.

In the publisher/subscriber model, the client registers for someevent notification and disconnects. When the particular eventoccurs the client is called back with notification. When im-plemented using traditional pull model, the client has to pollthe server for the event occurrence in regular intervals, whichleads to wasted computing resources and bandwidth and also tounavoidable delays in event occurrence at the server side andevent notification processing at the client side.

The GSIP protocol design also introduces a notion of persis-tent channels. The client stack is able to negotiate a persistentchannel with the server stack, which may be used for pushingdata from the server side to the client side. Such channel maybe transparent to the application and handled completely by theprotocol stub, the application just provides a callback functionsto be called, when the notification arrives.

4.4 OGSA Integration

To address some shortcomings of the Web Services model,the Grid Services based on Open Grid Services Architecture(OGSA) [1] introduced several extensions to the WSDL lan-guage and Web Services technology itself, such as notifica-tion interfaces similar to our publisher/subscriber model. Italso provides soft-state operation to support unreliable envi-ronments that can be easily integrated into GSIP as well.

One of our primary goals for the GSIP protocol is to fit in theOGSA framework and to be a viable replacement of the SOAPprotocol for Open Grid Services Infrastructure (OGSI)2. TheGSIP should provide efficient communication between OGSA-compliant Grid services allowing application of the OGSA ar-chitecture on services for which it currently means unaccept-able overhead of communication.

2The OGSI has been obsoleted by WSRF recently which is planned to beimplemented in Globus Toolkit version 4. However, we believe that GSIPintegration will remain applicable for WSRF-enabled Grid Services as well.

5 Prototype Implementation

GSIP testing and evaluation has been done by prototyping.Current GSIP prototype code named Gondor, which was usedalso for performance testing for this paper, is implemented inC#. Performance tests were run on Microsoft Shared SourceCLI called Rotor [5] and Microsoft .NET Framework ver-sion 1.1.

The Gondor prototype consists of invocation framework (calledthe stub on the client and skeleton on the server side) and Ser-vice Invocation Model Generator (SIMGEN utility). Invoca-tion framework implements Session and Channel componentsof the GSIP invocation model. SIMGEN utility is used to pro-duce service invocation model implementation in the form ofsource code. This source code complements the abovemen-tioned invocation framework and provides implementation ofall invocation model components for particular service.

SIMGEN utility operates by constructing an object orientedrepresentation of service WSDL contract, called ServiceModel. This service model is than processed and transformedinto object oriented representation of Service Invocation Modelsource code (the Service Code Model). This Service CodeModel is used to generate the actual source code for the ser-vice. SIMGEN utility is implemented using Microsoft Code-Dom technology (which is part of Rotor and Microsoft.NETFramework).

5.1 Prototype Performance Evaluation

For prototype performance evaluation, two simple Web Ser-vices have been implemented using GSIP. To compare the pro-totype performance, each service has also been implementedusing CLI Remoting with SOAP transport. SOAP based remot-ing was chosen since it better exposes the overhead of SOAPbased message encoding by eliminating the overhead burdenof Web Service containers (such as Apache, Internet Informa-tion Service, etc.). Both implementations (GSIP and Remot-ing/SOAP based) have been executed in two environments: Ro-tor and Microsoft .NET Framework v1.1 on single-processormachine with Windows XP. Time per one handled request andtotal spatial overhead of messages have been measured.

Echo Service is a Hello World incarnation in Web Servicesworld, at least when it comes to simplicity. Echo servicedescription is shown in Fig. 4. The service implementationechoes the received number (echoRequest) in the response.This service demonstrates the SOAP and GSIP overhead ofmessage encoding because of its trivial functionality.

Newton Service implements numerical solving of polynomialequations with the polynomial order up to nine using Newton’smethod. For demonstration purposes, a polynomial of order ofnine for which the method converges was chosen. Each requestruns ten iterations of the method. The purpose of this serviceis to demonstrate the SOAP and GSIP overhead on non-trivialmessages which contain floating point numbers. The servicedescription is shown in Fig. 5.

<message name="EchoRequest"><part name="echoRequest"type="xsd:int" />

</message><message name="EchoReply">

<part name="echoReply"type="xsd:int" />

</message><portType name="EchoPortType"><operation name="Echo"

parameterOrder="echoRequest" ><input message="EchoRequest" /><output message="EchoReply" />

</operation></portType>

Figure 4: Echo service description (simplified and shortened)

<message name="Solver.Request"><part name="iterCount" type="xsd:int" /><part name="a0" type="xsd:float" /><part name="a1" type="xsd:float" /><part name="a2" type="xsd:float" /><part name="a3" type="xsd:float" /><part name="a4" type="xsd:float" /><part name="a5" type="xsd:float" /><part name="a6" type="xsd:float" /><part name="a7" type="xsd:float" /><part name="a8" type="xsd:float" /><part name="a9" type="xsd:float" />

</message><message name="Solver.Response">

<part name="result" type="xsd:float" /><part name="durationMilis" type="xsd:int" />

</message><portType name="SolverPortType"><operation name="SolvePolynomial">

<input message="Solver.Request" /><output message="Solver.Response" />

</operation></portType>

Figure 5: Newton service description (simplified and short-ened)

Measurement Results The measurement results and com-parison between GSIP and Remoting/SOAP based services aresummarized in Tab. 1. This summary table provides results forservices running only on the Microsoft .NET Framework as itproves to be far outperforming the Rotor CLI implementation.All measurements were gathered using 10,000 requests to pro-vide large enough statistical sample for reasonable evaluation.

For Echo Service, the detailed results for both MS .NET andRotor hosted services are given in Fig. 6. For Newton Service,the corresponding detailed results are shown in Fig. 7.

It follows from the results that the GSIP is almost an order ofmagnitude better compared to the Remoting/SOAP in per re-quest processing time for both Echo and Newton services. Theadvantage of GSIP becomes even more obvious when com-paring spatial overhead (Fig. 8) as the GSIP performs almosttwo orders of magnitude better than Remoting/SOAP and it

GSIP, Microsoft.NET Framework 1.1Echo – avg. processor ticks per request 376,600±6,100Echo – avg. time per request 222.2±3.5 µsEcho – request message size 12 bytesEcho – response message size 12 bytesNewton – avg. processor ticks per request 472,500±6,500Newton – avg. milliseconds per request 278.82±3.8 µsNewton – request message size 92 bytesNewton – response message size 20 bytesSOAP, Microsoft.NET Framework 1.1Echo – avg. processor ticks per request 2,375,000±11,000Echo – avg. milliseconds per request 1,401.9±6.5 µsEcho – request message size 570 bytesEcho – response message size 584 bytesNewton – avg. processor ticks per request 2,767,000±12,000Newton – avg. milliseconds per request 1,632.8±7.3 µsNewton – request message size 1001 bytesNewton – response message size 693 bytes

Table 1: Selected results – summary

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000Request No.

1e+05

1e+06

1e+07

1e+08

1e+09

Proc

esso

r T

icks

per

Req

uest

MS .NET GSIPMS .NET SOAPRotor GSIPRotor SOAP

GSIP - SOAP Performance MeasurementEcho Service

Figure 6: Echo service – CPU ticks per request

never drops below one order of magnitude performance im-provement.

6 Future Work

To the date of writing, functional prototype written in C# isavailable. Currently, we are testing and evaluating its perfor-mance in comparison with various remote invocation and par-ticularly Web Service toolkits. The current prototype repre-sents an experimental branch written in C# hosted by CLI (Ro-tor Shared Source CLI and Microsoft.NET Framework v1.1).Another branch of prototypes, written in portable plain C isplanned. This stable prototype line will merge in features testedand confirmed in the experimental branch to produce releasecandidates suitable for production evaluation and use.

Currently, message encoding in GSIP is generic. We plan toreplace this encoding with ASN.1 based mechanism using BER(and possibly DER and PER) encoding rules [4]. Then Service

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000Request No.

1e+05

1e+06

1e+07

1e+08

1e+09

Proc

esso

r T

icks

per

Req

uest

MS .NET GSIPMS .NET SOAPRotor GSIPRotor SOAP

GSIP - SOAP Performance MeasurementService for Solving Roots of Polynomial

Figure 7: Newton service – CPU ticks per request

2000 4000 6000 8000 10000Number of Requests

10000

1e+05

1e+06

1e+07

1e+08

Dat

a T

rans

ferr

ed [

byte

s]

SOAP, Newton ServiceSOAP, Echo ServiceGSIP, Newton ServiceGSIP, Echo Service

Message Encoding Spatial Overhead

Figure 8: Spatial overhead of SOAP compared to GSIP.

Invocation Model Generator would then transform the messagepatterns found in WSDL contract into ASN.1 Type Notationand use ASN.1 compiler to produce data encoding routines,which would in turn be used by Data Unit implementations.

7 Conclusions

The GSIP infrastructure seems to provide efficient replacementfor the SOAP as Web Service transport protocol. It featuresfunctionality, which is not provided in current SOAP-basedWeb Services and promises superior performance in compar-ison to the SOAP. The main goal now is to provide production-class implementation (in C) and deploy it for production eval-uation.

References

[1] Foster, I., Kesselman, C., Nick, J., Tuecke, S.: ThePhysiology of the Grid: An Open Grid Services Archi-tecture for Distributed Systems Integration. Open GridService Infrastructure WG, Global Grid Forum, June22, 2002. http://www.globus.org/research/papers.html#OGSA

[2] Mitra N. (editor), “SOAP Version 1.2 Part0: Primer,” W3C Recommendation 24 June2003, http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.

[3] Chiu K., Govindaraju M., Bramley R., “Investigating theLimits of SOAP Performance for Scientific Computing,”Proceedings of The Eleventh International Symposium onHigh Performance Distributed Computing, IEEE Com-puter Society Press, pp. 246-254, Edinburgh, Scotland,23-26 July, 2002.

[4] Larmouth J., “ASN.1 Complete,” http://www.oss.com/asn1/bookreg.html.

[5] Stutz D., “The Microsoft Shared Source CLI Im-plementation,” Microsoft Corporation, March 2002,http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Dndotnet/html/mssharsourcecli.asp.

[6] Booth D., Haas H., McCabe F., Newcomer E., Cham-pion M., Ferris C., Orchard D., “Web Services Archi-tecture,” W3C Working Draft 8 August 2003, http://www.w3.org/TR/ws-arch/.

[7] Fielding R. T., “Architectural Styles and the De-sign of Network-based Software Architectures,” PhDdissertation, University of California, Irvine, 2000,http://www.ics.uci.edu/˜fielding/pubs/dissertation/fielding\_dissertation.pdf.

[8] van Engelen R. A., “gSOAP Documentation,” Depart-ment of Computer Science and School of Computa-tional Science and Information Technology Florida StateUniversity, Tallahassee, FL 32306-4530 http://www.cs.fsu.edu/˜engelen/soap.html.

[9] “Common Language Infrastructure – CLI”, Ecma Inter-national, http://www.ecma-international.org/publications/standards/ecma-335.htm.