Improving the Performance of Web Services by Dynamic Object Offloading Carmine Sementa, Quirino Zagarese

Ali Khajeh-Hosseini

Pasquale Cantiello

University of Sannio Department of Engineering Benevento, Italy {csementa, quirino.zagarese}@unisannio.it

University of St Andrews School of Computer Science St Andrews, UK [email protected]

Second University of Naples Naples, Italy [email protected]

I.

INTRODUCTION

As far as communication for distributed applications in heterogeneous environments is concerned, the introduction of Web Services, dating back a decade, was a turning point finally allowing businesses to comply with a set of wellknown standardized protocols. On the other hand, the inherent verbosity of XML has inhibited businesses from wide adoption in environments that deal with complex business objects, where performance matters. XML complexity is in fact one of the most important factors for performance of Web Services, and keeping XML payloads small and simple, and shunning their deep nesting play a key role among the best practices in this area. Web Services perform strictly depending on size and complexity of XML; complex payloads require more processing and memory for parsing. In addition, serialization and deserialization is needed on the server and client. Past attempts have tried to alleviate the influence of XML processing on systems performance, whether they be databases, Web Services or messaging platforms. XOP [1] states a way to inject binary data into an XML document to keep the parser from misinterpreting the resulting envelope, and it takes into account the efficiency needs as binary data do not go through a serialization. Besides general compression techniques for XML payload provided by gzip encoding over HTTP protocol, XMill [2] can take advantage of the peculiar structure of XML so efficiently that data expressed in domain-specific formats end up to enjoy a higher compression rate when previously turned into XML. Inflatable trees [4] offer an effective representation of XML supporting lazy construction of a document in memory based on the possibility of having portions of it stored into binary form, up to fivefold terser than in traditional ways. These portions get inflated transparently to client by runtime whenever it requires traversing them. Despite these and other modern techniques being widely applied to Web Services stack implementations, the prominence of XML in inefficiency is still steep and substantially unaddressed when dealing with business domains characterized by objects carrying hundreds of interrelated entities to be transferred. As expected, this brings up large XML payloads further exacerbated by deep nesting levels. On the other hand, interface granularity is limited by the business domain that the Web Service is being designed for, which presents the following trade-off: the number of messages exchanged vs. the average amount of data in a message. Even though this looks like a simple trade-off, it cannot be balanced in a generic way since a strategy that works for one web service might not work for other web services. In this work we suggest a new approach to Web Services performance enhancement. Our approach is focused on

two main aspects: keeping exchanged data and generated messages as low as possible. As previously mentioned, there is no general static way to achieve this goal, so we adopt a dynamic strategy based on client profiling and on a predictive model. With a service operation returning large objects, we would want to transfer only what the client will actually use. For this purpose, we keep track of the effective accesses to objects’ properties each client does. This way, we can profile each individual client and operation. At the same time, we can estimate the intrinsic cohesion between different entities inside the same business object. In addition we try to relieve a Web Service of the necessary XML processing and transferring by offloading part of them to a specific purpose component. II.

ARCHITECTURE

In an SOA environment, where services are implemented as Simple Object Access Protocol (SOAP) Web Services [5], it is common for some enterprises to deal with large XML documents. In such contexts, we can introduce offloading by splitting XML documents into lazily and eagerly loaded parts. Clients receive only the eagerly loaded part, but can still explore the rest of the document by requesting it from an alternative source as soon as they need it. If the mentioned services involve complex business objects, offloading can lead to good performance improvements, in terms of savings in data and message exchanges. Finding a good offloading strategy can be challenging because different users, as well as different use cases, may generate statically unpredictable accesses to objects’ properties. Dynamism, hence, can be a key concept for an effective offloading strategy design. Our solution evaluates the actual way clients access business objects properties, in order to adapt object offloading. There are four key situations to be evaluated: (a) client accessed an eagerly loaded property of the object; (b) client accessed a lazily loaded property of the object; (c) client did not access a lazily loaded property of the object; (d) client did not access an eagerly loaded property of the object. The (a) and (c) cases reflect good situations, as the system could reach an ideal point predicting the actual access of the object properties so that neither any data-miss is issued nor any data pre-fetching is wasted. The (b) and (d) cases concern negative situations; the former takes place whenever a client tries to access properties that have not been loaded yet; the latter takes place every time the client does not use properties loaded from the server. In our architecture, this information is stored in a Knowledge Base component (KB) that can be queried in order to apply dynamic offloading. We keep our architecture transparent to service designers, by employing a Service Interceptor component. For this purpose, [3] introduced a stan-

