1

2. Client/Server Programming and Service Oriented Programming

Client/Server

� Advantages

– The simplest and most widely adopted programming model for

distributed systems

� One entity provides a service; another entity uses the service

– The client sends a request in a message to the server and waits for a

reply or acknowledgement in a message

– Creates a clear separation between client and server

� This allows them to be placed in different computers, have different implementations, different OS and hardware, etc.

2

2-Tier Client/Server

� Initially, a 2 tier architecture was used

– Fat clients

– Thin clients

– There is currently a trend in large organizations to go back

to a thin client model. Mobiles, virtualization and cloud

computing are pushing/riding this trend.

GUI SQL DBMS

GUI SQL DBMS

Computation burden on

the client

But many messages

Computation burden on

the server (may be a

scalability problem)

But only few short

messages

� 2 tier architectures developed into 3-tier

� In the Internet, it is common to have multiple-tier installations– This allows different number of servers at each tier, e.g., many web servers

and one SQL server, etc.

– Each phase can implement its own client/server model and standard

3-Tier and n-Tier Client/Server (TODO)

GUIWeb

serverDBSQL

HTTP

HTML

3

Implementing Client/Server with Message Passing

� By sending messages over a TCP (sometimes UDP) connection

– Typically, a textual protocol is defined over TCP/IP. For example,

HTTP, NFS, SMTP

– The client connects to the server that listens on a known TCP/UDP

port. Sends the request in a message and waits for a reply, at which

point the connection is closed

– This solves heterogeneity

– Long delays and failures are overcome by reload/retry

– Security: mainly by encryption and digital signatures/certificates

� SSL, HTTPS, IPSec

Skeleton of a Server

server()

{

s = socket();

bind(s, mysockaddr, addrlen);

listen(s,5);

while (true) {s1=accept(s,remote_addr,…);

thread_create(handle_connection, s1, remote_addr);

}

}

handle_connection(socket s, sockaddr sa)

{

while (true)

{

if (n = recv(s, buf, len)) > 0) {

command = parse(buf);

reply = execute(command, sa);send(s, reply, …)

}

else if (n < 0)

terminate(s);

}

}

It is in fact better to store sockets of

connections in a list/table. Then use

“select” to read from all opened

connections and refer data read from

a given connection to a thread taken

from a thread pool.

4

Remote Procedure Call / Remote Method Invocation

� Idea

– A procedure/method is executed on a (possibly) different process(or)

than the one in which it was invoked

� Benefits

– Allows a “normal” programming model in a distributed setting

– Hides the details of sending and receiving messages, marshaling and

unmarshaling, finding the server, security policies, etc.

– Simplifies the programmer’s work

– Standard

� Code reuse

RPC/RMI

� Implementation:

– The procedure/method is called “as usual”, but

instead of invoking the real implementation, it

invokes a local stub/proxy

– The stub is responsible for all the gory details of

communicating with the target computer

– On the target computer, a stub/skeleton takes

care of interfacing with the network

� It invokes the implementation as if it was a local function, obtains the result and output parameters and passes them to the client

Application Stub

Implementation Stub

5

Dynamic Binding in RPC/RMI

� There is a need for a mechanism that allows to register

implementations and to bind to them

� Server side:

– The implementation registers in a repository/registry its name,

version, handle, and unique id

– The handle is typically system dependent, e.g., Ethernet address,

IP+port, etc.

– The implementation may also register necessary information for

authentication and access control, Quality of Service (QoS), etc.

� This process is also called export

Dynamic Binding in RPC/RMI - continued

� Client side:

– The client imports/binds the implementation given a name and

version. In response, it receives a handle that allows it to access the

implementation

– Some standards also support lookups based on properties of a

service rather than a specific name

– The binding process serves as an opportunity for load balancing,

fault-tolerance, authentication and access control, and matching

between client and server view of the declared interface etc.

– Some standards support negotiation of non-functional aspects, such

as QoS, during the binding process

� Problems:

– Binding is a slow and expensive process, especially if connections

are short lived

– The binder is a performance and scalability bottleneck for the system

6

RPC Client Example

Forex_Client()

{

Forex fex = (Forex) bind(“BestForex”);

fex.GetExRate(“USD”, “ILS”);

}

