Abstract:The Open Services Gateway initiative (OSGi) is a platform for service-oriented ... processor translates this domain-specific language to Java, as such remaining ..... Listing 6, for instance, declares a unification variable buy of type Item.
Language-Integrated Event Notification for OSGi Services Sven De Labey, Jeroen Boydens, Eric Steegmans K.U.Leuven, Dept. of Computer Science Celestijnenlaan 200A B3000 Leuven, Belgium {svendl,jeroen,eric}@cs.kuleuven.be Abstract:The Open Services Gateway initiative (OSGi) is a platform for service-oriented computing in Java with support for managing service dependencies among installed bundles (i.e. application components). An important aspect of OSGi is event notification. OSGi introduces a specialized approach, called the Whiteboard pattern, to integrate event notification in a volatile services environment. But this mechanism strongly deviates from the Java programming model because it bypasses important compile-time guarantees. Furthermore, the limited expressiveness of its event constraint language makes it impossible to detect composite events, and it leads to the notification of unsollicited events. In this paper, we propose a domain specific language that allows programmers to define events in a way that maximizes compile-time guarantees on event definitions and on the actions to be taken when these events arise. This extension not only raises the level of abstraction for event publication, but it also supports the detection of composite events. During the transformation of our DSL to Java, all technical interactions are injected, based on information that programmers provide by means of our new language constructs. The resulting application remains compatible with OSGi.
1 Introduction Object-Oriented programming languages such as Java are increasingly adopting the paradigm of Service-Oriented Computing [Pap03]. One of the most popular SOA adopters is the Open Services Gateway initiative [Ope]. OSGi technology provides a service-oriented, componentbased environment and offers standardized ways to manage the software lifecycle [OSG04]. It subscribes to the publish-find-bind model by providing a central service registry which is used by bundles (i.e. application components) to publish their services along with relevant metadata. OSGi also provides functionality for signalling and reacting to events. An OSGi PrinterService, for instance, may signal events when it starts printing a file. The OSGi framework itself also sends lifecycle events, when bundles are installed or removed, or when services are added to the registry [Ope]. While sending events in OSGi is relatively easy, registering an event handler to react to the proper event notifications remains very hard [CF02, AOS06]. The expressiveness of the LDAP constraint language is not only very weak, but these queries also bypass important compile-time guarantees on the syntactic correctness of the constraints. Additionally, programmers are forced to write a considerable amount of OSGi-specific boilerplate code for creating and registering event listeners. And this code bypasses compile-time guarantees as well. Another problem is that the LDAPbased event constraint language cannot handle composite events, i.e. combinations of events.
In this paper, we propose a domain specific language that (1) increases the expressiveness of OSGi’s event constraint language, (2) enables the compiler to verify the correctness of event constraints and (3) allows programmers to specify event patterns by integrating support for composite event detection directly in the OSGi runtime system. The resulting language significantly increases the level of abstraction by removing all boilerplate logic from the source code. Our preprocessor translates this domain-specific language to Java, as such remaining compatible with the OSGi specification. This paper is structured as follows. Section 2 provides an evaluation of OSGi and event notification. Sections 3 and 4 present a language-integrated solution for the weaknesses detected in the evaluation. Section 5 shows how this language extension is transformed to OSGi compatible Java code. Section 6 presents related work and Section 7 concludes.
2 OSGi and Event Notification In this section, we provide an overview of the OSGi programming model. Section 2.1 introduces the most important components of the OSGi services architecture and Section 2.2 explains how events can be notified. Our evaluation of this approach is presented in Section 2.3. 2.1 The OSGi Programming Model OSGi can be seen as a platform for running service-oriented Java applications. Such applications are installed as bundles in OSGi. A bundle is a physical jar file with an OSGi-specific manifest header which indicates the class that acts as the bundle activator. This activator serves as the entry point for an OSGi application. When a bundle is started in the OSGi runtime, the activator class is given control. The activator typically needs to interact with the OSGi framework to register or retrieve services. To do so, it uses its BundleContext reference, which is injected into the activator upon bundle activation. This BundleContext can be seen as a facade that provides access to relevant framework functionality. It can also be used for signalling events and for registering event handlers, as discussed next.
(a) OSGi Whiteboard Pattern
(b) Constrained Event Notification
Figure 1: Event Notification in OSGi
2.2 OSGi and Event Notification This section focuses on how bundles can register event handlers in order to react to events that are sent by other bundles, or by the OSGi framework itself. Two roles are important: the event handler and subject. Interactions between both are mediated by the OSGi EventAdmin service.
Event Handler. An EventHandler is a service registered by a bundle in order to react to an event. It must implement the handleEvent(Event ev) method that will be called by the OSGi framework when events occur. Event handlers are registered as services via the BundleContext reference of the registering bundle. This is shown in steps 1–2 in Fig. 1(b). Evidently, an EventHandler is not interested in all events that occur in the services architecture, and therefore needs a way to filter the set of events being signalled. This is done by registering constraints along with the EventHandler. Listing 1 shows how a topic (line 3) and a filter (line 4) are added to an ItemTracker event handler (lines 5–7). The topic constraint is used to indicate that only events sent on that topic are sollicited. The filter expression further finetunes event notification by constraining the values of event-specific keys, such as type and price. 1 2 3 4 5 6 7 8 9
public void start(BundleContext bundleContext){ ItemTracker tracker = new ItemTracker(); String topic = "org/osgi/service/Item"; String filter = "(&(type=sold)(price>1000))"; Dictionary dict = new Hashtable(); dict.put(EventConstants.EVENT_TOPICS,topics); dict.put(EventConstants.EVENT_FILTER,filter); bundleContext.registerService("EventHandler.class",tracker,dict); } Listing 1: Registration of a constrained EventHandler
Subject. A bundle that publishes events is called an event source or a subject. Each event typically contains metadata to finetune event notification. The Item event, for instance, contains information about the type of the event, and the price of the Item. Listing 2 shows how this metadata is added to the event (lines 2–5), whereas Listing 1 shows how constraints are defined by referring to these metadata properties. Subjects willing to publish events use their BundleContext reference to search for the OSGi EventAdmin service. This is shown in steps 3–4 in Figure 1(b). The EventAdmin then matches the metadata of the event with the constraints (topic and filter) of all the registered event handlers, as depicted in steps 5–6 in Figure 1(b). This decoupled way of notifying handlers about events, where a central EventAdmin is responsible for the technical wiring between subjects and handlers, is called the OSGi Whiteboard pattern [OSG04]. 1 2 3 4 5
public void start(BundleContext bundleContext){ Dictionary metadata = new Hashtable(); metadata.add("price",1500); metadata.add("type","sold"); Event event = new Event("org/osgi/service/Item",metadata);
6
String adminName=EventAdmin.class.getName(); ServiceReference sr = bundleContext.getServiceReference(adminName); EventAdmin admin = (EventAdmin)bundleContext.getService(sr); admin.sendEvent(event);
7 8 9 10 11
} Listing 2: Creating and sending events using the EventAdmin
2.3 Problem Statement In this section, we identify three key problems regarding the event notification system of OSGi, which we evaluate from the viewpoint of programming language development. The remainder of the text then focuses on a solution to these problems. Compile-time guarantees. The approach of integrating metadata and LDAP constraints bypasses compile-time guarantees, which forces programmers to handle errors at runtime that should have been detected at compile time: • Metadata. Key-value pairs are added as tuples of String and Object. The compiler cannot check the key for syntax errors and it cannot guarantee that keys and values are type compatible. The erroneous pair “(color,20)” can be added to an event and this will not even be signalled as a runtime error. • Constraints. LDAP is written in a String. Syntax errors in LDAP constraints, such as unmatching parentheses, are not detected. Neither is the use of non-existing boolean operators for composite constraints. The lack of support for compile-time error detection means the error is signalled only at runtime, by means of an InvalidSyntaxException. This is in strong contrast with regular Java expressions, for which the compiler can detect syntax errors and type conflicts, as such reducing problems when the system is operational. Limited Expressiveness. Once the LDAP query is uploaded to the service registry, it can no longer be modified. Consequently, LDAP constraints can only refer to service properties that never change during the lifetime of the service, i.e. static service properties. The EventAdmin fails to support queries that constrain dynamic or derived properties. An example of a dynamic property is the queue length of a PrinterService, which is modified when jobs arrive and get processed. Derived properties, then, require client input to evaluate a function, the result of which serves as the value for that property. The cost for printing a file, for instance, is derived from information about that file. These types of properties cannot be used in LDAP queries because they cannot be registered as key-value pairs in the Event instance. By only supporting static properties, the OSGi mechanism is unable to expressively filter events, leading to a large number of unsollicited notifications. Event handlers must discard these events, even though they should never have been delivered in the first place. Complex Event Processing. Bundles may be interested in patterns among events, rather than events themselves. This requires a mechanism that supports complex event detection by correlating event occurrences. The problem with OSGi’s event notification mechanism is that event handlers are wired to specific events. They cannot specify their interest in event patterns. Consequently, programmers become responsible for creating data structures and algorithms that detect the composite event based on notifications of atomic events that are detected by their event handler. This further drives down the level of abstraction, and it significantly reduces the readability of the code due to the interweaving of technical code with the business logic. Section 3 tackles the first two problems by introducing a domain-specific language for defining events and their handlers. Section 4 further develops these language constructs and integrates support for complex event detection.
3 Language-Integrated Atomic Event Notification This section introduces a domain-specific language extension that aims at (1) fostering compiletime guarantees for both subjects and their event handlers, (2) improving the expressiveness of event constraints and (3) increasing the level of abstraction so as to exonerate programmers from implementing boilerplate code. We first look at the subject side (Section 3.1) and then show how event handlers are integrated in our language extension (Section 3.2). public interface Item{ /∗ events that can be published by all Item services ∗/ public event Sold{ private final double price; public Sold(double price){ this.price=price; } public double getPrice(){ return this.price; } } public event Bought{ /∗ event body omitted ∗/ }
1 2 3 4 5 6 7 8 9
/∗ regular Java interfaces methods ∗/ void sell();
10 11 12
} Listing 3: Event definitions are directly integrated into the service interface
3.1 Atomic Event Definition and Publication. One of the problems of OSGi event notification is the invisibility of events: there is no standardized way for event handlers to find out what events a subject fires. Our language extension makes events visible by directly integrating them in the service interface. Listing 3 shows how a Sold event is integrated into the Item service interface. All subjects implementing this interface can publish this Sold event. Similar to Java classes, events may introduce abstract methods, thus forcing concrete classes to provide an implementation for these event methods. 1 2 3 4 5 6
public class Flight implements Item{ public void sell(){ //sell item at new Item.Sold(price).publish(); } } Listing 4: The publish() operation fosters event publication transparency
3.1.1 Atomic Event Publication. Similar to normal Java classes, all types that are declared with the event qualifier, such as Item.Sold, inherit from a common base class that offers general-purpose methods 1. A method getSource() allows to retrieve the subject, whereas getOccurrenceTime() returns the event’s publication time. The most important operation, accessible to all events, is publish(), which is illustrated in Listing 4. This operation signals the event to all event handlers that registered their interest in this event type. Contrary to OSGi, access to the BundleContext and retrieval of an EventAdmin are no longer necessary. Programmers simply indicate when an event must be fired, leaving all technical details to our preprocessing tool (see Section 5).
3.2 Language-integrated Handlers for Atomic Events OSGi requires event handlers to be registered in the OSGi registry. This forces programmers to interact with the BundleContext, providing information that (1) is insufficiently expressive and (2) circumvents compile-time guarantees. This in turn leads to large amounts of unsollicited events. We solve these problems by introducing specialized language constructs for event handlers. Rather than filtering events using LDAP constraints, our language supports event filters based on (1) the subject that sends them and (2) the event type and its characteristics. The language constructs are shown in Listing 5 on lines 1–7, but due to space constraints, we explain them by means of an example, as shown on lines 9–16: 1 2 3 4 5 6 7
class Monitor{ // -- Language Concepts, Definition observe(subject type) where(subject constraint){ on(event expression) where (event constraint){ reaction } } }
8 9 10 11 12 13 14 15 16
class Monitor{ // -- Language Concepts, Example observe(Item item) where(this.getStoredItems().contains(item)){ on(Item.Sold sale) where(sale.getPrice()>3000){ Logger.archive("We sold an item for " + sale.getPrice()); } on(...) //other events can be handled here. } } Listing 5: Defining event expressions and event constraints
• Subject. The observe() clause is introduced to indicate the type of the subject that the event handler wants to track. Line 10 in Listing 5 indicates that the handler is willing to listen 1 This
is similar to Java, where all classes inherit from a common base class, Object, which provides general-purpose methods such as equals and hashcode. These methods are also available to events.
to events sent by services of type Item. An accompanying where clause is used to further constrain this subject. In our example, the item must be contained in a list maintained by the event handler (see this.getStoredItems().contains(item) on line 10). • Event. The on() clause further specifies what types of events are sollicited from the subjects that satisfy the observe clause. Another where clause may be attached to the on clause to further finetune notification by means of a boolean constraint. Line 11 in Listing 5 shows an event handler solliciting Item.Sold events with a selling price of more than 3000. The event handler can retrieve event-specific information from signalled events by means of the sale variable. Comparison. Figure 2 compares our event filtering strategy with OSGi’s LDAP constraints. Three subjects, s1 , s2 and s3 implement the same service interface S , but they publish different event types, numbered e 1 through e 4 . Assume the event handler is only interested in e 1 and e4 from subject s2 . In other words, events shaded in gray are unsollicited. In LDAP, these events would be represented by instances of Event with different metadata properties attached to them. Figure 2(a) shows how an LDAP filter attempts to filter these events based on (1) the subject type and (2) on event-specific properties. Even in a best-case scenario, where the LDAP constraint is able to weed out uninteresting events e 2 and e3 , a lot of notifications would still be unsollicited. This is because the mechanism cannot sufficiently constrain the origin of an event: handlers cannot rule out s 1 and s3 using LDAP filters. They can refuse event types other than S , but they cannot filter based on instances of S . Worse, all events must be handled by the same method, handleEvent. This monolithic method decreases code comprehensibility and it becomes very hard to understand which reaction relates to which event type.
(a) LDAP-based Event Filter
(b) Language-Integrated Event Filters
Figure 2: Expressive language-integrated filters minimize unsollicited event notification
Our approach, on the other hand, allows to filter based on subject instances rather than subject types using the observe clause. Events from this subject are then represented by means of fully qualified types, such as Item.Sold in the on clause. These two different filters are installed following the design of the Pipes and Filters pattern [HW03]. Their collaboration is depicted in Figure 2(b): the subject filter blocks all events that were fired by subjects other than s 2 , whereas the event filter routes sollicited events from s 2 directly to their event handler. Each handler specializes in reacting to one type of event. Contrary to LDAP constraints, our subject and event constraints are directly integrated into the programming language, thus benefitting from maximal
compile-time guarantees. Another advantage is that all boilerplate code has been removed from the source code: event handlers are automatically registered in OSGi, as discussed in more detail in Section 5, which covers runtime aspects and the translation to Java.
4 Language-Integrated Composite Event Notification Composite events are structural combinations of atomic events and/or other composite events (in the case of recursive composition). This requires an event detection algorithm, which is currently not integrated in OSGi’s EventAdmin class. This section first introduces an event composition language that is integrated as a statically typed sublanguage in our DSL (Section 4.1). This language is then used by subjects to define composite events based on atomic events (Section 4.2) and by observers to define event patterns.
4.1 Event Composition Language. Composite events combine events with composition operators, thus creating the need for an event composition language. We define a sublanguage, embedded in our DSL, that allows to define such event compositions in OSGi. This is a sublanguage because its expressions may only appear inside the on clause, which was introduced in Section 3.2. This strategy keeps the event composition sublanguage completely independent of Java. The advantages of this separation strategy are (1) that the Java grammar definition is not polluted with composition operators and (2) that the composition language can easily be extended and tailored to the needs of specialized event handlers.
Figure 3: Composite events are defined as structural combinations of other events
In this paper, we focus on five composition operators which closely follow the syntax of the Java programming language. Examples of composite events, defined by means of these operators, are shown in Figure 3, where a downward pointing arrow depicts the detection and notification of the composite event: • Conjunction. The conjunctive operator “&&” is used to specify that a composite event, A&&B, occurs when both A and B have been detected. • Disjunction. This operator, denoted “||” is used to indicate that a composite event A||E occurs when either A or E is detected. • Sequence. The operator “->” indicates that a composite event A->C is fired when A is
followed by C. Other events, such as B in Figure 3, may be signalled between A and C without cancelling the detection of the composite event. • Repetition. The operator “[n]”, where n is a non-negative integer, is used to indicate that a composite event, such as C[3] is fired when an event C occurs 3 times. • Omission. The operator “!(...)” is used to indicate that an event !E(A->D) is fired when E is not fired during the detection of A->D. Event type E is also called the cancelling edge in the event graph A->D.
1 2 3 4 5 6
public event Profit{ public double amount; public Profit(double amt){ this.amount=amt; } }
7 8 9 10
observe(this){ Item.Bought buy where buy.getPrice()>3000; Item.Sold sale;
11
on(buy->sale) where(buy.getPrice() < sale.getPrice()){ new Profit(sale.getPrice()-buy.getPrice()).publish(); }
12 13 14 15
} Listing 6: Composite events are defined in the on clause
Language-integrated event composition enables our preprocessor to detect syntax and typing errors in event compositions. This approach also raises the level of abstraction because programmers can declaratively specify the composite event, leaving the injection of all the technical code to our preprocessor.
4.2 Composite Event Definition, Publication and Reaction Listing 6 shows how a composite event Profit is fired when an Item.Bought event is followed by an ItemSold event. This composition is specified in the on clause. Our domain-specific language is extended with two new constructs: • Constrained Unification Variables. These variables are specialized variables that play an important role in the detection process of composite events. Constrained unification variables (CUV) are matched with events that occur in the OSGi runtime. Line 9 in Listing 6, for instance, declares a unification variable buy of type Item.Bought. This CUV is matched with Item.Bought events signalled by the subject itself (as required by observe(this) on line 8). Note also that this variable is constrained: it contains a where
clause that imposes additional constraints on events. Unification only succeeds if three rules are satisfied: (1) the subject matches the observe clause, (2) the event type matches the CUV type and (3) the event instance satisfies the where clause. • Composite Event Specification. The specification of the composite event is isolated in the on clause, which is the only place where our event composition sublanguage is supported. Such a specification relates to the constrained unification variables, buy and sale, declared on lines 9–10 in Listing 6. If these variables are matched by event occurrences according to the specification buy->sale, and if the accompanying where clause on line 12 is satisfied at the moment of the detection, then the reactive part (line 13) is executed. This triggers the creation and publication of a new Profit event. Composite Event Handling. It is easy to see that the language constructs of Listing 6 are general enough to be used for event handlers as well. Event handlers can define their own event patterns in the on clause. But rather than signalling a composite event when the pattern is detected, these handlers will take other actions, such as the logging action shown on line 12 in Listing 5.
5 Implementation and Translation to Java First, we explain how our DSL is translated to Java (Section 5.1). Then, we show how this Java code is integrated with the OSGi framework (Section 5.2).
5.1 Translating Language Constructs to Java We have formally defined the grammar of our domain-specific language. This grammar is fed to ANTLR [Ash], which is a tool that generates (1) a lexer and (2) a parser. The parser turns applications written in our DSL into abstract syntax trees (AST). These ASTs are in turn transformed into instances of our DSL metamodel. A metamodel contains semantic information that is not readily available in an AST, as such easing the transformation. The DSL metamodel instance is subsequently transformed to the Java metamodel. During this step, our language constructs are transformed to Java classes that follow the Pipes and Filters design pattern [HW03]. This Java metamodel is written out as Java code, which can be compiled by the Java compiler. The compiled application can then be installed as an OSGi bundle because our approach does not violate compatibility with OSGi. In order to maintain a high level of abstraction, we have modelled the entire transformation and compilation as a black box, consuming source code written in our DSL and producing Java bytecode.
5.2 OSGi Runtime Integration We discuss OSGi integration by means of Figure 4, which shows an event handler that signals a composite event Profit when an Item.Bought event is followed by an Item.Sold event. The
Figure 4: Events sent by EventAdmin are sent to a series of interconnected filters.
OSGi EventAdmin distributes event notifications, that are sent to a series of connected filters. The first filter is a subject filter. As required by observe(this), this subject filter only allows events sent by the subject itself to pass through. Assuming that four types of events can be signalled (Moved, Bought, Sold, and Lost), the event filter then blocks Moved and Lost events since these are not sollicited in order to detect the composite event. Events of type Sold are also blocked at this point because the buy->sale specification is not interested in Item.Sold: Figure 4 shows that the Sold gate is opened only when a Bought event is signalled. Events that satisfy the type constraint are passed to the third filter, which checks the where clause of the constrained unification variables buy and sale. Events that pass this third filter are injected in the event graph that represents the composite event definition buy->sale. This graph is traversed as events are signalled, and when it reaches a sink, the next filter is activated. This filter represents the where expression that further constrains the on clause. If that condition is satisfied, then the EventAdmin is called to signal the Profit event.
6 Related Work The Observer pattern [Gam95] is the pattern on which the OSGi Whiteboard pattern [OSG04] is based. Bosch [Bos98] proposes LayOM, a layered object model that integrates events directly into a programming language. Layers intercept method calls so as to enable pre- and postprocessing, such as event notification. The main goal of LayOM is to increase the visibility of events. Other problems, such as the monolithic handleEvent method are not solved. Moreover, events are modelled as strings, similar to OSGi event metadata, thus reducing compile-time guarantees.
Programmers are also responsible for wiring handlers to subjects, thus reducing the level of abstraction. The VetoableChangeListener and the PropertyChangeListener interfaces from the JavaBeans package [Jav98] have similar problems. Neumann and Zdun [NZ99] propose XOTcl, a language with specialized language constructs for implementing event notification based on the Observer pattern. XOTcl introduces filters, comparable to our where clause. A disadvantage is that it is impossible to listen to event series. Composite event definitions are neither supported at the subject nor at the event handler. Moreover, these handlers are still forced to write all event notification logic in a single handleEvent method. Hedin introduces language support for events based on attribute extension [Hed98]. Programmers can make their subjects and events more visible and the compiler can verify whether event notification is implemented correctly, thus increasing both traceability and verifiability. This approach resembles our approach although its expressiveness is limited: event occurrences cannot be constrained or combined, whereas our approach supports (1) subject constraints, (2) constrained unification variables and (3) constrained event composition. Riehle introduces a programming model where state changes and dependencies are modelled as first class objects in the programming language [Rie96]. The resulting system is highy flexible and can be used for dependency management between objects in an object-oriented programming language. But no compiler can guarantee whether these dependencies are wired correctly. Programmers are also required to implement a large amount of classes. The Observer-ConditionedObservable pattern [LW07] has similar problems. Nordberg introduces a more reusable version of the Observer pattern based on aspect-oriented dependency inversion [M. 01]. Dependency management between subjects and event handlers is outsourced to an aspect, which realizes event notification by means of pointcuts. This pattern resembles OSGi’s Whiteboard pattern in that it hides dependency management, but it fails to support composite event notification and its lack of support for event constraints leads to a large amount of unsollicited notifications. Bunnig et al introduce PaL TODO , a programming language that focuses on structural dependencies. It is less suited for event notification, because eventing logic is intimately related to the behaviour (i.e. the business logic) of the application. Hence, PaL can only hide dependency management between subjects and their event handlers, similar to the Whiteboard pattern. CORBA [Obj91] and WS-Notification [OAS06] are distributed alternatives to OSGi’s event notification mechanism. Early support for event notification was introduced by the CORBA Event Service [Obj04], but this specification lacks support for constraints, leading to a large number of unsollicited notifications. The problem is solved by the CORBA Notification Service [FSR03] and READY [GKP98], which introduce structured events that contain filterable body elements modelled as key-value pairs. This approach resembles OSGi’s metadata system for Event objects, but it circumvents compile-time guarantees in a similar way. Esper [Mar06] is an engine that supports a very expressive event query language, EQL, but its integration with Java introduces problems similar to the ones we pointed out in our evaluation of LDAP. The domain specific language presented in this paper resembles our previous language extensions for OSGi [De 07] and will be integrated in our event broker extension for WS-Notification to raise the level of abstraction in the domain of Web Services programming as well [DS08].
7 Conclusion OSGi’s eventing infrastructure strongly deviates from the Java programming model because it bypasses important compile-time guarantees. The limited expressiveness of LDAP constraints leads to the notification of large amounts of unsollicited events, and composite event detection is not supported. We have solved these problems by defining a domain-specific language extension for Java that allows programmers to define, publish and constrain events in a type-safe way. Our approach raises the level of abstraction because composite events are tracked automatically by the runtime system based on composite event definitions introduced by the programmer. Furthermore, this domain-specific language is translated back to Java by means of a preprocessor, and the resulting language is 100% compatible with the OSGi specification.
References [AOS06] Ahn, Heejune ; Oh, Hyukjun ; Sung, Chang O.: Towards a Reliable OSGi Framework and Applications. In: Symposium on Applied Computing, 2006 [Ash]
Ashley, A. J.: ANTLR: http://supportweb.cs.bham.ac.uk/documentation/tutorials/.
[Bos98]
Bosch, Jan: Design Patterns as Language Constructs. In: Journal of Object-Oriented Programming 11 (1998), Nr. 2, 18-32. citeseer.ist.psu.edu/bosch98design.html
[CF02]
Cervantes, H. ; Favre, J. M.: Comparing JavaBeans and OSGi Towards an Integration of two Complementary Component Models. In: Euromicro Conference on Component Based Software Engineering, 2002
[De 07]
De Labey, S. et al.: ServiceJ. A Java Extension for Programming Web Service Interactions. In: International Conference on Web Services (ICWS), 2007
[DS08]
De Labey, S. ; Steegmans, Eric: Extending WS-Notification with an Expressive Event Notification Broker. In: International Conference on Web Services (ICWS), 2008
[FSR03] Filho, Roberto S. S. ; Souza, Cleidson R. B. ; Redmiles, David F.: The design of a configurable, extensible and dynamic notification service. In: Proceedings of the 2nd international workshop on Distributed event-based systems, 2003, S. 1–8 [Gam95] Gamma, E. et al.: Design Patterns: Elements of Reusable Object Oriented Software. AddisonWesley Longman Publishing Co., Inc., 1995 [GKP98] Gruber, Robert E. ; Krishnamurthy, Balachander ; Panagos, Euthimios: High-level Constructs in the READY event notification system. In: Workshop on Support for Composing Distributed Applications, 1998 [Hed98] Hedin, Görel: Language Support for Design Patterns Using Attribute Extension. In: Workshops on Object-Oriented Technology, 1998. – ISBN 3–540–64039–8, S. 137–140 [HW03] Hohpe, Gregor ; Woolf, Bobby: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Boston, MA, USA : Addison-Wesley Longman Publishing Co., Inc., 2003. – ISBN 0321200683
[Jav98]
Java SE 6.0: VetoableChangeListener API – http://java.sun.com/javase/6/. 1998
[LW07]
Lyon, Douglas A. ; Weiman, Carl F. R.: Observer-Conditioned-Observable Design Pattern. In: Journal of Object Technology 6 (2007), Nr. 4
[M. 01]
M. E. Nordberg III: Aspect-Oriented Dependency Inversion. In: OOPSLA Workshop on Advanced Separation of Concerns in OO Systems, 2001
[Mar06] Marinescu, Floyd: Esper: High Volume Event Stream Processing and Correlation in Java – http://www.infoq.com/news/Esper–ESP-CEP. 2006 [NZ99]
Neumann, Gustaf ; Zdun, Uwe: Filters as a language support for design patterns in object-oriented scripting languages. In: 5th Conference on Object-Oriented Technologies & Systems, 1999
[OAS06] OASIS Technical Committee: Web Services Brokered Notification 1.3 – http://docs.oasisopen.org/wsn/wsn-ws_brokered_notification-1.3-spec-os.pdf. 2006 [Obj91]
Object Management Group (OMG): Common Object Request Broker Architecture (CORBA) – http://www.corba.org/, 1991
[Obj04]
Object Management Group (OMG): http://www.omg.org/technology/documents/, 2004
[Ope]
Open Services Gateway Initiative: http://www.osgi.org
CORBA
Event
Service
v1.2
–
[OSG04] OSGi Alliance: Listeners Considered Harmful: The Whiteboard Pattern. A Technical Whitepaper – www.osgi.org/documents/osgi_technology/whiteboard.pdf, 2004 [Pap03]
Papazoglou, Mike: SOC: Concepts, Characteristics and Directions. In: Proceedings of the 4th International Conference on Web Information Systems Engineering, 2003
[Rie96]
Riehle, Dirk: The Event Notification Pattern–Integrating Implicit Invocation with Object-Orientation. In: Theor. Pract. Object Syst. 2 (1996), Nr. 1, S. 43–52. http://dx.doi.org/http://dx.doi.org/10.1002/(SICI)1096-9942(1996)2:13.0.CO;2-8. – DOI http://dx.doi.org/10.1002/(SICI)1096–9942(1996)2:13.0.CO;2–8. – ISSN 1074–3227