dard approach to handle incoming and outgoing messages. Handlers can access message contexts and modify both SOAP headers and contents. Figure 1 describes our architecture in detail. Thick-bordered components extend a plain client-server architecture based on Web Services. When a client application invokes a service (number 1 on the diagram), Service Interceptor handles the response message and queries the KB (2, 3) in order to decide which part of the resulting XML is kept for later lazy accesses (4) and which one gets serialized back to the client, along with a service invocation identifier (5). The former part is then managed by the Lazy Data Access Service (LDAS) which associates the invocation identifier to any XML fragments that may be lazily accessed. LDAS behaves like a dictionary where entry keys consist of InvocationID-ObjectPropertyName pairs and entry values are the corresponding XML fragments. Once the client application receives the object resulting from service invocation, it may access its relationships to other objects. In our architecture such accesses are managed through a clientside component named Data Access Layer (DAL) that hides the actual relationships loading strategy. If the client application accesses an eagerly loaded relationship, DAL will keep track of the access, return the requested entity and update the KB attaching collected data to future services invocations. In the other case, DAL will raise a request containing the InvocationID and the needed ObjectPropertyName to LDAS (6), which in turn will update the KB (7, 8) and return the needed entity to the client application. III.

ENTITIES AFFINITY MODEL

Since we are basing our approach on a probabilistic model, we need to define some key points. Given a class C and a composed property (i.e. non-literal) xP of it belonging to a class P, a C instance is xP-marked if that property is being accessed at least once. The probability for a property xP, defined on C, of being used by a client is: P C.x =

# of x −markedinstances of C

P

P

# of instances of C

This would describe the semantic strength of the xP relationship between C and P, that is the likelihood that, given an entity of C class, its xP is being traversed. Considering that a web service is a set of exposed functionalities, each of which has its own semantic, we may argue that how a client handles a particular item depends on the server functionality having generated such item as part of its response. In other words, it makes sense to expect that client applications invoking different methods may use the same kind of returned

Figure 2. Probability-based clusters for simple business object object in different ways. This is why we need to define, given an instance of C returned by functionality F, the conditional probability for xP of being used as P(C.xP|F) = σfunct=F(P(C.xP)). Such a probability is kept by the KB based on feedback from the client. The structure that can be used to model the KB is a standard graph where nodes represent the entity involved and edges map the relationships between entities. The edges are weighted as P(A.xB|F) and the weight represents the affinity between entities. Since we need to model the functionalities, we need a graph structure for each of them. A threshold level is also needed: we assume it to be fixed at present (at a system level or at a functionality level). The graph in Figure 2 shows a toy sample of business object described through four entities with the weights on the edges. Let us assume a 0.5 value as threshold. In such a case, invocation of F would immediately return C items along with A ones (since affinity between A and B is under the threshold level), while B and D ones would get available for lazy access. Should client later require B, D would get serialized as well and in that case the affinity levels will be updated as well. IV.

We presented a novel approach for Web Services optimization based on dynamic offloading and affinity between entities in business objects. Although such an approach could appear as too simplistic – threshold level is assumed fixed at the moment, while it could be automatically calculated in a self-tuning environment – we believe that a model all but complicated might pay off and come out being quite effective as well as nimble, in light of success achieved in similar issues by plain solutions, e.g. policies for CPU-cache lines eviction. We expect that our application of locality goes along the way of minimizing the overhead due to the additional computation and communication necessary to maintain the KB, but we would not rule out the chance of getting it more complex by adding concepts from social network studies – modeling relations among entities as ones among people – if future experimental measures from our initial implementation hinted that doing so is needed. REFERENCES [1] [2]

[3]

[4]

[5]

Figure 1.

Interaction phases in proposed stack

CONCLUSIONS

XML-binary Optimized Packaging, W3C Recommendation 25 January 2005, http://www.w3.org/TR/xop10/ H. Liefke, D. Sucio, “XMill: an Efficient Compressor for XML Data”, in Proc. of ACM SIGMOD international conference on Management of data, pp. 153–164, 2000. JSR-000224 Java API for XML-Based Web Services 2.0, Final release from Community Development of Java Technology Specifications, http://jcp.org/aboutJava/communityprocess/final/jsr224 R. Fernandes, M. Raghavachari, “Inflatable XML processing”, in Proc. of ACM/IFIP/USENIX International Conference on Middleware, pp. 144-163, November 2005. K. Umapathy, S. Purao, “Systems Integration and Web Services”, Computer, vol. 43, no. 11, IEEE Computer Society, November 2010.