� The implementation of “bind” locates a service whose name is “BestForex” and stores a mapping between this services identifier (e.g., IP address+port) to a proxy object pointed by “fex” that has the same signature as the real Forex object.

� When the method GetExRate is called, the proxy object (executed inside the stub module) connects to the real object, using the stored mapping, and generates a message coding the fact that it wishes to invoke the “GetExRate” method with the given parameters. When the reply is received from the server, the proxy method returns the value that was included in the reply message.

Stub Generation in RPC/RMI

� Static: automatic from an IDL file– Interface Definition Languages are used to declare the interface,

which includes the procedures, types of parameters, and whether they are in, out, or inout

� The latter is important for performance optimizations� The IDL is usually language independent, and can be mapped to more

than one language. This way the client and server can also be implemented in different programming languages

– In Web services, interfaces are described in WSDL

� Dynamic– The interface definition is stored in some interface repository.

� It can be located either on a dedicated server, or each server can act as its own interface repository

– There are methods to explore the interface repository and to create dynamic stubs

7

Sample RPC Standards

� NFS RPC

� DCE-RPC

� CORBA

� DCOM => .NET remoting

� Java RMI

� Web services

– Only the IDL (WSDL), communication protocol (SOAP), and discovery

and binding (UDDI) are standardized

� Protocol Buffers from Google

– In fact, Protocol Buffers is only an IDL and a serialization mechanism

with several RPC stacks implemented for it

� Thrift from Facebook

Invocation Models

� Synchronous RPC

– The application is blocked until the reply arrives

� Delayed RPC (promises and futures)

– Control is returned immediately, but the returned values are undefined until the reply arrives. The application can check when the invocation has ended

� Asynchronous RPC

– The call is invoked and control returns immediately. When the reply arrives, the application is notified through a registered event handler

� One-way

– No reply is expected (and control returns immediately)

8

Issues with Implementing RPC/RMI

� What needs to be described in the IDL and interface repository?

– Until recently (DCE, CORBA, DCOM, Java RMI), only the signatures

and parameters type definitions

– Recently (Web Services), the interface repository (WSDL and UDDI)

can also include semantic information about the service

� Several proposals to extend WSDL with things like Web Services Endpoint Language (WSEL) and Web Services Offerings Language (WSOL) to standardize the representation of semantic information

– In CORBA, there is also an implementation repository, which can

included some semantic information

� Parameter passing

– Taken care of by marshaling and unmarshaling

� The types of the parameters must be known

Issues with Implementing RPC/RMI – cond.

� Pointers

– The problem is that pointers in one computer are invalid in another

computer

– Solutions:

� Disallow pointers and references

� The server stub can translate pointers. The client can send/receive a copy of the pointed object, which requires knowledge of its size/type

� The client can generate a stub for pointed objects, and send a reference to the server, which can then access the pointed object using reversed RPC/RMI

� A pointer to a pointer, e.g., a list linked, is a further issue

– Either pass all pointers – not always possible

– Or, copy on demand

– In any case, very inefficient

9

Failures in RPC/RMI

� A request is lost– The solution here is to reissue the request after a timeout up to

several retries. After that, an exception is raised

� A reply is lost– The problem here is that the client does not know if the request was

already executed

– The solution is to associate a unique identifier to each request, so the server can filter duplicate requests

– If the client always waits for a reply before sending a further request, it is possible to simply use a retry bit

In general, this is similar to providing reliable delivery for messages by the network, like is done by TCP/IP

Many standards use TCP/IP, but still include a middleware level sequencing and recovery to overcome breakups of TCP/IP connections

Failures in RPC/RMI - continued

� Client Failure

– The problems are

� Orphan computation

– Wastes resources

– The computation might have locked resources

� If the client recovers and starts issuing requests, we need to distinguish between requests and replies that belong to different incarnations of the client

– Solutions (none of them is perfect)

� Log file allows clients to learn what was their state just before crashing

� Attach an epoch number to requests to distinguish between sequence numbers of different incarnations of the same client

� Use timeouts and leases on computations to overcome orphans

– Practically, often the client restarts with a new TCP or UDP port and thus has a

new identify

10

Other Issues in RPC/RMI

� Global variables like errno

