840 likes | 860 Views
Learn about XML, SOAP, WSDL, and WSDL Specifications for creating interoperable web services regardless of programming language. Understand how to connect, publish, and interact with applications using XML-encoded data.
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