D ESIGN OF TECHNOLOGIES FOR THE INTEGRATION
4.1 Design of a middleware technology
4.1.3 Design of a FSPM integrative protocol
With the designed FSP data exchange model, we can now design the needed protocol-middleware technology, i.e. the FSPM integrative protocol, by referencing the JSON-RPC [149, 150].
<property name="radius" value="0.1"/>
<property name="color">
<rgb>0.0 1.0 0.0</rgb>
</property>
<property name="p_extened" value="0.1"/>
</node>
<edge id="1" src_id="0" dest_id="1" type="successor"/>
</graph>
Figure 4.7 An example of XEG code representing a plant with a sphere component
The JSON-RPC refers to the RPC protocol that uses JSON to encode its calls and the HTTP protocol as transport mechanism, which indicates that it is an application layer protocol but on top of HTTP. It mainly consists of three specified parts, including a set of data models for typing of data in the HTTP message body, the request and response structures for constructing of the HTTP request and response messages [151]. The data models are data types sharing from JSON, namely four primitive types (Strings, Numbers, Booleans, and Null) and two structured types (Objects and Arrays).
The JSON-RPC request structure defines how the method name and its parameters of a JSON-RPC call are packed as an HTTP request message. The HTTP response message structure defines how the returning values or error information of a JSON-RPC call is packed as an HTTP response message. (c.f. Figure 4.8).
By default, the request structure includes:
• A request line with POST as preferred request method
• Request header fields, including at least:
o Content-Type: value must be application/json
Figure 4.8 Examples of JSON-RPC POST request and response message
o Content-Length: value must comply to HTTP protocol specification
o Accept: value must be application/json
• An empty line
• A message body with a single JSON object consisting of four members:
o jsonrpc: A string denoting the version of JSON-RPC protocol.
o method: A string containing the name of the method to be invoked.
o params: An optional structured value that holds the parameter values to be used during the invocation of the method.
o id: A client established identifier with String, Number or Null type.
The response structure includes:
• A status line with one of five JSON-RPC specified status codes, or a HTTP specified status code.
• Response header fields, including at least:
o Content-Type: value must be application/json
o Content-Length: value must comply to HTTP protocol specification
• An empty line
• A message body with a single JSON object consisting of four members:
o jsonrpc: A string denoting the version of JSON-RPC protocol.
o result: Value is data generated by the invoked method, required on success.
o error: A structured value that holds the parameter values to be used during the invocation of the method, required on error.
o id: An identifier which must be equal to the id of the Request Object.
We have defined our ‘FSPM integrative RPC’ based on specific assumptions of the integration of different FSPMs. A FSPM, as introduced previously, is a special type of program that can be executed independently. It thus always has a ‘main’
method, which takes a FSP data graph and some environment arguments as parameters. The integration of different FSPMs is about to allow one FSPM to call the ‘main’ method of another FSPM over networks in a distributed manner. More specifically in our project, the FSPM for structural simulation has to be integrated with a FSPM for functional simulation by calling its ‘main’ method. Environmental data will thus only be used as the parameters of the functional FSPM and will affect the structural simulation indirectly by the computed functional properties in the exchange graph received by the structural FSPM. In general, it is hardly true that identical environment parameters are needed for different FSPMs to be integrated.
It is because of their heterogeneity that they have the value of being integrated. It is also because of their heterogeneity that their parameters cannot be exactly the same.
With reference to the data models of JSON-RPC, we designed an application layer protocol on top of HTTP with a smaller set of data models as data types. As the XEG is added as a new type for an intermediate form of FSP graph in our protocol, content-type is specified to media type (formerly MIME type) [152]
‘application/x-www-form-urlencoded’ accordingly. This defines the format of the message body: the keys and values are encoded in key-value pairs separated by ‘&’,
with a ‘=’ between the key and the value. On one hand, JSON and XML are the two most common formats for data exchange, we choose XML as data model format of the XEG for its mature data modeling mechanisms. On the other hand, JSON has less verbose syntax, and is quicker to read and write, the syntax of URL encoded form is even simpler than JSON (e.g. no nested values). The combination of data model XEG and media type ‘application/x-www-form-urlencoded’ therefore results in a simple but powerful protocol.
With reference to the request and response structures of JSON-RPC, we designed our integrative protocol with simplified request and response structures.
Similar to the standard JSON-RPC, a call of our FSPM integrative RPC is represented by sending a set of key-value pairs to a server. The difference is that the key-value pairs in our protocol are not formatted in a JSON object but in a URL encoded form. Moreover, the member of the URL encoded form of the request and response structure have members ‘model’, ‘main_method’, ‘result_graph’ ‘time’
‘retroactive’ to enable the integration of different FSPMs. The value of the member
‘model’ should be Null when the code of the server FSPM is not available on client side. When a FSPM integrative RPC call is received, a response with a URL encoded form with the result in XEG will be sent back to the client. No specific status codes have been designed at the level of our protocol, and we think the status code mechanism defined at HTTP level is already enough to ensure the correct exchange between different FSPMs.
In detail (c.f. Figure 4.9), the data models of the designed protocol includes four primitive data types sharing from JSON-RPC (i.e. Strings, Numbers, Booleans, and Null), and one structured type (XEG).
The request structure includes:
• A request line with POST as request method
• Request header fields, including at least:
o Content-Type: value must be application/x-www-form-urlencoded
o Content-Length: value must comply to HTTP protocol specification
o Accept: value must be application/x-www-form-urlencoded
• An empty line
• A message body consisting of four members:
o model: A string containing the code of the FSPM to be integrated. If the code is not sent from the callee, the value must be Null
o main_method: A string containing the name of the ‘main’
method of the FSPM to be integrated.
o graph: An optional structured value that holds the FSP graph (in XEG) as input of the invocation of the method.
o time: A value of Number type to represent the number of running steps of the target FSPM. It is the key for time scale alignment between different FSPMs.
o retroactive: A value of Boolean type to represent the retroactive setting of the integration.
o id: A client established identifier with String, Number or Null type.
The response structure includes:
• A status line with a HTTP specified status code.
• Response header fields, including at least:
o Content-Type: value must be application/x-www-form-urlencoded
o Content-Length: value must comply to HTTP protocol specification
• An empty line
• A message body consisting of two members:
o result_graph: Value is an FSP graph in XEG generated by the invoked method, required on success.
o id: An identifier which must be equal to the id of the request.
Figure 4.9 Examples of the FSPM integrative protocol request (upper) and response (lower) messages.