====== Differences ====== This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
architecture_styles [2015/02/26 16:59] apaschke [Direct Strongly-Coupled API4KB Access] |
architecture_styles [2015/02/28 11:37] apaschke [Direct Strongly-Coupled API4KB Access] |
||
---|---|---|---|
Line 21: | Line 21: | ||
===== Direct Strongly-Coupled API4KB Access ===== | ===== Direct Strongly-Coupled API4KB Access ===== | ||
- | Strong coupling with the local client requiring direct knowledge of the (downloaded) API4KB libraries and knowledge artifacts or direct knowledge about how the inter-process interaction and access with the remote API4KB works in ad-hoc network programming (e.g. via socket programming). | + | Strong coupling with the local client requiring direct knowledge of the (downloaded) API4KB **Artifacts** or direct knowledge about how the inter-process interaction and access with the remote API4KB works in ad-hoc network programming (e.g. via socket programming). |
- | Example: OntoMaven and RuleMaven. | + | Example: [[http://www.corporate-semantic-web.de/ontomaven.html|OntoMaven and RuleMaven]]. |
Line 47: | Line 47: | ||
A unit of composition with contractually specified interfaces and explicit content dependencies only. Component is specified in terms of a contract which includes a set of provided interfaces (interfaces that the component offers as a service to other components) and required interfaces (dependencies that this component has on other components). Container provides managed server-side hosting environment for components and deals with the distributed systems and middleware issues. | A unit of composition with contractually specified interfaces and explicit content dependencies only. Component is specified in terms of a contract which includes a set of provided interfaces (interfaces that the component offers as a service to other components) and required interfaces (dependencies that this component has on other components). Container provides managed server-side hosting environment for components and deals with the distributed systems and middleware issues. | ||
- | Examples, e.g. Java Beans, Corba Component Model, API4KB OntoMaven Aspect-Oriented Component Model, ... | + | Examples, e.g. Java Beans, Corba Component Model, [[http://www.corporate-semantic-web.de/ontomaven.html|OntoMaven Aspect-Oriented Component Model]], ... |
===== Decoupled Indirect Communication ===== | ===== Decoupled Indirect Communication ===== | ||
Line 57: | Line 57: | ||
Publish-subscribe with event-based communication through propagation of events (via an underlying overlay network, e.g. structured and unstructured peer-to-peer or other broker overlay). Publishers publish structured events to an event service (responsible for event routing and matching) and subscribers express interest in particular events through subscriptions. | Publish-subscribe with event-based communication through propagation of events (via an underlying overlay network, e.g. structured and unstructured peer-to-peer or other broker overlay). Publishers publish structured events to an event service (responsible for event routing and matching) and subscribers express interest in particular events through subscriptions. | ||
- | Distributed Event Based Systems with Complex Event Processing (CEP) in Event Processing Agents (EPAs) deployed in Event Processing Networks (EPNs). | + | Distributed Event Based Systems and Event Streaming with Complex Event Processing (CEP) in Event Processing Agents (EPAs) deployed in Event Processing Networks (EPNs). |
==== Group communication ==== | ==== Group communication ==== | ||
Line 67: | Line 67: | ||
Examples, e.g. Tuple Spaces, Distributed Shared Memory, Message Queues (e.g., JMS, Active MQ, ...) | Examples, e.g. Tuple Spaces, Distributed Shared Memory, Message Queues (e.g., JMS, Active MQ, ...) | ||
- | ==== Asynchronous Messaging Libraries ==== | + | ==== Asynchronous Messaging Libraries ==== |
- | Libraries exist which can be used according to a number of different messaging patterns. | + | Libraries exist which combine and can be used according to a number of the different, above mentioned messaging patterns, e.g. |
- | * [[http://en.wikipedia.org/wiki/%C3%98MQ|0MQ]] (ZeroMQ) provides "sockets" (a many-to-many connection generalizing the concept of network socket) which each operate according to a specific messaging pattern (e.g. RPC, pub-sub, ...) | + | * [[http://en.wikipedia.org/wiki/%C3%98MQ|0MQ]] (ZeroMQ) is a lightweight messaging system specially designed for high throughput and low latency scenarios as in IoT, low-level event streaming etc. It provides "sockets" (a many-to-many connection generalizing the concept of network socket) which each operate according to a specific messaging pattern (e.g. RPC, pub-sub, ...), which (in contrast to e.g. more advanced messaging queue servers and enterprise service bus middlewares) need to be manually implement by combining various pieces of the framework (see ad-hoc network programming with sockets and devices in strong coupling category). |
+ | * higher-level message queue middleware such as Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling or Sparrow), Scala (Kestrel, Kafka) or Java (ActiveMQ), and Enterprise Service Bus middleware such as OpenESB, Mule ESB, ... | ||
+ | |||
+ | Examples, e.g. [[http://responder.ruleml.org|RuleML RuleResponder]] is implemented as a Staged Event-Driven Architecture (SEDA) using the Mule ESB and ActiveMQ or RabbitMQ. It can use all kinds of synchronous and asynchronous transport protocols including e.g. AMQP, JMS, HTTP Rest, SOAP, etc.. | ||
===== Summary of Dimensions ===== | ===== Summary of Dimensions ===== |