From Object-oriented Programming to Service-oriented Computing
How to Improve Interoperability by Preserving Subtyping
Diana Allam, Herv
e Grall and Jean-Claude Royer
epartement Informatique,
Ecole des Mines de Nantes, Nantes, France
Service-oriented Architecture, Object-oriented Programming, Interoperability, Loose Coupling, Subtyping.
The object-oriented paradigm is increasingly used in the implementation and the use of web services. How-
ever, the mismatch between objects and document structures in the wire has a negative impact over interoper-
ability, more particularly when subtyping is involved. In this paper, we discuss how to improve interoperability
in this context by preserving the subsumption property associated to subtyping. First we show the weaknesses
of existing web service frameworks used for serialization and deserialization. Second we propose new foun-
dations for serialization and deserialization, which leads to the specification of a new data binding between
objects and document structures, compatible with subtyping.
Web services are message-oriented systems based on
document exchanges. But the development of web
services on both client and server sides is increas-
ingly based on object-oriented implementations. This
raises the problem of impedance mismatch between
objects and tree structures in XML or JSON (L
and Meijer, 2007): it is difficult to preserve object
properties after serialization and deserialization. This
is due to the differences in the data models and the
type systems between the object-oriented paradigm
and the structural one. Such problems are currently
hidden because of restrictions imposed by the cur-
rent practice for the implementation of web services.
According to the current practice, interoperability is
achieved by twining the required interface at the client
with the provided one at the server. In that way, web
services involve a tightly coupled architecture rather
than a loosely coupled one, which contradicts the
standard approach for Service Oriented Architecture
Among the restrictions imposed in the current
practice for web services, we find subtyping, which is
useful for web service interoperability as noticed for
instance by (Carpineti and Laneve, 2006), (Lee and
Cheung, 2010) and (Kourtesis and Paraskakis, 2009).
Currently, object-oriented frameworks fail to preserve
This work has been supported by the CESSA ANR
project (see
subtyping in its object definition. However it is possi-
ble to remove this gap while considering current tech-
niques for serialization and deserialization: an extra
adaptation on the client side is then required to make
the subtype and the supertype compatible. Thus, this
solution is not consistent either with the principle of
loose coupling: the client and the server cannot be
considered as black boxes.
In order to preserve subtyping while being con-
form to the loose coupling principle, we propose
new foundations for serialization and deserialization,
based on commutative diagrams as found in category
theory (Pierce, 1991). The implementation will give
rise to a new data binding framework for the two most
common technologies for web services, RESTful and
This paper is structured as follows: in Sec. 2, we
present a general view of interoperability between a
client and a server in existing object-oriented frame-
works for RESTful and SOAP Web services. In
Sec. 3, we present two problems related to subtyping
in the case of a dynamic switching between services.
In Sec. 4, we formalize the serialization and deserial-
ization processes and provide their specification with
commutative diagrams. In Sec. 5 we conclude this pa-
per by proposing a solution to the subtyping problems
in the formal framework proposed and by stating the
position we will defend in future work.
Allam D., Grall H. and Royer J..
From Object-oriented Programming to Service-oriented Computing - How to Improve Interoperability by Preserving Subtyping.
DOI: 10.5220/0004405401690173
In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 169-173
ISBN: 978-989-8565-54-9
2013 SCITEPRESS (Science and Technology Publications, Lda.)
In this section we show how the web service inter-
operability between a client and a server is ensured
in object-oriented frameworks and how it can be im-
proved with subtyping.
A View on Document Exchanges. Based on our
observations on some frameworks and standards, like
JAX-WS, JAX-RS and Restlet, we deduce a general
common exchange process of messages for existing
object-oriented frameworks for web services. At each
side, either the client side or the server one, mes-
sages at emission and reception must cross four levels
of message types. These four levels link the object-
oriented environment to the serial environment in the
wire. Starting from the object-oriented level, we dis-
tinguish four levels:
1. Data level which refers to the input and output
types of the service operations declared at the
client (in the proxy interface) or at the server (in
the service interface)
2. Marshallable level which refers to the reification
format of Data. The marshallable message for-
mat is the essential message transformation which
makes the difference between the two web ser-
vice models: SOAP and RESTful. As SOAP is
an activity-oriented model, the marshallable mes-
sage corresponds to an activity. Thus, two types
are associated to each declared service operation.
The first type is associated to the request on the
operation, often named with the operation name,
and has as attributes the input parameters of the
operation. The other type is associated to the re-
ply which contains an attribute having the return
type of the operation. For the RESTful model,
which is resource oriented, transmitted messages
must be resources. Here, marshallable types are
equal to Data types.
3. Serializable level which refers to the type of mes-
sages ready to be serialized. These types corre-
sponds to tree types associated to the marshallable
types. In web service development practices, they
are generated from the serialization annotations
added into the marshallable types.
4. Serial level which refers to the message format
ready to be sent in the wire. Serial messages are
often represented in XML or JSON format.
Message transformations across these four levels at
the client side is illustrated in Figure 1. These four
levels appear in a symmetric way at the server side.
This figure shows the different conversions applied
on a message due to a function call f (b), where f
has type A R and b has type B, a subtype of A. The
figure distinguishes the SOAP and RESTful cases at
the marshallable level as we mentioned before. For
RESTful, the marshallable message is the data b at
emission and a data r, an instance of R, at reception.
At emission in SOAP, the marshallable message is b
instance of f
where f
is a reification format for
function calls f (b). At reception in SOAP, the mar-
shallable message is r
, an instance of f
where f
is a reification format for function results r.
Twining Development Interfaces. Building a se-
rial message from a data at emission then building a
data from the serial message at reception must lead
to an equivalent instance. Therefore, an interoper-
ability is required between the exchange levels at the
client side and at the server side, as it is defined in Fig-
ure 1. According to the current practices of web ser-
vice implementations, this interoperability is achieved
by tightly coupling the client and the server. The
object-oriented environment is associated to a struc-
tural interface expressed with Web Service Descrip-
tion Language (WSDL) or Web Application Descrip-
tion Language (WADL). Clients calling a web service
must get this structural service interface and gener-
ate locally the corresponding types. Therefore, the
declared operations at the client and the server are
equal. Consequently, for the request and the response,
the four levels for messages at the client side and the
server side respectively exactly match, defining each
time a serialization process and an inverse deserial-
ization process.
Interoperability and Subtyping. From a type-
theoretical point of view, the equality between de-
clared operations at the client and the server is not
required to ensure a correct interoperability. The pro-
vided operation by a web service could be a subtype
of the required one by the client, as recalled for in-
stance by (Seco and Caires, 2000). Hence, according
to the variance properties for subtyping, the argument
type of the required operation must be a subtype of
the argument type of the corresponding provided op-
eration; and the return type of the required operation
must be a supertype of the return type of the provided
In the following section, we aim at showing weak-
nesses in existing frameworks for serialization and de-
serialization: they fail to preserve the subsumption
Figure 1: Message transformations from object instances to serial messages and inversely at the client side.
property associated to subtyping when they respect
the loose coupling principle.
In order to test the preservation of subtyping while re-
specting the loose coupling principle, we propose a
scenario where a client can switch between two web
services related by subtyping. We assume that the
client is initially configured according to a Web Ser-
vice 1 interface. Then, this client would switch to a
Web Service 2, a compatible substitution of Web Ser-
vice 1. Switching between services having similar
roles is more and more used in dynamic environments
as in (Srirama et al., 2006) and (Zaplata et al., 2009).
The ideal case would be by doing such a switch au-
tomatically without involving any modification to the
system because a web service is replaced by a com-
patible one. That way, we ensure a perfect loose cou-
pling because no modifications are required to ensure
a correct interoperability. However, this ideal solution
is out of the scope of existing frameworks for serial-
ization and deserialization. In the following we will
show the interoperability weaknesses in this context
by considering two subtyping examples. The first ex-
ample considers subtyping on provided and required
operations. The second one considers subtyping be-
tween Data types used as input arguments.
The tests are done using Apache CXF framework
and JAXB Data Binding (the default one in CXF),
which are popular standards and can be considered
as paradigmatic. These tests consist to verify if an
emitted instance could be rebuilt at reception as an
instance of a supertype. The preservation of the dy-
namic binding (proper to object-oriented languages)
from the client side to the server side is out of our in-
terest for these tests. In order to study interoperability
in the two web service models, SOAP and RESTful,
we consider examples that can be deployed with both
Figure 2: Interoperability and subtyping between re-
quired/provided operations.
Subtyping between Provided and Required Oper-
ations. Figure 2 illustrates a view of the first exam-
ple in SOAP and RESTful. Here, the operation pro-
vided by Web Service 2 can replace the one provided
by Web Service 1 because the input type B is a subtype
of the input type A, according to the object-oriented
definition. The client always sends B instances when
calling the op service. An overview of the tests done
between Client and Web Service 2 is given in Table 1.
In this table, we note B A if B has exactly the same
attributes as A else it is noted B 6≡ A.
Table 1 shows that interoperability works per-
fectly for RESTful while it works partially for SOAP.
Subtyping between Data Types. Figure 3 illus-
trates a view of the second example in SOAP and
RESTful. Here, Web Service 2 can replace Web Ser-
vice 1 because it declares exactly the same service.
There is only one difference: Web Service 2 does not
know subtype B, which is an implementation detail.
We consider that the client sends B instances when
calling the op service operation. Table 2 shows an
overview of the tests done between Client and Web
Service 2. In this table, a type is called external when
its instances can be exposed to the external world.
Thus, they can be serialized according to specific se-
rialization annotations for this type. Otherwise, the
type is called internal. In that case, if an instance of
Table 1: Results of tests on cxf framework for the example of Figure 2.
Interoperability is preserved B A Yes Yes
B 6≡ A No Yes
Table 2: Results of test on cxf framework for the example of Figure 3.
B is an external type B A Yes No
Interoperability is preserved B 6≡ A No No
B is an internal type Yes No
Figure 3: Interoperability and subtyping over Data Types.
such a type is sent to the external world, we consider
the serialization annotation of its external supertype.
Table 2 shows that interoperability fails for REST-
ful while it works partially for SOAP.
In order to fix the subtyping issues previously pre-
sented, in this section we aim at giving a formalization
of the problem by referring to commutative diagrams.
The message exchange mechanism of Figure 1 can
be summarized as follows: in object-oriented frame-
works for web services, an emitted message is an in-
stance of a marshallable type. It will be transformed
to a serializable message which is then serialized into
a serial message to be transmitted in the wire. At re-
ception, the serial message is deserialized into a se-
rializable message which is transformed into an in-
stance of the expected marshallable type. This mech-
anism can be formalized in a diagram by defining two
categories, a functor and some transformations in or-
der to go from one category to another:
1. Category of Marshallable Types: this category
contains marshallable types as points and typed
functions as arrows,
Figure 4: Fundamental Diagram for Serialization and Dese-
2. Category of Serializable Types: this category
contains serializable types as points and typed
functions as arrows,
3. Binding Functor: a mapping from marshallable
types to serializable types, extended to arrows,
4. Transformations: converting a message from a
marshallable type to a serializable type is achieved
by a serialization transformation. Inversely, con-
verting a message from a serializable type to a
marshallable type is achieved by a deserialization
In such a formalization, we consider that it is use-
less to specify a category for serial types because se-
rializable messages essentially are trees, which are
fully serializable: by using a depth-first traversal and
a parenthesis notation, we can convert a tree into a se-
rial data and by using the inverse function, come back
to the original tree.
In Figure 4, we illustrate our formalization by con-
sidering that an instance of type B must be sent to a
destination waiting an instance of supertype A. Two
marshallable types, M
and M
, are associated re-
spectively to A and B according to the definition given
in Figure 1. These two marshallable types are re-
lated by an embedding i which allows to convert an
instance of type M
into an instance of type M
, due
to the subtyping relation between A and B. The bind-
ing functor F allows two serializable types, F(M
and F(M
), to be associated to M
and M
tively. These two serializable types are related by the
corresponding embedding F(i) that allows to convert
any instance in F(M
) into F(M
). In order to con-
vert messages between categories, two serialization
transformations, s
and s
, transform the instances
of M
and M
to their respective serializable forms
in F(M
) and F(M
). Likewise, two deserialization
transformations, d
and d
, transform the instances
of F(M
) and F(M
) to their respective marshallable
forms in M
and M
In a diagram like this, what properties can we as-
sume? First, it is natural to specify that the composi-
tion of the serialization transformation with the dese-
rialization transformation produces the identity trans-
formation, modulo a natural equivalence over mar-
shallable types asserting that two objects are equiv-
alent if their serialization is equal. Second, the dia-
gram in Figure 4 may be commutative: all paths with
the same source and target define by composition the
same function, modulo the natural equivalence over
marshallable types.
Actually, these two assumptions are fundamental
to solve the subtyping issues previously described as
we will discuss in the next section.
In both examples described in Figures 2 and 3, the
whole process is described by finding a path join-
ing M
to M
by crossing the category of serializ-
able types. Actually, the path that causes problems is:
) F(M
) M
. The trouble comes
from an erroneous conversion function from F(M
to F(M
), namely F(i) : F(M
) F(M
). It is con-
sidered as equal to the identity function, which is a
violation of the commutativity property. With this
value, the composition of the different functions over
the path is not well-defined in some cases, which gen-
erates the errors observed. But with the commutativ-
ity assumption, the problem can be tackled. Indeed,
the conversion function can be easily computed:
F(i) = d
It is obtained by composing the deserialization trans-
formation with the embedding function and finally the
serialization transformation.
Practically, F(i) corresponds to a projection and
possibly a renaming for the serializable structures.
For instance, assume that type A has one serializ-
able attribute x, while its subtype B has another se-
rializable attribute y. An instance of F(M
) could be
represented by the structure B(x(val
), y(val
)) (using
a parenthesis notation) while an instance of F(M
could be represented by the structure A(x(val
Then the conversion function F(i) renames the mes-
sage root element from B to A and projects the couple
of values (x, y) into x. Finally, the conversion function
F(i) can be integrated in the framework for serializa-
tion and deserialization at reception on both client and
server sides, in a fully transparent way, which satisfies
the loose coupling principle: this solution does not re-
quire any extra adaptation on the client side when a
switch is done between compatible services.
Finally, it turns out that the diagram, when as-
sumed commutative, could become a well-founded
specification for serialization and deserialization. Its
implementation could lead to the definition of a new
data binding between marshallable types and serializ-
able types, preserving the subsumption property asso-
ciated to subtyping, and therefore improving interop-
Carpineti, S. and Laneve, C. (2006). A basic contract lan-
guage for web services. In Programming Languages
and Systems, 15th European Symposium on Program-
ming (ESOP), volume 3924 of LNCS, pages 197–213.
Kourtesis, D. and Paraskakis, I. (2009). Semantic Enter-
prise Application Integration for Business Processes:
Service-Oriented Frameworks, chapter IV. Business
Science Reference, Hersley.
ammel, R. and Meijer, E. (2007). Revealing the x/o
impedance mismatch: changing lead into gold. In
Proceedings of the 2006 international conference on
Datatype-generic programming, SSDGP’06, pages
285–367, Berlin, Heidelberg. Springer-Verlag.
Lee, T. Y. L. and Cheung, D. W. (2010). Formal models
and algorithms for XML data interoperability. JCSE,
Pierce, B. C. (1991). Basic Category Theory for Com-
puter Scientists (Foundations of Computing). The
MIT Press, 1 edition.
Seco, J. C. and Caires, L. (2000). A basic model of typed
components. In ECOOP, pages 108–128.
Srirama, S. N., Jarke, M., and Prinz, W. (2006). Mobile web
service provisioning. Advanced International Confer-
ence on Telecommunications / Internet and Web Ap-
plications and Services, International Conference on,
Zaplata, S., Dreiling, V., and Lamersdorf, W. (2009). Re-
alizing mobile web services for dynamic applications.
In Godart, C., Gronau, N., Sharma, S., and Canals, G.,
editors, Proceedings of the 9th IFIP Conference on e-
Business, e-Services, and e-Society (I3E 2009), pages
240–254. Springer.