� Error reporting

� Weakly typed languages like C

� Procedures/functions with an unknown number of parameters

There is a good chapter in Tanenbaum&Steen about RPC. We will

devote the rest of the discussion to modern extensions of RPC,

mainly .NET and Web Services.

Web Services

� Web services is a high level, platform independent, flexible, and extendible middleware standard, which has wide industry support

– Supports a service oriented architecture

� Stateless, although it is still possible to use session cookies

– The base protocols are SOAP over HTTP over TCP/IP

– Defines standard XML based ways of representing services, publishing them, discovering them, and learning their specification

� Disclaimer: A few drawings in the next slides were taken from Liran Ben-Haim

11

The General Web Services Architecture

UDDI

Any Client

SOAP SOAP

SOAP

Web Web Server

Web Service

Main Web Services Components

� Simple Object Access Protocol (SOAP)

– Extendible XML based RPC protocol

– Serialization standard (XSD)

� Web Service Description Language (WSDL)

– An extendible XML based standard for describing services

– Includes the capabilities of an IDL + semantic description of the service

� Universal Description, Discovery and Integration (UDDI)

– A yellow pages directory for services

� Support both semantic and syntactic description of services

� Supports discovery

12

UDDI Data Structures

tModel: Descriptions of specifications

for services

Binding: Technical information

about a service entry point

Service: Descriptive information

about a particular family of technical

offerings

Name, description and

categorization of the service

Business: Information about the

entity who offers a service

Name, contact, description

and categorization of the provider

Access point(s) for the service

Pointer to a WSDL file

WSDL Documents

� Types– A container for data type definitions using some type system (such as XSD)

� Message– An abstract, typed definition of the data being communicated

� Defined by a sequence of elements (name and corresponding type)

� Operation– An abstract description of an action supported by the service

� Define the corresponding messages

� Port Type– An abstract set of operations supported by one or more endpoints

� By default: One-way, Request-response, Solicit-response, and Notification

� Binding– A concrete protocol and data format specification for a particular port type

� Port– A single endpoint defined as a combination of a binding and a network

address

� Service– A collection of related endpoints (ports)

13

An Example (partial) WSDL Document

<message name="getTermRequest">

<part name="term" type="xs:string"/>

</message>

<message name="getTermResponse">

<part name="value" type="xs:string"/>

</message>

<portType name="glossaryTerms">

<operation name="getTerm"><input message="getTermRequest"/><output message="getTermResponse"/>

</operation>

</portType>

<binding type="glossaryTerms" name="b1"><soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />

<operation>

<soap:operation soapAction="http://example.com/getTerm"/>

<input>

<soap:body use="literal"/></input>

<output>

<soap:body use="literal"/>

</output>

</operation>

</binding>

SOAP Elements

� Envelope (mandatory)

– Top element of the XML document representing the message

� Header (optional)

– Determines how a recipient of a SOAP message should process the message

– Adds features to the SOAP message such as authentication, transaction management, message routes, TTL, etc…

� If the mustUnderstand attribute is set to true for a given field, the recipient must raise an exception if it does not recognizes it

� Body (mandatory)

– Exchanges information intended for the recipient of the message.

– Typical use is for RPC calls and error reporting.

14

POST /HelloWorld/Hello.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: lengthSOAPAction: "http://tempuri.org/Add"

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope …>

<soap:Header>

<AuthHeader xmlns="http://tempuri.org/">

<Username>avi</Username>

<Password>xM76w@</Password>

</AuthHeader>

</soap:Header>

<soap:Body>

<Add xmlns="http://tempuri.org/">

<a>23</a>

<b>44</b>

</Add>

</soap:Body>

</soap:Envelope>

SOAP Faults

� Used to carry error and/or status information within a SOAP message

� Appears within the SOAP body

� Defines the following:– faultcode (mandatory)

– Faultstring (mandatory)

– faultactor (optional)

– Detail

<SOAP:Fault><faultcode>SOAP:Server</faultcode><faultstring>Internal Application Error</faultstring><detail xmlns:f=“http://www.a.com/CalculatorFault”>

<f:errorCode>794634</f:errorCode><f:errorMsg>Divide by zero</f:errorMsg>

</detail></SOAP:Fault>

