User Tools

Site Tools


architecture_styles

====== Differences ====== This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
architecture_styles [2015/02/23 16:02]
apaschke [OMG API4KB (Distributed) Architecture Styles]
architecture_styles [2015/02/28 11:37]
apaschke [Direct Strongly-Coupled API4KB Access]
Line 1: Line 1:
 ====== OMG API4KB Distributed Architecture Styles ====== ====== OMG API4KB Distributed Architecture Styles ======
  
-===== Software Communication =====+===== Introduction: ​Software Communication =====
  
 The two things needed for software communication are a message transport and a message protocol. A message transport is the physical means to convey a message. Examples of transport mechanisms include Ethernet, shared memory, and the Peripheral Component Interconnect (PCI) bus. Wi-Fi and Bluetooth are examples of wireless transports. The two things needed for software communication are a message transport and a message protocol. A message transport is the physical means to convey a message. Examples of transport mechanisms include Ethernet, shared memory, and the Peripheral Component Interconnect (PCI) bus. Wi-Fi and Bluetooth are examples of wireless transports.
Line 17: Line 17:
 Both CORBA and Java RMI serialize messages in compliance with the Internet Inter-ORB Protocol (IIOP) standard. This is a comprehensive standard, which is usually implemented with support from automated tools. On the other hand, web services only specifies the use of XML and leaves up to the software developer(s) to ensure that the source and the destination have the same understanding of the XML content. There are many tools to support this understanding. WSDL specifies that messages will comply to an XML schema. If WSDL is not being used and no XML schema has been specified; the source and destination must at lease have some sort of mutual understanding of an implied schema or else they run the risk that parts of their messages will be lost or misunderstood. Both CORBA and Java RMI serialize messages in compliance with the Internet Inter-ORB Protocol (IIOP) standard. This is a comprehensive standard, which is usually implemented with support from automated tools. On the other hand, web services only specifies the use of XML and leaves up to the software developer(s) to ensure that the source and the destination have the same understanding of the XML content. There are many tools to support this understanding. WSDL specifies that messages will comply to an XML schema. If WSDL is not being used and no XML schema has been specified; the source and destination must at lease have some sort of mutual understanding of an implied schema or else they run the risk that parts of their messages will be lost or misunderstood.
  
 +In the following three categories of communication paradigms are distinguish according to their decreasing strength of API4KB coupling.
  
-===== Remote invocation ​=====+===== Direct Strongly-Coupled API4KB Access  ​=====
  
-Wide range of direct ​techniques based on a loosely-coupled two-way exchange via an interface between communicating entities. ​+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: [[http://​www.corporate-semantic-web.de/​ontomaven.html|OntoMaven and RuleMaven]]. 
 + 
 + 
 +===== Loosely-coupled Remote Invocation via API4KB Interfaces ===== 
 + 
 +Wide range of techniques based on a loosely-coupled two-way exchange via an interface between communicating entities. ​
  
 ==== Request-Reply Protocols ==== ==== Request-Reply Protocols ====
Line 35: Line 43:
  
 **Distributed Object Middleware**,​ e.g. Java RMI (which is restricted to Java). OMG CORBA is a multi-language solution with a declarative Interface Description Language (IDL). Usually developers choose to invoke CORBA methods through a static interface, which is obtained by using an automated tool to translate the IDL into the chosen implementation language. However, it is also possible to formulate a CORBA message using the facilities of the Dynamic Invocation Interface (DII). **Distributed Object Middleware**,​ e.g. Java RMI (which is restricted to Java). OMG CORBA is a multi-language solution with a declarative Interface Description Language (IDL). Usually developers choose to invoke CORBA methods through a static interface, which is obtained by using an automated tool to translate the IDL into the chosen implementation language. However, it is also possible to formulate a CORBA message using the facilities of the Dynamic Invocation Interface (DII).
 +
 ==== Distributed Components ==== ==== Distributed Components ====
 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]], ...
  
-===== Indirect ​communication ​=====+===== Decoupled ​Indirect ​Communication ​=====
  
 Indirect decoupled techniques where sender and receiver are time and space uncoupled via an intermediary. Indirect communication between entities in a distributed system through an intermediary with no direct coupling between the sender and the receiver(s),​ e.g. event routing in publish-subscribe middleware (based e.g. on peer-to-peer),​ streaming to a cloud, .... Indirect decoupled techniques where sender and receiver are time and space uncoupled via an intermediary. Indirect communication between entities in a distributed system through an intermediary with no direct coupling between the sender and the receiver(s),​ e.g. event routing in publish-subscribe middleware (based e.g. on peer-to-peer),​ streaming to a cloud, ....
Line 48: 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 58: 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 combine and can be used according to a number of the different, above mentioned messaging patterns, e.g.
  
-Libraries exist which can be used according to a number of different ​messaging ​patterns.+  * [[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, ...
  
-  * [[http://en.wikipedia.org/​wiki/​%C3%98MQ|0MQ]] (ZeroMQprovides "​sockets"​ (a many-to-many connection generalizing ​the concept ​of network socket) which each operate according to a specific messaging pattern (e.g. RPCpub-sub, ...)+Examples, e.g. [[http://responder.ruleml.org|RuleML RuleResponder]] is implemented as a Staged Event-Driven Architecture ​(SEDAusing the Mule ESB and ActiveMQ or RabbitMQ. It can use all kinds of synchronous and asynchronous transport protocols including ​e.g. AMQPJMSHTTP Rest, SOAP, etc..
  
 ===== Summary of Dimensions ===== ===== Summary of Dimensions =====
-  * Coupling in Time (Synchronous/​Asynchronous+  * Time Uncoupling - The sender and the receiver(scan have **independent lifetimes** 
-  * Coupling in (Virtual AddressSpace (Local/​Remote+  * Space Uncoupling - The sender** does not know or need to know the identity of the receiver(s)**, and vice versa 
-  * Multiplicity of Message Recipients (Brokered/​Brokerless)+  * Synchronous vs. Asynchronous Communication - sender sends a message and then continues **without blocking** 
 +  * Centralized vs. Distributed Architecture ​(+hybrid) 
 +  * Structured vs. Unstructured Topology 
 +  * Placement: Multiple Servers, Proxy/​Cache,​ Mobile Code  
 +  * Architecture Styles: Client-Server,​ Broker Overlay, Peer-to-Peer 
 +  * Multiplicity of Message Recipients (Group Communication, ​Brokered/​Brokerless)
   * Directionality of Communication (Uni-/​Bi-directional)   * Directionality of Communication (Uni-/​Bi-directional)
-  * Object-Orientation+  * Communication Entities: Processes, Objects, Components, Services / Agents ​
   * Classification of Endpoints (Single-/​Multi-Sorted)   * Classification of Endpoints (Single-/​Multi-Sorted)
architecture_styles.txt · Last modified: 2015/04/24 10:11 by rmbell