Authors:
Sven De Labey
and
Eric Steegmans
Affiliation:
University of Leuven, Belgium
Keyword(s):
Service-Oriented Computing, OSGi, Object-Oriented Programming, Language Extension.
Related
Ontology
Subjects/Areas/Topics:
Communication and Software Technologies and Architectures
;
e-Business
;
Enterprise Information Systems
;
Languages, Tools and Architectures
;
Model-Driven Software Development
;
Service-Oriented Architectures
;
Service-Oriented Software Engineering and Management
;
Software and Systems Development Methodologies
;
Software Engineering
;
Technology Platforms
Abstract:
The Open Services Gateway initiative (OSGi) is a successful attempt to bridge the gap between Java and Service Oriented Computing. OSGi provides an LDAP-based query language for fine-tuning service retrieval and offers an eventing mechanism that signals changes to a service’s lifecyle to all clients depending on that service. Nonetheless, a number of challenges remain unsolved. OSGi’s service query language, for instance, bypasses important compile-time guarantees on the syntactical correctness of queries and the language works only for properties that never change during the lifetime of a service. What programmers need, however, is a statically type-checked, robust query language that takes into account dynamically evolving, volatile service characteristics. A second problem is that the lifecycle management system requires programmers to write a considerable amount of boilerplate logic for reacting to service events. This obfuscates the business logic, which in turn decreases code c
omprehension and increases the odds for introducings bugs when implementing client-service interactions. This paper evaluates OSGi as a platform for programming client-service interactions in Java. After focusing on a number of shortcomings of OSGi’s integrated service query language and its lifecycle management system, we propose a solution based on a programming language extension. After the conceptual definition of these new language concepts, we show how they can be transformed to regular Java code without losing interoperability with the OSGi standard.
(More)