840 likes | 859 Views
CIS5930 Internet Computing. XML Web Services Basics Prof. Robert van Engelen. Web Services Basics. Interoperability has highest priority XML over HTTP Web services can be created regardless of the programming language Reusable application components
E N D
CIS5930Internet Computing XML Web Services Basics Prof. Robert van Engelen
Web Services Basics • Interoperability has highest priority • XML over HTTP • Web services can be created regardless of the programming language • Reusable application components • Software can be reused as service components in a service-oriented architecture, i.e. to support the requirements of software users • Compositionality is realized with open standards • Connect existing software • Publish the application as a service • Applications connect and interact by encoding and decoding data in XML CIS 5930 Fall 2006
XML Web Services Protocols • SOAP • “Simple Object Access Protocol” is an XML messaging protocol • Typically remote procedure call (RPC) request-response messages • Or XML-based messages (document/literal style) • WSDL • “Web Service Description Language” is an XML document that defines the service interface, protocol bindings, and service endpoint addresses • Uses XML schema to define XML types • Typically uses SOAP to bind the messaging protocol • UDDI • “Universal Description, Discovery and Integration” is a repository/database of services (e.g. defined by WSDLs) • Not very popular, won’t discuss CIS 5930 Fall 2006
WSDL • WSDL represents a contract between the service requestor and the service provider • WSDL is an XML specification that defines four critical pieces of information of an XML Web service: • Interface information describing all publicly available functions • Data type information for all message requests and message responses • Binding information about the transport protocol to be used • Address information for locating the specified service CIS 5930 Fall 2006
WSDL Specification • The definitions root element defines the name and namespace of the web service • The types element contains a set of XML schemas with all the data types (XML elements and types) used between the client and server • One or more message elements define the names of the messages, each contains zero or more message part elements, which can refer to message parameters or message return values • The portType element combines multiple message elements to form a complete one-way or round-trip operation • The binding element describes how the service will be implemented on the wire • The service element defines the endpoint address for invoking the service CIS 5930 Fall 2006
Example WSDL • The HelloService service provides a single publicly available function sayHello • The function expects a single string parameter, and returns a single string greeting • Request-response message pattern over HTTP using HTTP POST CIS 5930 Fall 2006
WSDL definition Root Element • Defines the name and targetNamespace:<definitions name="HelloService” targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl” xmlns="http://schemas.xmlsoap.org/wsdl/” xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/” xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl” xmlns:xsd="http://www.w3.org/2001/XMLSchema”> • Typically the xmlns namespace bindings are included in the root element and are used in the remainder of the WSDL • Note that the WSDL namespace is declared as the default namespace for all of the other WSDL elements (http://schemas.xmlsoap.org/wsdl/) so these elements are not explicitly namespace qualified CIS 5930 Fall 2006
The WSDL message Elements • Two message elements are defined • The first represents a request message, SayHelloRequest, and the second represents a response message, SayHelloResponse:<message name="SayHelloRequest"> <part name="firstName" type="xsd:string"/></message><message name="SayHelloResponse"> <part name="greeting" type="xsd:string"/></message> • For the request, the part specifies the function parameters • For the response, the part specifies the function return values • The type is a QName value, indicating the schema type of the part CIS 5930 Fall 2006
Built-in XSD SimpleTypes Simple type Example Value(s) string Web Services boolean true, false, 1, 0 float -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN double -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN decimal -1.23, 0, 123.4, 1000.00 integer -126789, -1, 0, 1, 126789 nonPositiveInteger -126789, -1, 0 negativeInteger -126789, -1 long -1, 12678967543233 int -1, 126789675 short -1, 12678 byte -1, 126 nonNegativeInteger 0, 1, 126789 unsignedLong 0, 12678967543233 unsignedInt 0, 1267896754 unsignedShort 0, 12678 unsignedByte 0, 126 positiveInteger 1, 126789 date 1999-05-31 time 13:20:00.000, 13:20:00.000-05:00 CIS 5930 Fall 2006
The WSDL portType Element • The portType element defines a single operation, sayHello • The operation consists of a single input message (SayHelloRequest) and a single output message (SayHelloResponse):<portType name="Hello_PortType"> <operation name="sayHello"> <input message="tns:SayHelloRequest"/> <output message="tns:SayHelloResponse"/> </operation></portType> • The input/output elements specify a message attribute of tns:SayHelloRequest or tns:SayHelloResponse • The tns prefix references the targetNamespace defined within the definitions element CIS 5930 Fall 2006
Message Exchange Patterns • The operation in portType uses input and/or output to define the message exchange pattern • WSDL supports four basic patterns of operation • One-way • Request-response • Solicit-response • Notification • The one-way and request-response are most often used CIS 5930 Fall 2006
The WSDL binding Element • The binding element provides specific details on how a portType operation will actually be transmitted over the wire • Bindings can be made available via multiple transports • Multiple bindings for a single portType can be specified • The binding element itself specifies name and type attributes:<binding name="Hello_Binding" type="tns:Hello_PortType"> • The type attribute references the portType CIS 5930 Fall 2006
WSDL SOAP Bindings • WSDL 1.1 includes built-in extensions for SOAP 1.1<binding name="Hello_Binding" type="tns:Hello_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” namespace="urn:examples:helloservice” use="encoded"/> </input> <output> <soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/” namespace="urn:examples:helloservice” use="encoded"/> </output> </operation> </binding> CIS 5930 Fall 2006
WSDL SOAP Bindings (cont’d) • The soap:binding element indicates a SOAP binding over HTTP transport • The style attribute indicates rpc for an RPC format or document for a document-oriented message format • The transport attribute defines the transport mechanism • The soap:operation element indicates the binding of a specific operation to a SOAP implementation • The soapAction attribute specifies that the SOAPAction HTTP header should be used for identifying the service (SOAP 1.1 only) • The soap:body element specifies the details of the input and output messages • The encodingStyle attribute defines the encoding format when the use attribute is encoded (RPC encoded) and the namespace attribute defines the RPC message namespace • For document/literal messaging, the use attribute is literal CIS 5930 Fall 2006
SOAP Request Message • An RPC request message uses the encodingStyle and namespace:<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance’ xmlns:xsd='http://www.w3.org/2001/XMLSchema’ xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/’ xmlns:soapenc='http://schemas.xmlsoap.org/soap/encoding/’ soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> <soap:Body> <n:sayHello xmlns:n='urn:examples:helloservice'> <firstName xsi:type='xsd:string'>World</firstName> </n:sayHello> </soap:Body></soap:Envelope> CIS 5930 Fall 2006
SOAP Response Message • An RPC request message:<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/’ xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance’ xmlns:xsd='http://www.w3.org/1999/XMLSchema'> <SOAP-ENV:Body> <ns1:sayHelloResponse xmlns:ns1='urn:examples:helloservice' SOAP-ENV:encodingStyle= 'http://schemas.xmlsoap.org/soap/encoding/'> <greeting xsi:type='xsd:string'>Hello, World!</greeting> </ns1:sayHelloResponse> </SOAP-ENV:Body></SOAP-ENV:Envelope> CIS 5930 Fall 2006
Using WSDL • Most Web service development toolkits support WSDL • Generate WSDL from server (interface) code • Translate WSDL to server objects and client proxies • Dynamic invocation obtains the WSDL, select an operation, populate the parameters and send the request message • Generic SOAP client: http://www.soapclient.com/soaptest.html • http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl • Find more WSDLs and code at http://www.xmethods.com CIS 5930 Fall 2006
Generating WSDL and Server Code with gSOAP • Suppose we implement a HelloService with one operation sayHello that takes a string parameter s and returns the string “Hello s” • To bind XML namespaces to C (and C++) code, gSOAP uses a prefix convention for function names and type names:prefix__name • The service interface is defined in a header file containing the line:int ns__sayHello(char *firstName, char **greeting); • To generate WSDL and server code (-S) or client code (-C) in C (-c) for SOAP RPC encoding (-e):$ soapcpp2 -S -c -e hello.h input output CIS 5930 Fall 2006
Implementing a Web Service with gSOAP • Add directives to the header file specification to define the service name, namespace, and endpoint://gsoap ns service name: hello//gsoap ns service namespace: urn:hello//gsoap ns service location: http://www.cs.fsu.edu/~engelen/hello.cgiint ns__sayHello(char *firstName, char **greeting); CIS 5930 Fall 2006
Implementing a Web Service with gSOAP (cont’d) • The following files are generated:soapStub.h annotated copy of the header filesoapH.h XML serializer declarationssoapC.c XML serializers for C/C++ typessoapServer.c SOAP server skeleton and dispatcherhello.nsmap XML namespace mapping tablehello.wsdl the service WSDLhello.sayHello.req.xml sample request messagehello.sayHello.res.xml sample response message • To complete the service, we create a C implementation of the sayHello function with the following parameters:int ns__sayHello(struct soap *soap, char *firstName, char **greeting); • The first arg is the gSOAP engine context (runtime environment) CIS 5930 Fall 2006
Implementing a Web Service with gSOAP (cont’d) • Implementation of the sayHello function in hello.c:int ns__sayHello(struct soap *soap, char *firstName, char **greeting){ if (!firstName) return soap_sender_fault(soap, “No name!”, NULL); *greeting = (char*)soap_malloc(soap, strlen(firstName)+8); strcpy(*greeting, “Hello ”); strcat(*greeting, firstName); strcat(*greeting, “!”); return SOAP_OK;} • For a simple CGI-based service, add the service dispatcher:#include “hello.nsmap”int main(){ return soap_serve(soap_new());} • Compile with gcc -o hello.cgi hello.c stdsoap2.c soapC.c soapServer.c CIS 5930 Fall 2006
Implementing a Web Service with gSOAP (cont’d) • Deploy hello.cgi as a service in Apache (e.g. cgi-bin dir) and publish hello.wsdl on the Web site • To test the service over stdin/stdout, modify hello.sayHello.req.xml to include a name string and run hello.cgi from the command line:$ ./hello.cgi < hello.sayHello.req.xml • To deploy as an iterative stand-alone service, use the following:#include “hello.nsmap”int main(){ struct soap *soap = soap_new(); soap_bind(soap, NULL, 8080, 100); for (;;) { if (soap_accept(soap) < 0) break; soap_serve(soap); soap_destroy(soap); soap_end(soap); } soap_print_fault(soap, stderr); soap_done(soap); free(soap); return 0;} CIS 5930 Fall 2006
Implementing a Concurrent Web Service with gSOAP • #include “hello.nsmap”int main(){ pthread_t tid; struct soap *soap = soap_new(); soap_bind(soap, NULL, 8080, 100); for (;;) { if (soap_accept(soap) < 0) break; pthread_create(&tid,NULL,(void*(*)(void*))serve,(void*)soap_copy(soap)); } soap_print_fault(soap, stderr); soap_done(soap); free(soap); return 0;}void *serve(void *soap){ pthread_detach(pthread_self()); soap_serve((struct soap*)soap); soap_destroy((struct soap*)soap); soap_end((struct soap*)soap); soap_done((struct soap*)soap); free(soap); return NULL;}int ns__sayHello(struct soap *soap, char *firstName, char **greeting) { … } CIS 5930 Fall 2006
Implementing a Client with gSOAP • Since we already have a gSOAP header file with the service definitions, we can also create a client from it:$ soapcpp2 -C -c -e hello.h • The client uses the stub call defined in soapClient.c:#include “hello.nsmap”int main(){ struct soap *soap = soap_new(); char *s; if (soap_call_ns__sayHello(soap, NULL, NULL, “Robert”, &s)) soap_print_fault(soap, stderr); else printf(“The response is %s\n”, s); soap_destroy(soap); soap_end(soap); soap_done(soap); free(soap); return 0;} • Compile with gcc -o client client.c stdsoap2.c soapC.c soapClient.c CIS 5930 Fall 2006
Implementing a Service with ASP.NET in VB • <%@ WebService Language="VB" Class="TempConvert" %>Imports SystemImports System.Web.ServicesPublic Class TempConvert :Inherits WebService<WebMethod()> Public Function FahrenheitToCelsius(ByVal Fahrenheit As Int16) As Int16 Dim celsius As Int16 celsius = ((((Fahrenheit) - 32) / 9) * 5) Return celsiusEnd Function<WebMethod()> Public Function CelsiusToFahrenheit(ByVal Celsius As Int16) As Int16 Dim fahrenheit As Int16 fahrenheit = ((((Celsius) * 9) / 5) + 32) Return fahrenheitEnd FunctionEnd Class CIS 5930 Fall 2006
Implementing a Client with SOAP::Lite for Perl • Example in Perl using the SOAP::Lite package:use SOAP::Lite;print "Connecting to Hello Service...\n";print SOAP::Lite -> service('http://www.cs.fsu.edu/~engelen/hello.wsdl') -> sayHello ('World'); • The program generates the following output:Connecting to Hello Service...Hello World! CIS 5930 Fall 2006
SOAP Fault messages • The gSOAP service may return a SOAP Fault:return soap_sender_fault(soap, “description”, detail); • If the problem is at the receiving side (SOAP-ENV:Server) use:return soap_receiver_fault(soap, “description”, detail); • Example SOAP Fault message:HTTP/1.1 500 Internal Server ErrorServer: gSOAP/2.7Content-Type: text/xml; charset=utf-8Content-Length: 520Connection: close<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/” xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd="http://www.w3.org/2001/XMLSchema” xmlns:ns="urn:hello"> <SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring>No name!</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body></SOAP-ENV:Envelope> CIS 5930 Fall 2006
SOAP 1.1 Faults • The SOAP Fault element has the following sub elements: • <faultcode> A code for identifying the fault • <faultstring> A human readable explanation of the fault • <faultactor> Information about who caused the fault to happen (opt) • <detail> Holds application specific error information • The faultcode values defined below must be used in the faultcode element when describing faults: • VersionMismatch: Invalid namespace for the SOAP Envelope element • MustUnderstand: An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood • Client: Message was incorrectly formed or contained incorrect info • Server: There was a problem with the server and processing could not proceed • Note: SOAP 1.2 differs slightly (mostly element naming) CIS 5930 Fall 2006
WSDL and SOAP Faults • Faults in portType operations specify which faults may be returned:<message name="AuthenticationFault"> <part name="AuthenticationFault” element=”f:AuthenticationFault"/></message><portType name=“myPort”> <operation name=“getStatus”> <input message=“tns:getStatusRequest”/> <output message=“tns:getStatusResponse”/> <fault name=“fault” message=“tns:AthenticiationFault”/> </operation></portType><binding name=“myBinding” type=“myPort”> <operation name="getStatus"> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> <wsdl:fault name="AuthenticationFault"> <soap:fault name="AuthenticationFault" use="literal"/> </wsdl:fault> </operation></binding> CIS 5930 Fall 2006
SOAP Headers • The optional SOAP Header element contains SOAP processing information in one or more subelements, such as addressing and authentication, for example:<SOAP-ENV:Envelope …> <SOAP-ENV:Header> <wsse:Security SOAP-ENV:mustUnderstand="1"> <wsse:UsernameToken wsu:Id="User"> <wsse:Username>engelen</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">/u5faawcfIeve1yHCsdXAWyIlbU=</wsse:Password> <wsse:Nonce>NDU0MGE5YjljYTUzYzAzZjA2MTc=</wsse:Nonce> <wsu:Created>2006-10-26T12:27:37Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> … </SOAP-ENV:Body></SOAP-ENV:Envelope> CIS 5930 Fall 2006
SOAP Headers (cont’d) • The optional actor attribute may be used to address the Header element to a particular endpoint:<SOAP-ENV:Header> <m:Transaction SOAP-ENV:actor=”endpoint URL” SOAP-ENV:mustUnderstand=“1”> … </m:Transaction> <wsse:Security>…</wsse:Security></SOAP-ENV:Header> • This allows the header information to be targeted at any intermediate SOAP processors for which this information is intended • The SOAP mustUnderstand attribute is used to indicate whether a header entry is mandatory or optional for the recipient to process CIS 5930 Fall 2006
SOAP Headers (cont’d) • The SOAP Header is a struct in gSOAP, defined in the header file:#import “wsse.h” // get WSSE Security elementsstruct SOAP_ENV__Header{ mustUnderstand _m__Transaction *m__Transaction; mustUnderstand _wsse__Security *wsse__Security;};and accessible in the soap context, for example:soap.header.m__Transaction = new _m__Transaction(); CIS 5930 Fall 2006
SOAP RPC Encoding • SOAP RPC encoding defines rules on representing primitive types, xs:simpleTypes (e.g. enumerations), array, and records (structs) as xs:complexTypes in XML • Closer to the notion of programming language types • Full XML schema support is not possible • XML attributes not supported • No element repetitions with maxOccurs=“unbounded” • Only xs:sequence and xs:all, no xs:choice CIS 5930 Fall 2006
SOAP RPC Encoding (cont’d) • Primitive types • Built-in XSD types, such as xs:string (see Schema specification) • Schema xs:simpleTypes for elements, such as enumerations<xs:simpleType name=”switch"> <xs:restriction base="xsd:token"> <xs:enumeration value=”on"/><xs:enumeration value=”off"/> </xs:restriction></xs:simpleType> • Base64 (xs:base64Binary) and hex (xs:hexBinary) types CIS 5930 Fall 2006
SOAP RPC Encoding (cont’d) • Arrays are “SOAP encoded” arrays:<xs:complexType name="ArrayOfstring"> <xs:complexContent> <xs:restriction base="SOAP-ENC:Array"> <xs:sequence> <xs:element name="item" type="xsd:string” minOccurs="0" maxOccurs="unbounded”/> </xs:sequence> <xs:attribute ref="SOAP-ENC:arrayType” wsdl:arrayType="xsd:string[]"/> </xs:restriction> </xs:complexContent> </xs:complexType> • Arrays are encoded in SOAP messages follows:<inputStringArray SOAP-ENC:arrayType="xsd:string[2]"> <item xsi:type=“xsd:string”>hello</item> <item xsi:type=“xsd:string”>world!</item> </inputStringArray> CIS 5930 Fall 2006
SOAP RPC Encoding (cont’d) • Struct are just xs:complexTypes with xs:sequence (or xs:all):<xs:complexType name=”lightSwitch"> <xs:sequence> <xs:element name=“light” type=“tns:switch”/> <xs:element name=“level” type=“xs:int”/> <xs:element name=“image” type=“xs:base64Binary”/> </xs:sequence> </xs:complexType> CIS 5930 Fall 2006
RPC versus Doc/lit in WSDL • Document/literal SOAP messages don’t include encodingStyle and XML types for request/responses are not constraint by the SOAP RPC encoding rules • Document style and literal use are declared in the bindings:<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> CIS 5930 Fall 2006
RPC versus Doc/lit in WSDL (cont’d) • The parts in messages now refer to elements, which will be the request/response elements in the SOAP Body<definitions xmlns:m=“urn:examples:tempservice” …> <message name="getTermRequest"> <part name="term" element=”m:getTemp"/> </message> <message name="getTermResponse"> <part name="value" element=”m:getTempResult"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType> CIS 5930 Fall 2006
RPC versus Doc/lit in WSDL (cont’d) • The parts in messages refer to elements that define the request and response elements in the SOAP Body of a message:<types> <xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” targetNamespace=“urn:examples:tempservice” … elementFormDefault=“qualified” attributeFormDefault=“unqualified”> <xs:element name=“getTemp”> <xs:complexType> <xs:sequence> <xs:element name=“zipCode” type=“xs:string”/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name=“getTempResult”> <xs:complexType> <xs:sequence> <xs:element name=“temp” type=“xs:float”/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </types> CIS 5930 Fall 2006
SOAP Request Message in Doc/Lit Style • Note the absence of SOAP-ENC:encodingStyle and xsi:type in the message:<?xml version='1.0' encoding='UTF-8'?><soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance’ xmlns:xsd='http://www.w3.org/2001/XMLSchema’ xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'> <soap:Body> <n:getTemp xmlns:n='urn:examples:tempservice'> <n:zipCode>32306</n:zipCode> </n:getTemp> </soap:Body></soap:Envelope> CIS 5930 Fall 2006
SOAP Multi-ref Encoding • SOAP operation (request/response) • The XSD type system to represent values of primitive types in XML, such as bool, integer, float, string, base64 • A SOAP array type to encode sparse and partial arrays • Id-href XML attributes to implement graph edges to encode multi-ref objects <env:Envelope> <env:Body env:encodingStyle=“…”> <ns:myRemoteOp> <arg1 xsi:type=“xsd:int”>123</arg1> <arg2 enc:arrayType=“xsd:string[5]”> <item>abc</item> <item href=“#_1”/> <item href=“#_1”/> <item href=“#_2”/> <item enc:position=“[5]”>xyz</item> </arg2> </ns:myRemoteOp> <mref id=“_1”>abc</mref> <mref id=“_2”>def</mref> </env:Body></env:Envelope> CIS 5930 Fall 2006
X X X X Y X X Y Z Static Structure Analysis forSOAP RPC Encoding CIS 5930 Fall 2006
gSOAP Constructs a Plausible Object Model for Serialization typedef int SSN;struct Node{ int val; int *ptr; float num; struct Node *next;}; val ptr num next Node SSN Data model graph(arcs denote all possiblepointer references) Source code typedefinitions CIS 5930 Fall 2006
Generating an XML Schema Definition for Serialized XML <simpleType name=“SSN”> <restriction base=“int”/></simpleType><complexType name=“Node”> <sequence> <element name=“val” type=“int”/> <element name=“ptr” type=“int” minOccurs=“0”/> <element name=“num” type=“float”/> <element name=“next” type=“tns:Node” minOccurs=“0”/> </sequence></complexType> val ptr num next Node SSN Data model graph CIS 5930 Fall 2006
Generating Code for Runtime Points-To Analysis serialize_pointerToint(int *p) { if (p != NULL) { // lookup and mark (p,TYPE_int) // as target in ptr hash table }}serialize_Node(struct Node *p){ if (p != NULL) { // lookup and mark (p,TYPE_Node) // as target in ptr hash table mark_embedded(&p->val,TYPE_int); serialize_pointerToint(p->ptr); // skip p->num serialize_pointerToNode(p->next); }} val ptr num next Node SSN Data model graph CIS 5930 Fall 2006
Generating Serialization Code put_pointerToint(int *p) { if (p != NULL) { // lookup (p,TYPE_int) // if embedded, then output “ref” // if single, then output value // if multi, then output value // with “id” and mark embedded }}put_Node(struct Node *p){ if (p != NULL) { // lookup (p,TYPE_Node) // if embedded, then output “ref” // if single, then output value // if multi, then output value // with “id” and mark embedded put_int(&p->val); put_pointerToint(p->ptr); put_float(&p->num) put_pointerToNode(p->next); }} val ptr num next Node SSN CIS 5930 Fall 2006
Serialization Example val=123 ptr=B num=1.4 next=B val=456 ptr=C num=2.3 next=A Nodeloc=A Nodeloc=B =789 Ptr hash table after runtime points-to analysis by thegenerated algorithm constructed from the data model SSNloc=C CIS 5930 Fall 2006
Serialization Example (cont’d) multi, id=1 single val=123 ptr=B num=1.4 next=B val=456 ptr=C num=2.3 next=A multi, id=1 Nodeloc=A Nodeloc=B single embedded, id=2 =789 SSNloc=C CIS 5930 Fall 2006
Serialization Example (cont’d) multi, id=1 single val=123 ptr=B num=1.4 next=B val=456 ptr=C num=2.3 next=A multi, id=1 Nodeloc=A Nodeloc=B single embedded, id=2 =789 <Node id=“_1”></Node> SSNloc=C CIS 5930 Fall 2006
Serialization Example (cont’d) multi, id=1 single val=123 ptr=B num=1.4 next=B val=456 ptr=C num=2.3 next=A multi, id=1 Nodeloc=A Nodeloc=B single embedded, id=2 =789 <Node id=“_1”> <val>123</val></Node> SSNloc=C CIS 5930 Fall 2006