Mais conteúdo relacionado Mobile Server Platform - Architectures and Protocols for Future M2M Ecosystems2. Outline of Talk
• Research Area in a Nutshell
• Motivation and Research Gap
• The Mobile Server Platform
– The Mobile Web Server Layer
• Architecture, Payload and Performance Aspects
• Multimedia Extensions and Topologies
– The SLA Framework Layer
• Components and Life Cycles
• Performance Analysis
• The Software Application Layer
– MEDICARE – A Context-Aware Health Care Application
– Social Network in Pocket (SNiP)
• Conclusion and Outlook
© Fahad Aijaz, ComNets, RWTH Aachen University 2
3. Research Area in a Nutshell
Today‘s Internet and the WWW Internet of Things = M2M
High-tech Web Servers. M2M Terminal M2M Terminal
Hosts Web Service and Resources. CONSUMER + PROVIDER CONSUMER + PROVIDER
Transparent Access to the Clients.
Neutral towards diverse clients.
Mobile
Web Server
? Consume
Mobile
Web Server
TRANSPARENT
ACCESS
Mobile
Web Services ? Mobile
Web Services
WEB SERVICES
- Specialized functions
- Internal process Publish/Search/ Publish/Search/
- Access interface Outsource Outsource
Web Service
Broker/
Cloud
Computing
- Private Data
- Multimedia
- Websites
RESOURCES Web Server M2M Services
© Fahad Aijaz, ComNets, RWTH Aachen University 3
4. Motivation and Research Gap
Mobile devices are not only mobile phones!
Industrial Automation
1
interaction
2 Automotive / Telemetric
Variable Capabilities & Requirements
access interfaces
PROPERTIES
3 Smart Energy Grids service protection
Only request-response based. Mobile
Immediate service Web Server execution models
invocation, only. 4 Health Care Sector
Short-lived executions. messaging protocols
Respond on same network Mobile 5
infrastructure (blocking Web Services Home Automation
service management
call!).
Runtime service 6 standard operations
management is not possible. Social Networking
data privacy
7
Transform into Web 2.0 Services
M2M Domain Requirements Mobile Server Platform M2M Applications
Provides a general middleware architecture and protocol stack for rapid development of M2M applications
This research gap has been confirmed through literature!
© Fahad Aijaz, ComNets, RWTH Aachen University 4
5. The Mobile Server Platform
(Conceptual Overview)
Health Care | Social Networks
The MSP provides a set of strategically connected architectures
The platforms architecture is categorized into logical layers Applications‘
Offers a Web Services provisioning solution for M2M apps
private data
Software Application Layer
Notification
Service Interaction Strategies
SOAP Access REST Access
Interface Interface XML/REST, JSON/REST
Solicit-Response
SLA Framework Layer WEB SERVICE AGREEMENTS
Request-Response
One-way Mobile Web Server Layer
Server Endpoints
Observer
Instance
Factory
Server Process Classification
Multi-Interfaced Services
Multimedia Delivery & Control
AGREEMENT
PROTECTED Asynchronous Server Endpoints
SERVICES
ASYNCHRONOUS SERVICE
ACCESS PROTOCOL
Multi-Interfaced Mobile Web Services
Synchronous Asynchronous
HTTP/TCP | RTP/UDP | IEEE 802.15.4
Mobile Web Services Mobile Web Services
© Fahad Aijaz
© Fahad Aijaz, ComNets, RWTH Aachen University 5
6. The Mobile Web Server Layer
(Classification of Server Processes)
Mandatory process to consume asynchronous Mobile Web services
Involved Server 1 2
Observer
Instance
Factory
Endpoints
Service Management Process
Service Creation Process
CreateInstance
Create with
Observer EPR
Service Factory
MOBILE WEB SERVICE
2
ASYNCHRONOUS
Request with
Observer EPR
Service Instance 3b
solicit-response / notification
1a
Response with 3a
Instance EPR
Service Observer
mutually exclusive
service invocations
starts 1b
4
Completed
Notification Service Computation Result
Listener (normal completion)
© Fahad Aijaz, ComNets, RWTH Aachen University 6
7. The Mobile Web Server Layer
(Classification of Server Processes)
Only possible subsequent to the Service Creation Process
Service Managemenr Process
STATES OF AN
ASYNCHRONOUS MOBILE WEB SERVICE
Service Creation Process
GetProperties
Unsubscribe open.running
CONTROLLABLE
Subscribe 3
open.notrunning
SetProperties
ChangeState open.notrunning.suspended
Service Instance closed.abnormalCompleted.terminated
Request with
Observer EPR closed.abnormalCompleted
INTERNAL
2
closed.completed
1
Response with closed.abnormalCompleted.aborted
mutually exclusive
Instance EPR
Service Observer service states
ASYNCHRONOUS
MOBILE WEB SERVICE
Notification
Listener GetProperties 4
StateChanged
Events and State Notifications
(solicit-response / notification)
© Fahad Aijaz, ComNets, RWTH Aachen University 7
8. The Mobile Web Server Layer
(SOAP Access Interface Overheads)
Thick Clients Activity Oriented XML Based only! High Payload (WS-*) Processing Overhead
SOAP Access Interface
SOAP Envelope
SOAP CLIENT SOAP SERVER
<SOAP-ENV … > - Receive SOAP Envelope
- Construct Req. SOAP
<SOAP-HEADER …> >
<SOAP-HEADER … - Parse Req. SOAP
- Embed Custom XML <!–- WS-* Specifications
<!–- WS-* Specifications - Parse Embedded XML
- Conform to WS-* Custom XML … -->
Custom XML … --> - Parse WS-*
- Send SOAP Envelope </SOAP-HEADER>
</SOAP-HEADER…> - Process Request
- Receive Response
<SOAP-BODY …> >
<SOAP-BODY … - Construct Resp. SOAP
- Parse Resp. SOAP <!–- WS-* Specifications
<!–- WS-* Specifications - Embed Resp. Custom XML
- Parse Embedded XML Custom XML
Custom XML - Conform to WS-*
- Parse WS-* Complex Types … -->
Complex Types … --> - Send SOAP Envelope
-… </SOAP-BODY>
</SOAP-BODY…> -…
</SOAP-ENV>
Service as a Resource (SaaR) Performance Optimization
?
SERVER
CLIENT
- Receive HTTP Req.
- Construct Payload HTTP Request: GET, POST, PUT, DELETE - Process Request URL
- Send as HTTP Req.
- Send as HTTP Resp.
- Receive Response CUSTOMIZED-PAYLOAD -…
- Parse HTTP Resp.
-…
Think Clients Resource/Activity Oriented Format Neutral WWW-like Access Light-weight
© Fahad Aijaz, ComNets, RWTH Aachen University 8
9. The Mobile Web Server Layer
(SaaR Design Approach)
RE S T Access
Service Provider specifies the mapping semanctics for each method
presentational tate ransfer
Static network resources Every resource Resources
Interface
Network resources
changes the client’s are transferred
Example: HTML, XML, JPG, GIF…
state using HTTP
Synchronous Access URL Service Logic
SYNCHRONOUS URL ELEMENTS
CREATE |POST
HTTP : // IP : PORT / SERVICE / METHOD
READ |GET
mandatory optional UPDATE |PUT
DELETE |DELETE
Asynchronous Access URL
ASYNCHRONOUS URL ELEMENTS
HTTP : // IP : PORT / SERVICE / METHOD / STRATEGY / ENDPOINT / OPERATION
mandatory optional mandatory
© Fahad Aijaz, ComNets, RWTH Aachen University 9
10. The Mobile Web Server Layer
(Payload Optimization)
XML payload comparison of the operations offered by Service Factory Endpoint
SOAP Payload REST Payload
CreateInstanceRs ≈ 82 % reduction
Operations of the Service Factory endpoint
CreateInstanceRq ≈ 67 % reduction
ListInstanceRs ≈ 67 % reduction
ListInstanceRq ≈ 83 % reduction
GetPropertiesRs ≈ 67 % reduction
GetPropertiesRq ≈ 95 % reduction
0 100 200 300 400 500 600 700 800
XML payload in bytes
JSON/REST results in much optimized payload than the XML/REST
© Fahad Aijaz, ComNets, RWTH Aachen University 10
11. The Mobile Web Server Layer
(Prototypical Performance Evaluation)
Mean Latency of the Asynchronous Server with SOAP and XML/REST Interfaces
SOAP Access Interface REST Access Interface
MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS SOAP SERVER MEAN LATENCY AND STANDARD DEVIATION OF THE ASYNCHRONOUS REST SERVER
Asynchronous SOAP Server Asynchronous REST Server
120 55
Mean Mean
110 Standard Deviation 50 Standard Deviation
100
Server Processing Latencies [ms]
76.62 ms
Server Processing Latencies [ms]
45
90 10.71 ms
40
80
35
70 15.8 ms
30
60 -10.71 ms
25
50 6.493 ms
40 20
30 15
20 10
-6.493 ms
10 5
5 10 15 20 25 30 35 40 45 50 5 10 15 20 25 30 35 40 45 50
No. of Requests No. of Requests
Asynchronous Server with the REST Access Interface performs ≈79% faster
© Fahad Aijaz, ComNets, RWTH Aachen University 11
12. The Mobile Web Server Layer
(Basic Analysis of XML and JSON Payloads)
JSON elements XML elements
XML Encoding 25
<R>
<123> </123>
20
S XML 5 2 Broot _ name 5 2 Belement
<123> </123> n
_ name
<123> </123> e 1
...
15
Data in Bytes
</R>
JSON Encoding 7 bytes allocated by the
10
{ XML root tag of 1 byte
7 B
n
"123" : null
S JSON 2 element _ name
"123" : null 5 e 1
"123" : null
2 bytes allocated by the start
... and end braces of JSON element
} 0
© Fahad Aijaz, ComNets, RWTH Aachen University 12
13. The Mobile Web Server Layer
(Basic Analysis of XML and JSON Payloads)
Difference trend with 25 elements Difference trend with 210 elements
S XML S JSON
0.35 11
3 bytes 10.5 3 bytes
0.325
8 bytes 10 8 bytes
0.3 13 bytes > 0.325 9.5 13 bytes ≈ 10.5
18 bytes
MB 9 18 bytes MB
0.275 23 bytes 8.5 23 bytes
0.25 8
7.5
Difference in Payload (MB)
Difference in Payload (MB)
0.225 7
6.5
0.2
6
0.175 5.5
5
0.15
4.5
0.125 4
3.5
0.1
3
2.5
0.075
< 0.025 2 ≈ 0.5
0.05 MB 1.5 MB
0.025 1
0.5
2 4 8 16 32 2 4 8 16 32 64 128 256 512 1024
No. of Elements No. of Elements
JSON results in less data transmission as number of elements increase
Lengthy element names result in much rapid increase is payload
JSON/REST for M2M terminals Less computation requirements
© Fahad Aijaz, ComNets, RWTH Aachen University 13
14. The Mobile Web Server Layer
(Multimedia Extensions and Topologies)
Integration of RTSP and RTP Extended RTSP States in Asynchronous Server
Offers a Web Service provisioning solution through M2M terminals
Software Application Layer
Mobile Web Server Layer
Observer
Instance
Factory
Multi-Interfaced Mobile Web Services
Delivery Resource Asynchronous Services Control Resource Synchronous and Asynchronous Services
Multimedia Delivery Strategy RTP/UDP Multimedia Control Strategy RTSP/TCP
The RTSP SETUP, PLAY, PAUSE and TEARDOWN are exposed as states of asynchronous services
The RTSP OPTIONS and DESCRIBE methods are exposed as synchronous mobile Web Services
© Fahad Aijaz, ComNets, RWTH Aachen University 14
15. The Mobile Web Server Layer
(Multimedia Extensions and Topologies)
Relayed Delivery and Relayed Control
Multimedia Delivery Strategy RTP/UDP
Multimedia Control Strategy RTSP/TCP
Synchronous and Asynchronous Servers work together
Relays Control INTERMEDIATE KNOWN PUBLIC IP/PORT
Relays Multimedia ACCESS GATEWAY Server
Client
TCP TUNNEL
Server Layer
Mobile Web
Mobile Web
Server Layer
CONTROL HOLE
HOLE
CHANNEL PUNCHING
PUNCHING
RTSP/TCP RTSP/REST
TCP
TCP
RTP/UDP RTP/UDP
UDP INTERNET UDP
NAT/ DELIVERY NAT/
FIREWALL CHANNEL FIREWALL
PRIVATE IP/PORT PRIVATE IP/PORT
Works with every network where interaction are enabled!
Sequence of events during the TCP/UDP
1 Server establishes a permanent TCP tunnel with the IAG TCP hole punching
2 The client sends RTSP SETUP to the IAG IAG relays it to server SCP response
3 Only client sends UDP to IAG IAG is not introducer gateway sends keep-alive to client
4 Client sends RTSP PLAY to IAG IAG relays it to server Service Management Process
5 Server indirectly delivers media over the RTP/UDP channel that is relayed by the IAG
6 Client may send RTSP PAUSE, TEARDOWN via IAG Service Management Process
© Fahad Aijaz, ComNets, RWTH Aachen University 15
16. The SLA Framework Layer
(Conceptual Overview)
Extends the Mobile Web Server Layer
The functions of the SLA architecture are classified
into 4 distinct life cycles
Service Level Agreements Framework
The SLA life cycles are executed based on the
incoming mobile Web Service requests
The SLA negotiation is based on
the Web Service Agreement
4 LIFE CYCLES OF THE
standard of the Open Grid
Forum
SLA FRAMEWORK
The standard is
optimized to define
the SLA messaging
for mobile nodes Agreement Offer Service Invocation
Agreement Agreement QoS Disposal
Life Cycle Life Cycle
The SLA framework Creation Evaluation Monitoring Monitoring
is compatible with (AC) (AE) (QM) (DM)
the REST and SOAP
access interfaces
Protects both, the Template Agreement
Acquisition Disposal
synchronous and Life Cycle Life Cycle
asynchronous services
The life cycles utilize the properties of the Synchronous and Asynchronous Servers
© Fahad Aijaz, ComNets, RWTH Aachen University 16
17. The SLA Framework Layer
(Life Cycles)
Template Aquisition Life Cycle
1 MOBILE WEB SERVICE
CLIENTS
A) Reads and manipulates the template
MOBILE WEB SERVICE
HOST
PROTECTED
MOBILE WEB SERVICE
A) Associated agreement
B) Generates a UUID for the client
Agreement C) Saves a copy against the UUID
SLA Mobile Server template with validity
B) Must be used before expiry
Creation REST REQUEST C) Automated deletion
http://xperia.comnets.de:9090/FetchTemplate
(AC)
1 FETCH TEMPLATE AC FT
AGREEMENT TEMPLATE 2 SERVICE PROVIDER’S
Template
UUID + AGREEMENT TEMPLATE -- -- AGREEMENT TEMPLATE
Acquisition Stored in the mobile
Life Cycle ! host or the cloud
FETCH TEMPLATE
SYNCHRONOUS
MOBILE WEB SERVICE
Agreement Offer Life Cycle
2 MOBILE WEB SERVICE
CLIENTS
A) Verify the UUID of the client
B) Notify the requesting client
C) Transitions to the evaluation
MOBILE WEB SERVICE
HOST
Agreement phase (if verified)
SLA Mobile Server
Creation
(AC) A) Reads the agreement terms
B) Prepares an agreement offer
3 AGREEMENT OFFER + UUID AC
UUID
C) Sends the agreement offer as NOTIFICATION Verification
an asynchronous request
a) Agreement creation phase is completed
Agreement Offer ! b) Agreement evaluation phase is started
Life Cycle
Agreement AGREEMENT ACCEPT/REJECT 4 AE Offer
Evaluation
Evaluation A) Evaluate the agreement offer against -- --
the related template
(AE) AGREEMENT AGREEMENT
B) Accept or reject the agreement offer
TEMPLATE OFFER
NEGOTIATED C) Save a copy (if accepted) & notify PROTECTED
AGREEMENT the client MOBILE WEB SERVICE
© Fahad Aijaz, ComNets, RWTH Aachen University 17
18. The SLA Framework Layer
(Life Cycles)
Template Aquisition Life Cycle
1 MOBILE WEB SERVICE
CLIENTS
A) Reads and manipulates the template
MOBILE WEB SERVICE
HOST
PROTECTED
MOBILE WEB SERVICE
A) Associated agreement
B) Generates a UUID for the client
Agreement C) Saves a copy against the UUID
SLA Mobile Server template with validity
B) Must be used before expiry
Creation REST REQUEST C) Automated deletion
http://xperia.comnets.de:9090/FetchTemplate
(AC)
1 FETCH TEMPLATE AC FT
AGREEMENT TEMPLATE 2 SERVICE PROVIDER’S
Template
UUID + AGREEMENT TEMPLATE -- -- AGREEMENT TEMPLATE
Acquisition Stored in the mobile
Life Cycle ! host or the cloud
FETCH TEMPLATE
SYNCHRONOUS
MOBILE WEB SERVICE
Agreement Offer Life Cycle
2 MOBILE WEB SERVICE
CLIENTS
A) Verify the UUID of the client
B) Notify the requesting client
C) Transitions to the evaluation
MOBILE WEB SERVICE
HOST
Agreement phase (if verified)
SLA Mobile Server
Creation
(AC) A) Reads the agreement terms
B) Prepares an agreement offer
3 AGREEMENT OFFER + UUID AC
UUID
C) Sends the agreement offer as NOTIFICATION Verification
an asynchronous request
a) Agreement creation phase is completed
Agreement Offer ! b) Agreement evaluation phase is started
Life Cycle
Agreement AGREEMENT ACCEPT/REJECT 4 AE Offer
Evaluation
Evaluation A) Evaluate the agreement offer against -- --
the related template
(AE) AGREEMENT AGREEMENT
B) Accept or reject the agreement offer
TEMPLATE OFFER
NEGOTIATED C) Save a copy (if accepted) & notify PROTECTED
AGREEMENT the client MOBILE WEB SERVICE
© Fahad Aijaz, ComNets, RWTH Aachen University 18
19. The SLA Framework Layer
(Conceptual Overview)
Service Invocation Life Cycle
3
A) Verify and evaluate request
MOBILE WEB SERVICE MOBILE WEB SERVICE
against the negotiated agreement
CLIENTS HOST
B) Verify the usage limit & the usage
interval (default)
C) Invoke or schedule the service SLA Mobile Server
D) Initiate the QoS monitoring
5 SERVICE INVOCATION + UUID AE Verification
NOTIFICATION
For asynchronous services
Service Invocation Evaluation
Agreement QoS only!
QoS VIOLATIONS
Life Cycle QM
Evaluation Monitoring QoS
(AE) (QM) SERVICE RESPONSE 6
Handlers
-- --
A) Service provider specifies the QoS
handlers during deployment
B) Reads the service settings Third-party QoS
C) Starts the associated QoS handlers ! handlers are possible
D) QoS handlers monitors and reacts
upon QoS violations
Agreement Disposal Life Cycle
4 MOBILE WEB SERVICE
CLIENTS
Automatic disposal
MOBILE WEB SERVICE
HOST
Disposal ! is a default process
SLA Mobile Server
Monitoring
(DM) 3 AGREEMENT DISPOSAL + UUID DM Verification
Explicit disposal requests are possible only from the
! permitted clients through the client-controlled process. Settings
DISPOSAL RESPONSE 4 Disposal
Agreement A) Offers periodic cleanup cycles in automatic disposal
Disposal B) Looks for the expired agreements and templates
-- --
Life Cycle C) Takes the agreement validity (end date) and usage limit
as the expiration criteria
D) Disposes agreements, templates and client records (e.q. UUID) Agreements and Agreement
E) Shared process for all agreements and templates ! Templates to dispose
© Fahad Aijaz, ComNets, RWTH Aachen University 19
20. The SLA Framework Layer
(Conceptual Overview)
Service Invocation Life Cycle
3
A) Verify and evaluate request
MOBILE WEB SERVICE MOBILE WEB SERVICE
against the negotiated agreement
CLIENTS HOST
B) Verify the usage limit & the usage
interval (default)
C) Invoke or schedule the service SLA Mobile Server
D) Initiate the QoS monitoring
5 SERVICE INVOCATION + UUID AE Verification
NOTIFICATION
For asynchronous services
Service Invocation Evaluation
Agreement QoS only!
QoS VIOLATIONS
Life Cycle QM
Evaluation Monitoring QoS
(AE) (QM) SERVICE RESPONSE 6
Handlers
-- --
A) Service provider specifies the QoS
handlers during deployment
B) Reads the service settings Third-party QoS
C) Starts the associated QoS handlers ! handlers are possible
D) QoS handlers monitors and reacts
upon QoS violations
Agreement Disposal Life Cycle
4 MOBILE WEB SERVICE
CLIENTS
Automatic disposal
MOBILE WEB SERVICE
HOST
Disposal ! is a default process
SLA Mobile Server
Monitoring
(DM) 3 AGREEMENT DISPOSAL + UUID DM Verification
Explicit disposal requests are possible only from the
! permitted clients through the client-controlled process. Settings
DISPOSAL RESPONSE 4 Disposal
Agreement A) Offers periodic cleanup cycles in automatic disposal
Disposal B) Looks for the expired agreements and templates
-- --
Life Cycle C) Takes the agreement validity (end date) and usage limit
as the expiration criteria
D) Disposes agreements, templates and client records (e.q. UUID) Agreements and Agreement
E) Shared process for all agreements and templates ! Templates to dispose
© Fahad Aijaz, ComNets, RWTH Aachen University 20
21. Performance Analysis
(Service Creation Process)
Synchronous Server Asynchronous Server
5
4
Completed
Completed
Create Service Invoke Service Web Service Parse Create Service Invoke Service
Web Service Parse
Request Object Method Request Request Object Method
Request SERVER RUNNING
SERVER PROCESSING READY RUNNING PROCESSING READY
1 2 3 1 2
Request
Timer
Dispatch Dispatch Invoke Service
Terminate 6 5 Terminate 7 6 Terminate Notify 4
Result Result Method
RESPONSE RESPONSE NOTIFY WAITING
Until the service Until the Service Instance
! object is created ! endpoint is created
Web Service Parse Create Service
Request Request Object
SERVER PROCESSING READY
1 2
d parse d obj
Ds Dc
© Fahad Aijaz, ComNets, RWTH Aachen University 21
22. Performance Analysis
(Service Creation Process)
Asynchronous SCP with SOAP Synchronous SCP with SOAP
<SOAP-ENV:Envelope <SOAP-ENV:Envelope
… xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/
<SOAP-ENV:Header>
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>
<wsa:To> http://xperia.comnets.de </wsa:To>
<SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<wsa:Action> soaprpc</wsa:Action>
<wsa:MessageId>ffb471ec-194-1cb37664-125c53c2</wsa:MessageId>
<wsa:ReplyTo> <echoService xmlns="urn:Services" id="o0" SOAP-ENC:root="1">
<wsa:Address> http://schemas.xmlsoap.org/ws/.../role/anonymous </wsa:Address> <ServiceType xmlns="" xsi:type="xsd:string">Synchronous</ServiceType>
</wsa:ReplyTo>
<as:FactoryEPR>http://xperia.comnets.de/factory</as:FactoryEPR> <ContextData xmlns="" xsi:type="xsd:ContextData">
</SOAP-ENV:Header> <!-- user-defined input XML elements -->
<SOAP-ENV:Body SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> </ContextData>
<GPSLocation> </echoService>
<ServiceType>Asynchronous</ServiceType>
<createInstanceRq xmlns="" xsi:type=":createInstanceRq">
</SOAP-ENV:Body>
<StartImmediately xsi:type="xsd:boolean">true</StartImmediately>
</SOAP-ENV:Envelope>
<ObserverEPR xsi:type="xsd:string">
http://tattoo.comnets.de/3466b6a-0df-5fe9ad
</ObserverEPR> ein est ek syn
<Name xsi:type="xsd:string">GPS Location</Name>
<Subject xsi:type="xsd:string"> Create Service Instance </Subject>
<Description xsi:type="xsd:string">
Provides GPS coordinates of the host mobile
d
syn
X DS ein est esyn d obj
</Description> soap
syn
<ContextData xsi:type=“xsd:ContextData"> d p a rse
</ContextData>
<!– user-defined input XML elements -->
syn
Dc
X DS ein est easyn d obj
</createInstanceRq>
asyn
</GPSLocation>
</SOAP-ENV:Body>
d soap
a syn
</SOAP-ENV:Envelope> d p a rse
ein est ek asyn
a syn
Dc
© Fahad Aijaz, ComNets, RWTH Aachen University 22