Working Draft 

Core communication

[RDF Schema]

Request-reply model

The foundation of the core communication is the basic request-reply model common in distributed programming. Request and Reply are both Messages. The request-reply model is implemented by the TransportLayer.

Client

A Request submitted by the client is uniquely identified by the URI of the request instance. The clients must append a to property to the request specifying the recipient. The recipient is an instance of ProcessingEntity. The TransportLayer has to figure out how to deliver the Request to the specified recipient (which protocol mapping to use, how to resolve the address etc.). Extensibility: the recipient can have additional properties telling the TransportLayer how to deliver the Request.

Example:

 

Service

The Request that the service gets carries a URI that uniquely identifies the request. To reply, the service has to attach the inReplyTo property to the Reply that identifies the request to which the reply belongs to.

If the service requires knowledge about who sent the request, it has to initialize the TransportLayer specifying this particular mode of operation. If this option is specified the TransportLayer will append from property to every Request that it passes to the service. The from property will point to an instance of ProcessingEntity. The URI of this instance depends on the underlying protocol mapping (URL, IOR etc.).

Example:

 
 

Transport Layer

The TransportLayer may use different policies and protocols mappings. For example, it may send a message via an HTTPLayer or TCPIPLayer depending on the destination specification. TransportLayer abstracts out from the underlying protocol mappings. Thus, it does not provide any guarantees about whether the message will be sent using a connection-oriented or a connectionless method. A particular implementation of the TransportLayer may provide appropriate customization options, e.g. setting of connection timeouts etc.
 

See also: Core Communication, Basic State MaintenanceHTTP, TCP/IP



Sergey Melnik. Last modified: 06/01/99