15

Microsoft .NET

� A combination of a programming framework, run-time

environment, and a middleware

– In this course we will focus on the middleware aspects

– In fact, .NET supports multiple middleware standards:

� ASP.NET

� .NET Remoting

� .NET Web Services Extensions (WSE)

Merged into the WCF -

Windows Communication

Framework

.NET as a Programming Framework

Vis

ua

l Stu

dio

.NE

T

CLR

Base Class Library

Data and XML

XML Webservices Windows Forms

Web Forms

Common Language Specification

Cobol J#...JScriptVB C#

Operating System

16

WCF Architecture

Client

Proxy

Channel

Channel

Encoding

Channel

Transport

Channel

ServiceDispatcher

Endpoints

Channel Stack

Channel

Channel

Encoding

Channel

Transport

Channel

Channel Stack

WCF Architecture

17

WCF Components: Contracts and Descriptions

� The data contract describes every parameter that makes up every message that a service can create or consume. The message parameters are defined by XML Schema definition language (XSD) documents, enabling any system that understands XML to process the documents

� The message contract defines specific message parts using SOAP protocols, and allows finer-grained control over parts of the message, when interoperability demands such precision

� The service contract specifies the actual method signatures of the service. It is distributed as an interface in one of the supported programming languages, such as Visual Basic or Visual C#

� Policies and bindings stipulate the conditions required to communicate with a service. For example, the binding must (at a minimum) specify the transport used (for example, HTTP or TCP), and an encoding. Policies include security requirements and other conditions that must be met to communicate with a service

WCF Components: Service Runtime

� Contains the behaviors that occur only during the actual operation of the service

– Throttling controls how many messages are processed, which can be varied if the demand for the service grows to a preset limit

– An error behavior specifies what occurs when an internal error occurs on the service, for example, by controlling what information is communicated to the client

– Metadata behavior governs how and whether metadata is made available to the outside world

– Instance behavior specifies how many instances of the service can be run (for example, a singleton specifies only one instance to process all messages).

– Transaction behavior enables the rollback of transacted operations if a failure occurs

– Dispatch behavior is the control of how a message is processed by the WCF infrastructure

� Extensibility enables customization of runtime processes– Message inspection is the facility to inspect parts of a message– Parameter filtering enables preset actions to occur based on filters acting on

message headers

18

WCF Components: Messaging / Channels

� A channel is a component that processes a message in some way, e.g., by authenticating a message. A set of channels is also known as achannel stack. Channels operate on messages and message headers

� There are two types of channels: – Transport channels read and write messages from the network. Transports

use an encoder to convert messages (which are represented as XML Infosets) to and from the byte stream representation used by the network. Examples of encodings are XML and optimized binary. Sample transports include:

� The HTTP channel specifies that the HyperText Transport Protocol is used for message delivery

� The TCP channel similarly specifies the TCP protocol

� The Transaction Flow channel governs transacted message patterns

� The Named Pipe channel enables interprocess communication

� The MSMQ channel enables interoperation with MSMQ applications

– Protocol channels implement message processing protocols� WS-Security is an implementation of the WS-Security specification enabling security

at the message layer

� The WS-Reliable Messaging channel enables the guarantee of message delivery

� The encoders present a variety of encodings that can be used to suit the needs of the message

WCF: Defining a Sample Service Contract

using System;

using System.ServiceModel;

namespace Microsoft.ServiceModel.Samples {

// Define a service contract

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]

public interface ICalculator {

// Create the method declaration for the contract

[OperationContract] double Add(double n1, double n2);

[OperationContract] double Subtract(double n1, double n2);

[OperationContract] double Multiply(double n1, double n2);

[OperationContract] double Divide(double n1, double n2);

}

}

Various behaviors that can be controlled include, e.g.,• the communication style (RPC, One-Way, Duplex)• parameter passing (by value - in or by reference - out)• security policies

19

WCF: Implement a Sample Service

using System;

using System.ServiceModel;

namespace Microsoft.ServiceModel.Samples {

// Define a service contract

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]

public interface ICalculator {… // see previous slide

}

// Step 1: Create service class that implements the service contract.

