Distributed Systems Notes-middlewares__distributed

CMU 95702 Distributed Systems notes. A brief introduction to several schemes for solving interoperability concern in distributed systems Cobra ' s CDR, Java serialization and Xml/json. This chapter is relatively simple to organize.

Word, middleware is to better communicate with remote server. Interoperability Concern

Interoperability issues in distributed systems. Big/little endian byte ordering may differ floating point representation may differ Binary vs Unicode
If j=3, Binary says is 00 ... 011, and the Unicode representation is 0000000000110011, and if there is no agreement at both ends, there will be an error.
The receiver had better know which one we are using.

Suppose we write TCP server in C + +, then we can write a JAVA TCP connection to connect to the server. you can.
Both C + + and JAVA know how to open a TCP connection.

Assuming that the client sends a Java object to the server, the contents of the object can be encapsulated into C + + object again. not at all. Three solutions CORBA ' s CDR

Both sides know the data type and order of the message. Both sides have an IDL (Interface Description Language Interface Description language) before communication, which is similar to Google's protocol buffers. XML, xsdl, and WSDL can be used as IDL.

As in the following section C code.

1 2 3 4 5

struct person {string name;

We can have CORBA Interface Compiler to do the right marshalling and unmarshalling operation, either C or JAVA.
The CORBA ' s CDR is characterized by-very fast. So the transmitted information does not include the data type, only the right-hand column of the table. Java Serialization

Java ' s serialization itself can be used to marshal and unmarshal, so it does not require IDL. Neither side knew the data type beforehand.

Like the following section of Java code.

1 2 3 4 5 6 7 8 9

public class person implements serializable{string name. String place; Long, public person (string nm,place,year) {n M=name;this.place=place;this.year=year; }//More methods}

Java serialization is characterized by a lot of data (such as class name, version number, data type, etc.) to describe real data. Web Service use of XML

Format:

1 2 3 4 5

<p:person xmlns:p= "HTTP://WWW.ANDREW.CMU.EDU/~MM6" > <p:name>Smith</p:name> <p:place> London</p:place> <p:year>1934</p:year> </p:person>

is slower than the first two methods. Because it is the text form and the first two methods are binary forms. HTTP header needs to declare content-type:text/xml; Charset:iso-8859-1 can represent any binary message because binary data (images and other encrypted elements) can be represented as BASE64 must follow the syntax of XSDL. Support each platform. Web Service use of JSON

Format:

1 2 3 4

{' person ': {' name ': ' Smith ' ' place ': ' London ' ' Year ': ' 1934 '}}

can represent any binary message, because binary data (pictures and other encrypted elements) can be represented as Base64 must follow JSON's syntax. CompareMarshalling and external data representation
Binary, Xml/json text interoperability
CORBA flexibility, Java requires both sides, Xml/json interoperable security reliability
Tcp:reliable as it checks if the message is arrived
Udp:not Reliable Performance
CORBA > Java > Xml/json (Package and unpackage) Remote references full OOP Describe how the protocols the The Internet Allow for heterogeneity Describe I middleware allows for heterogenity
Hides low level implementation Pass Pointers

In distributed OOP, we need to transfer pointers, including the following information.
UDP Based request-reply Protocol

Directly on the diagram and code.

Code:

1 2 3 4 5 6 7 8 9

Client Side:public byte[] dooperation (remoteobjectref o, int methodid, byte[] arguments) sends a request message To the remote object and returns the reply. The arguments specify the remote object, which is invoked and the arguments of this method. Server side:public byte[] Getrequest (); Acquires a client request via the server port. Cooloperation Select Object, execute, method public void sendreply (byte[] reply, inetaddress clienthost, int clientport); Sends the reply message, reply to the client, Internet address and port.

Failure Model

Dooperation may be timeout at waiting, what we are going to do. Returns an error message to caller response may be lost, so we tell the client to let the client try and try until the confirmation server is dead. The result is that the client may receive the same message. Handle Duplicates

Empty history According to the acknowledgement of the client. request-reply Message Structure

1 2 3 4 5

Messagetype:int (0=request, 1=reply) requestid:int objectreference:remoteobjectref methodid:int or method Argument:ar Ray of bytes

Original address: http://www.shuang0420.com/2016/11/02/Web-service-middlewares/