Software communication requires a message transport, a message protocol, and a destination address. 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.
All three concepts of transport, protocol, and destination address are interrelated. A change to one affects the others. For example: if the source and destination happen to be in the same virtual address space; the source will know the virtual address of the receiving function and will know how to invoke it and how to pass a message through parameters. Nearly all CORBA implementations automatically recognize when this optimization can be used.
A simple function call is not possible when the source and destination are physically separated. Distributed software communication is accomplished by serializing the message according to a protocol that destination understands. A remote destination addresses could be something simple like the combination of an IP address and port number or it could be expressed as a URL, or an IRI, or a CORBA Inter-operable Object Reference (IOR).
All physical message transports including Ethernet and Wi-Fi just transport bytes. It is left up to the source and destination to agree on a message protocol. The protocol specifies the set of rules for how these messages will be serialized for transport. A protocol could be ad-hoc and unsophisticated or it might have the sophistication necessary for the source and destination to remain oblivious of the distributed nature of the system. This in turn allows the developer to choose the style that best fits the application.
The API4KB RFP indicates that we must support the following architecture styles (although it uses the term platform mappings):
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.
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.
Wide range of techniques based on a loosely-coupled two-way exchange via an interface between communicating entities.
Protocols involve pairwise exchange of messages from client to server and from server back to client with the first message containing an encoding of operation to be executed at the server, the second message contains the result (encoded as an array of bytes). Paradigm is rather primitive (in contrast to RPC/RMI) and typically only used for e.g. embedded systems where performance is very important. Approach is also used by e.g. the http protocol.
Examples, e.g. Web Services, stateless REST Web Services, Enterprise Service Bus, …
Resembles RPC in the world of distributed objects.
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).
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, OntoMaven Aspect-Oriented Component Model, …
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, ….
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 and Event Streaming with Complex Event Processing (CEP) in Event Processing Agents (EPAs) deployed in Event Processing Networks (EPNs).
Broadcast and multicast.
Examples, e.g. Tuple Spaces, Distributed Shared Memory, Message Queues (e.g., JMS, Active MQ, …)
Libraries exist which combine and can be used according to a number of the different, above mentioned messaging patterns, e.g.
Examples, e.g. 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..