Distributed Embedded Systems Computer Architecture and Operating Systems 2
Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages
Web Services Introduction Web services: service-based middleware optimized for the internet flexible calling of remote services via the internet creation of complex applications by the composition of services UDDI Service Registry/Broker Internet Web Application Server Client PC
Web Services Introduction Using web services UDDI Service Registry/Broker 2: return service handle UDDI protocol 1: Send service description WSDL File Internet Client PC Web Application Server SOAP XML 3: Send SOAP request SOAP XML 4: Send SOAP answer e.g. HTTP protocol
Web Services UDDI Founded by IBM, Ariba, and Microsoft Service publishing and discovery Based on other web service technologies: WSFL UDDI WSDL service interactions service publishing & discovery service description SOAP XM-based messaging HTTP, ftp, IIOP, etc. network protocol
Web Services UDDI Categorization of services using predefined taxonomies UDDI defines the protocol used to communicate with a service registry/broker UDDI messages are defined in XML, wrapped in a SOAP frame and send via HTTP 1: publish tmodels SW Companies, Standardization bodies, etc. 3: UDDI assigns a unique UUID to each tmodel and each service 4: Applications request the services 2: publish services UDDI Service Registry/ Broker Businesses
Web Services UDDI The UDDI Service Registry/Broker uses a standardized data model to specify a registered service: 1. businessentity: description of publishing party 2. businessservice: service description 3. bindingtemplate: description of a service s API used to access the service on a technical level 4. tmodels: categories and taxonomies used by the other parts of the data model
Web Services UDDI The UDDI Service Registry/Broker uses a standardized data model to specify a registered service: 1. businessentity: description of publishing party 2. businessservice: service description 3. bindingtemplate: description of a service s API used to access the service on a technical level 4. tmodels: categories and taxonomies used by the other parts of the data model
Web Services UDDI Example 1 The UDDI Service Registry/Broker uses a standardized data model to specify a registered service: 1. businessentity: description of publishing party 2. businessservice: service description 3. bindingtemplate: description of a service s API used to access the service on a technical level 4. tmodels: categories and taxonomies <overviewdoc> used by the other parts of the data model <tmodel xmlns="urn:uddi-org:api" tmodelkey="uuid:aaaaaaaa-aaaa-aaaa- AAAA-AAAAAAAAAAAA"> <name>hs-owl:add_42</name> <description xml:lang="en">add the (sic) number</description> <overviewurl>http://schema.com/add42.wsdl</overviewurl> </overviewdoc> <categorybag> <keyedreference tmodelkey="uuid:cd253352-186b-4532-c53f-6bdad766635" keyname="number adding services" keyvalue="84.14.16.01.00"/> <keyedreference tmodelkey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyname="types" keyvalue="nonsense sevices"/> </categorybag> </tmodel>
Web Services UDDI Example 1 The UDDI Service Registry/Broker uses a standardized data model to specify a registered service: 1. businessentity: description of publishing party 2. businessservice: service description 3. bindingtemplate: description of a service s API used to access the service on a technical level 4. tmodels: categories and taxonomies <overviewdoc> used by the other parts of the data model <tmodel xmlns="urn:uddi-org:api" tmodelkey="uuid:aaaaaaaa-aaaa-aaaa- AAAA-AAAAAAAAAAAA"> <name>hs-owl:add_42</name> The WSDL reference <description xml:lang="en">add the (sic) number</description> <overviewurl>http://schema.com/add42.wsdl</overviewurl> </overviewdoc> <categorybag> <keyedreference tmodelkey="uuid:cd253352-186b-4532-c53f-6bdad766635" keyname="number adding services" keyvalue="84.14.16.01.00"/> <keyedreference tmodelkey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyname="types" keyvalue="nonsense sevices"/> </categorybag> </tmodel> The pointer to an element in a user-defined taxonomy The pointer to an element in the "wsdlspec" type in the uddiorg:types (UUID:C1ACF26D...)
Web Services Predefined taxonomies (tmodels): tmodels 1. ISO 3166 Geographic Taxonomy: Geographical locations <businessentity businesskey=...... <categorybag> <!-- Categorize this businessentity as serving California using the ISO 3166 taxonomy --> <keyedreference keyname="california, USA" keyvalue="us-ca" tmodelkey="uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88"/> </categorybag>... </businessentity> 2. Universal Standard Products and Services Classification (UNSPSC) <businessentity businesskey=...... <categorybag> <keyedreference keyname="domestic Air Cargo Transport" keyvalue="78.10.15.01.00" tmodelkey = "uuid:cd153257-086a-4237-b336-6bdcbdcc6634"/> </categorybag>... </businessentity>
Web Services UDDI Example 1 The UDDI Service Registry/Broker uses a standardized data model to specify a registered service: 1. businessentity: description of publishing party 2. businessservice: service description 3. bindingtemplate: description of a service s <businessservice API used to access the service on a technical level 4. tmodels: categories and taxonomies used by the other parts of the data model businesskey="bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb" servicekey="cccccccc-cccc-cccc-cccc-cccccccccccc"> <name>owl Add 42 Instance</name> <bindingtemplates> <bindingtemplate servicekey="cccccccc-cccc-cccc-cccc-cccccccccccc" bindingkey="dddddddd-dddd-dddd-dddd-dddddddddddd"> <accesspoint URLType="https">https://hs-owl.de/add42</ accesspoint> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uuid:aaaaaaaa-aaaa-aaaa-aaaa- AAAAAAAAAAAA"/> <tmodelinstancedetails> </bindingtemplate> </bindingtemplates </businessservice>
Web Services Stub/Proxy/Skeleton Pattern Client Server Proxy Skeleton Dispatcher Middleware Middleware Processor Communication Driver Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern Client The client is just your everyday program; nothing related to distributed systems is used. Server Proxy Skeleton Dispatcher Middleware Middleware Processor Communication Driver Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern Client Proxy Server The proxy replaces the server component the client side. From the client point of view, the proxy is the the server component. Skeleton It(de-)serializes the method calls and object accesses. It also translates between middleware API and proxy. Dispatcher Middleware Middleware Processor Communication Driver Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern Client Server Proxy Skeleton Dispatcher Processor Middleware The dispatcher chooses the right server components, i.e. its skeleton. Communication Driver Middleware Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern Client Server Proxy The skeleton translates between server API and middleware. It also handles parallel accesses. The skeleton (de-)serializes the method calls and object accesses. Middleware Skeleton Dispatcher Middleware Processor Communication Driver Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern The server is just your everyday program; nothing related to distributed systems is used. Client Server Proxy Skeleton Dispatcher Middleware Middleware Processor Communication Driver Communication Driver Processor Communication System
Web Services Stub/Proxy/Skeleton Pattern Proxy and/or skeletons are often also called stubs. The binding between client and server can either be static or dynamic: Static binding means that the references between client and servers are statically defined at compile-time. Dynamic binding means that references are established at run-time via a broker/repository. Distributed system may either use compile-time or run-time objects. Compile-time objects are instances of classes/ interfaces which have been defined at compile-time. Run-time objects are constructed at run-time via reflection mechanisms. If distributed systems are cross-language (e.g. CORBA), object adapters are used to translate between the languages.
SOAP Introduction Protocol for the exchange of structured data. Data is expressed in form of an XML document. SOAP normally used TCP and HTTP/HTTPS as underlying protocols. SOAP defines how data can be expressed and how remote calls are modeled History: Dave Winer and Microsoft developed 1998 XML-RPC SOAP V1.0 1999 SOAP V1.2: W3C recommendation 2003
SOAP Message Structure Messages are transmitted in an envelope <?xml version="1.0"?> <s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:header> </s:header> <s:body> </s:body> </s:envelope> The header comprises application-specific meta information about a message (transaction IDs, authentication, etc.). The main message data is in the body.
SOAP Message Structure Example: Ask a database if a specific wine is on storage Request: <?xml version="1.0"?> <s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:body> <m:bottleinstorage xmlns:m="http://www.wine-store.de/soap"> Brunello di Montalcino </m: BottleInStorage> </s:body> </s:envelope> Answer: <?xml version="1.0"?> <s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:header> <m:requestid xmlns:m="http://www.wine-store.de/soap">c4f7d603e</m:requestid> </s:header> <s:body> <m:dbresponse xmlns:m="http://www.wine-store.de/soap"> <m:title value="brunello di Montalcino"> <m:choice value="1">il Poggione, 1998</m:Choice> <m:choice value="2">castello Banfi, 1999</m:Choice> </m:title> </m:dbresponse> </s:body> </s:envelope>
WSDL Introduction WSDL (Web Service Description Language) is an XML Schema to describe web services. WSDL V2.0 is a W3C recommendation Structure of a WSDL 2.0 document: 1. Abstract Section: Meta-Level 1.1 Types (aka messages): Data Types described as an XML Schema 1.2 Interfaces (aka porttype): Interfaces implemented by the services 1.2.1 Operation: Operations/methods including input and output parameters, parameters types are defined in 1.1 2. Concrete Section: Instance-Level 2.1 Binding: Interfaces from 1.2 used by the service, transport protocol 2.2 Service 2.2.1 Endpoints: The address (e.g. URL) of the service
WSDL Example Find wine in a database...
WSDL Example <?xml version="1.0" encoding="utf-8" standalone="no"?> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http:// www.example.org/findwine/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http:// www.w3.org/2001/xmlschema" name="findwine" targetnamespace="http://www.example.org/findwine/"> <wsdl:types> <xsd:schema targetnamespace="http://www.example.org/findwine/"> <xsd:element name="findwine"> <xsd:complextype> <xsd:sequence> <xsd:element name="in" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="findwineresponse"> <xsd:complextype> <xsd:sequence> <xsd:element name="out" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="findwine" type="xsd:string"></xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="findwinerequest"> <wsdl:part element="tns:findwine" name="parameters"/> </wsdl:message> <wsdl:message name="findwineresponse"> <wsdl:part element="tns:findwineresponse" name="parameters"/> </wsdl:message>
WSDL Example <wsdl:porttype name="findwine"> <wsdl:operation name="findwine"> <wsdl:input message="tns:findwinerequest"/> <wsdl:output message="tns:findwineresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="findwinesoap" type="tns:findwine"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="findwine"> <soap:operation soapaction="http://www.example.org/findwine/findwine"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="findwine"> <wsdl:port binding="tns:findwinesoap" name="findwinesoap"> <soap:address location="http://www.example.org/"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
SOAP SOAP & Eclipse Install Eclipse JEE Edition Install Tomcat Server and add Tomcat as a server platform to Eclipse.
SOAP SOAP & Eclipse Create your service implementation. E.g. use a normal Java project for this.
SOAP SOAP & Eclipse Create WebServices for this class. Eclipse can do this by invoking the WebService context menu on the Java class. When asked, also create a test client application.
SOAP SOAP & Eclipse The generated WSDL file (as a graphic):
SOAP SOAP & Eclipse The generated WSDL file (as a XML file):
SOAP SOAP & Eclipse The generated server application knows about the mapping between our Java program and the service.
SOAP SOAP & Eclipse For the generated client application, several java classes have been generated.
SOAP SOAP & Eclipse General structure on the client side (simplified!): Client Application uses AddClassProxy implements AddClass Interface uses ask for SOAP dispatcher return handle to AddClassSoapBindingStub AddClassServiceLocator AddClassSoapBindingStub uses SOAP Middleware (Axis)
SOAP SOAP & Eclipse Client application implemented in JavaServer Pages (JSP): Result.jsp <jsp:usebean id="sampleaddclassproxyid" scope="session" class="defaultnamespace.addclassproxy" /> <% if (request.getparameter("endpoint")!= null && request.getparameter("endpoint").length() > 0) sampleaddclassproxyid.setendpoint(request.getparameter("endpoint")); Connect to Java class %>... case 13: gotmethod = true; String x_1id= request.getparameter("x16"); int x_1idtemp = Integer.parseInt(x_1id); int add_4213mtemp = sampleaddclassproxyid.add_42(x_1idtemp); String tempresultreturnp14 = org.eclipse.jst.ws.util.jsputils.markup(string.valueof(add_4213mtemp)); %> <%= tempresultreturnp14 %> Calls method <% break;
SOAP SOAP & Eclipse AddClass.java: /** * AddClass.java * * This file was auto-generated from WSDL * by the Apache Axis 1.4 Apr 22, 2006 (06:55:48 PDT) WSDL2Java emitter. */ package DefaultNamespace; public interface AddClass extends java.rmi.remote { public int add_42(int x) throws java.rmi.remoteexception; } Our server class is now an interface on the client side.
SOAP SOAP & Eclipse AddClassProxy.java: Proxy Class This class implements the interface, it is the proxy for the server class on the client side. package DefaultNamespace; public class AddClassProxy implements DefaultNamespace.AddClass { private DefaultNamespace.AddClass addclass = null;... private void _initaddclassproxy() { try { addclass = (new DefaultNamespace.AddClassServiceLocator()).getAddClass(); Get SOAP stub class. if (addclass!= null) { if (_endpoint!= null) ((javax.xml.rpc.stub)addclass)._setproperty("javax.xml.rpc.service.endpoint.address", _endpoint); else _endpoint = (String)((javax.xml.rpc.Stub)addClass)._getProperty("javax.xml.rpc.service.endpoint.address"); } } catch (javax.xml.rpc.serviceexception serviceexception) {} }... public int add_42(int x) throws java.rmi.remoteexception{ if (addclass == null) _initaddclassproxy(); return addclass.add_42(x); }} Redirect to stub class.
SOAP SOAP & Eclipse AddClassServiceLocator.java: SOAP-specific dispatcher class package DefaultNamespace; public class AddClassServiceLocator extends org.apache.axis.client.service implements DefaultNamespace.AddClassService {... // Use to get a proxy class for AddClass private java.lang.string AddClass_address = "http://localhost:8080/webserviceproject/services/addclass"; The URI public java.lang.string getaddclassaddress() { return AddClass_address; } // The WSDD service name defaults to the port name. private java.lang.string AddClassWSDDServiceName = "AddClass"; Service Name
SOAP SOAP & Eclipse AddClassServiceLocator.java public DefaultNamespace.AddClass getaddclass() throws javax.xml.rpc.serviceexception { java.net.url endpoint; } try { endpoint = new java.net.url(addclass_address); } catch (java.net.malformedurlexception e) { } throw new javax.xml.rpc.serviceexception(e); return getaddclass(endpoint); public DefaultNamespace.AddClass getaddclass(java.net.url portaddress) throws } javax.xml.rpc.serviceexception { try { DefaultNamespace.AddClassSoapBindingStub _stub = new DefaultNamespace.AddClassSoapBindingStub(portAddress, this); _stub.setportname(getaddclasswsddservicename()); return _stub; } catch (org.apache.axis.axisfault e) { } return null; Get SOAP stub
SOAP AddClassSoapBindingStub.java public int add_42(int x) throws java.rmi.remoteexception {... org.apache.axis.client.call _call = createcall(); _call.setoperation(_operations[0]); _call.setusesoapaction(true); _call.setsoapactionuri(""); SOAP & Eclipse _call.setencodingstyle(null); _call.setproperty(org.apache.axis.client.call.send_type_attr, Boolean.FALSE); _call.setproperty(org.apache.axis.axisengine.prop_domultirefs, Boolean.FALSE); _call.setsoapversion(org.apache.axis.soap.soapconstants.soap11_constants); _call.setoperationname(new javax.xml.namespace.qname("http://defaultnamespace", "add_42")); setrequestheaders(_call); setattachments(_call); Dispatcher for method Marchalling try { java.lang.object _resp = _call.invoke(new java.lang.object[]{new java.lang.integer(x)}); if (_resp instanceof java.rmi.remoteexception) { throw (java.rmi.remoteexception)_resp; } else { extractattachments(_call); try { return ((java.lang.integer) _resp).intvalue(); } catch (java.lang.exception _exception) { return ((java.lang.integer) org.apache.axis.utils.javautils.convert(_resp, int.clas } } } catch (org.apache.axis.axisfault axisfaultexception) { throw axisfaultexception;
SOAP SOAP & Eclipse When Monitoring the Traffic has been chosen for the generation process, the SOAP traffic can be also seen:
SOAP SOAP & Eclipse The request message:
SOAP SOAP & Eclipse The response message: