# Dynamic Linked Data: A SPARQL Event Processing Architecture
## 4 Broker Design
### Protocols And Dependability  
The gates layer implements the SPARQL 1.1 SE Protocol (see Section 3): it create requests (i.e., update, query, subscribe and unsubscribe) for the scheduler and delivers responses and notifications. As shown in Figure 4, the SEPA broker reference implementation provides two gates: HTTP(S) and WS(S), both supporting also the Transport Layer Security (TLS) Protocol. The former processes updates and queries according to the SPARQL 1.1 Protocol, while the latter uses the WebSocket protocol for conveying subscription requests and notifications. The HTTP gate is based on the non-blocking, event-driven I/O model based on Java NIO, provided by the Apache HTTP Components ([[https://hc.apache.org/](https://hc.apache.org/)]([https://hc.apache.org/](https://hc.apache.org/))), while the WebSocket gate is based on the Java WebSocketslibrary by TooTallNate ([[https://github.com/[PERSON]/Java-WebSocket](https://github.com/[PERSON]/Java-WebSocket)]([https://github.com/[PERSON]/Java-WebSocket](https://github.com/[PERSON]/Java-WebSocket))). Other protocols like MQTT, COAP or Linked Data Notification can be supported by implementing the corresponding gates.  
SEPA aims to provide a minimum level of dependability [52] through the Dependability Manager. On the one hand, it implements the security policies and mechanisms presented in Section 3. In a real-world scenario, the OAuth 2.0 Authorization Server would be different form the Resource Server (i.e., the SEPA broker). Clients who need secure access to the SEPA broker would register and get a valid token from such an external service (e.g., [[https://auth0.com](https://auth0.com)]([https://auth0.com](https://auth0.com))). However, at the same time, to provide an off-the-shelf solution for testing SEPA security, the reference implementation of the Dependability Manager implements the client credentials grant type and uses JSON Web Tokens (JWT) (i.e., the reference implementation uses the APIs provided by Connect2 Id, [https://connect2 id.com/products/nimbus-jose-jwt](https://connect2 id.com/products/nimbus-jose-jwt)). On the other hand, reliability is achieved with simple, but effective methods of failure detection in the communication between the broker and subscribed agents. This property is important to grant the general dependability of the connection, but also, it is functional, on the broker side, for cleaning unused resources. In this sense, the WebSocket protocol used by the reference implementation embeds a failure detection mechanism. In fact, thanks to the ping-pong controls frames, the broker and the agents can recognize a failure (i.e., a broken connection) and react accordingly to some fault-tolerant policies. Furthermore, the broker can exploit this information to free unused resources created by agents that have been disconnected in an unexpected way, avoiding a negative impact on the performance. Overall, the protocol and the broker architecture must support the development of distributed applications with some degree of availability and resilience. Therefore, future implementations of new gates should at least implement a basic fault detection mechanism to recognize disconnections or node failures.  
Figure 4: Broker reference architecture.