public class CalculatorService : ICalculator {

// Step 2: Implement functionality for the service operations

public double Add(double n1, double n2) {

double result = n1 + n2;

Console.WriteLine("Received Add({0},{1})", n1, n2);

// Code added to write output to the console window.

Console.WriteLine("Return: {0}", result);

return result;

} … // implement the other methods

}

}

WCF: Self-Hosting a Sample Service

using System;using System.ServiceModel;using System.ServiceModel.Description;namespace Microsoft.ServiceModel.Samples {

… // see previous slide

class Program { static void Main(string[] args) {// Step 1 of the address configuration procedure: Create a URI to serve as the base address.Uri baseAddress = new Uri("http://localhost:8000/ServiceModelSamples/Service");// Step 2 of the hosting procedure: Create ServiceHostServiceHost selfHost = new ServiceHost(typeof(CalculatorService), baseAddress);try {

// Step 3 of the hosting procedure: Add a service endpoint.selfHost.AddServiceEndpoint( typeof(ICalculator), new WSHttpBinding(), "CalculatorService"); // Step 4 of the hosting procedure: Enable metadata exchange.ServiceMetadataBehavior smb = new ServiceMetadataBehavior();smb.HttpGetEnabled = true;selfHost.Description.Behaviors.Add(smb);// Step 5 of the hosting procedure: Start (and then stop) the service.selfHost.Open();Console.WriteLine("The service is ready."); Console.WriteLine("Press <ENTER> to terminate service."); Console.WriteLine();// Close the ServiceHostBase to shutdown the service.selfHost.Close();

} catch (CommunicationException ce) {Console.WriteLine("An exception occurred: {0}", ce.Message);selfHost.Abort();

}}

}

Can also be hosted inside IIS, WAS, etc

20

WCF: Creating a Client

� From the command line:– svcutil.exe /language:cs /out:generatedProxy.cs /config:app.config

http://localhost:8000/ServiceModelSamples/service

– Generates the client proxy code (generatedProxy.cs) and a configuration file (app.config)

<?xml version="1.0" encoding="utf-8"?><configuration>

<system.serviceModel><bindings>

<wsHttpBinding><binding name="WSHttpBinding_ICalculator"></binding>

</wsHttpBinding></bindings><client>

<endpointaddress=http://localhost:8000/ServiceModelSamples/Service/CalculatorServicebinding="wsHttpBinding"bindingConfiguration="WSHttpBinding_ICalculator"contract="Microsoft.ServiceModel.Samples.ICalculator"name="WSHttpBinding_ICalculator">

</endpoint></client>

</system.serviceModel></configuration>

WCF: Sample Client’s App Code

using System;

using System.Collections.Generic;

using System.Text;

using System.ServiceModel;

namespace ServiceModelSamples {

class Client {

static void Main() {

//Step 1: Create an endpoint address and an instance of the WCF Client.

CalculatorClient client = new CalculatorClient();

// Step 2: Call the service operations.

// Call the Add service operation.

double value1 = 100.00D;

double value2 = 15.99D;

double result = client.Add(value1, value2);

Console.WriteLine("Add({0},{1}) = {2}", value1, value2, result);

//Step 3: Closing the client gracefully closes the connection and cleans up resources.

client.Close();

}

}

}

21

WCF Architecture Overview

ServiceEndpoint

EndpointAddress

Binding

ContactDescription

EndpointAddress

URI

AddressHeader

Identity

WCF Architecture Overview - continued

Binding

Name

Namespace

BindingElement

SecurityBindingElement

ReliableSessionBindingElement

TcpTransportBindingElement

22

WCF Architecture Overview - continued

ContractDescription

Name

Namespace

OperationDescription

MessageDescription

IContractBehavior

WCF Architecture Overview - continued

EndpointAddress

Binding

ContractDescription

ServiceEndpoint

ServiceDescription

Service Type

IServiceBehavior

EndpointAddress

Binding

ContractDescription

ServiceEndpoint

IChannelBehavior

ChannelDescription

23

WCF Architecture Overview - continued

ServiceDescription

ServiceHost

EndpointListener

CORBACommon Object Request Broker Architecture

� An object oriented extension to RPC

– Supports OO concepts: Interfaces, Objects, Encapsulation, Inheritance (of both interfaces and implementations), Polymorphism

� An international standard

– Defined by the Object Management Group (OMG)

� http://www.omg.org

– Defines a set of standard services in what is known as the Object Management Architecture (OMA)

– The standard defines an architecture, and emphasize portability and interoperability

� The standard does not cover the implementation details

� Language, OS, and hardware independent

� Supports multiple transport protocols and can connect to other frameworks using bridges

� Still in wide usage in various industries

– Telecom, Investment Banking, Military

24

Java Remote Method Invocation

� Basic RPC functionality

� By default, uses IIOP for communication (has CORBA inside)– A Java only solution for the same problem

– Implements its own registry and lookup mechanisms

– Since everything is in Java, no need for IDL files

� There exists an XML-RPC Java interface called JAX-WS, which enables interoperability with SOAP objects, including Web services

Representational State Transfer (REST)

� REST is an alternative architecture to RPC

– In principle, a general methodology, in practice the only

implementation is based on HTTP and tightly relies on HTTP

� Main principles include:

– Each object is identified through a URI

– Communication is performed between a client and a server by

exchanging representations of objects (identified through a URI)

– Unlike RPC, here the interface is fixed and consists of Create, Read,

Update, and Delete (CRUD) operations only

� These are being mapped into (or expressed through) HTTP GET, POST, PUT, and DELETE commands (and possibly also HEAD and OPTIONS to explore an object metadata)

� Object representation can be in any standard format

– XML, XHTML, JSON, ATOM, jpeg, gif, mpeg-4, etc.

25

More on REST

� Stateless

– No client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.

� Cacheable

– Clients are able to cache responses. Responses must, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests.

� Layered system

– A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.

� Code on demand (optional)

– Servers can extend or customize the functionality of a client by transferring executable logic to it, .e.g., Java applets, JavaScript, etc.

Claimed Benefits of Being RESTful

� Simplicity

� Scalability

� Simple availability/fault-tolerance

� Caches, proxies and other mediators are transparent

– The above properties are due to the fixed interface, the use of URIs,

stateless interactions and the idempotent semantics of (most of) the

operations

� REST relies on HTTP’s native return codes, authentication and

security mechanisms, and headers for its operations

– No need to reinvent the wheel, and can be supported in any HTTP compliant environment

26

HTTP Return Codes

ExampleDescription Status Range

100 ContinueInformational100

200 OKSuccessful200

201 Created

202 Accepted

301 Moved PermanentlyRedirection300

304 Not Modified

401 UnauthorizedClient error400

402 Payment Required

404 Not Found

405 Method Not Allowed

500 Internal Server ErrorServer error500

501 Not Implemented

A RESTful Example

A Corresponding RESTful ServiceAn RPC Based Service

PUT users/{username}createUserAccount

GET users/{username}getUserAccount

PUT users/{username}updateUserAccount

DELETE users/{username}deleteUserAccount

POST users/{username}/bookmarkscreateBookmark

PUT users/{username}/bookmarks/{id}updateBookmark

DELETE users/{username}/bookmarks/{id}deleteBookmark

GET users/{username}/bookmarks/{id}getBookmark

GET users/{username}/bookmarks[?tag={tag}]getUserBookmarks

GET {username}/bookmarks[?tag={tag}]getUserPublicBookmarks

GET [?tag={tag}]getPublicBookmarks

27

A Few Comments

� PUT vs. POST for Creating Objects

– POST is used to add an object whose id is assigned by the server

� The response includes code 201 and the body is the representation of the object including its server assigned id

– PUT is used to add an object whose id is assigned by the client

� Many servers and browsers only support GET and POST

– X-HTTP-Method-Override: DELETE

� Authentication

– By relying on the 401 return code and the Authorization: ???

header

� Metadata discovery

– HEAD returns the headers for the object, including, e.g., possible

mime types (representations)

– Options returns the supported methods (GET, POST, etc.)

Additional Issues

� What if we need something stronger than CURD?

– E.g., transfer money from one account to the other?

– The solution is to create “transfer” objects

� What about distributed transactions?

– Similarly to above, create “transactions” objects

� What about reliable messaging?

– Beyond TCP, it is currently up to the application to add support for it

and/or trying to limit oneself to use only idempotent operations