Is XML-RPC the right model?
Larry Cable,
CTO,
iPlanet Application Server
What am I here for?
• Convince you that my problem is your
problem!
• Explain why a standard solution is crucial
• Suggest that XML-RPC isnt sufficent
• explore the requirements of the real solution
XML based Internet APM
Common beliefs?
• HTTP(S) is the transport for the Internet
• XML is (increasingly) the data representation
for exchange of data between loosely coupled
(hetrogeneous) systems
• (Traditional) RPC protocols and MOM will
continue to be used in intra/extranet
deployments because they exhibit useful
properties that are not (yet) available from
HTTP(S) or XML
What is the problem statement?
• Define a mechanism to enable the efficient
transfer of a broad range of structured data
between hetrogeneous, distributed
applications over inter/extra/intranets using a
variety of transports
What’s the problem? …
• Data Representation:
– transformation
– presentation
– interpretation
– interrogation
– interoperation
– portability
– reuse
– internationalization
– ...
• Data Transportation:
– performance:
• latency
• bandwidth
– service type:
• sync/async
• guaranteed delivery
– security:
• identity
• encryption
– transactions
– encapsulation
– interoperability
– ...
XML as a data representation
• Pro:
– (verifiable) universal, self–
–
–
–
describing, extensible
syntax
I18N “ready”
namespace support
(composition)
transport independent
...
• Con:
–
–
–
–
–
not time/space efficient
not intrinsically secure
no transaction support
no transport semantics
...
RPC Vs XML
• RPC:
– (typically) binary
–
–
–
representation
protocol model
transport dependent
programming language
centric
not extensible
secure
robust
not easily transformed
–
–
–
–
• It’s implementationcentric
• XML:
– text representation
– document/message
–
–
model
transport
independent
language
independent
extensible
not secure (yet)
not robust
easily transformed
–
–
–
–
• It’s applicationcentric
App Vs Implementation
A
p
p
l
i
c
a
t
i
o
n
XML
RPC
Implementation
RDBMS
XML-RPC ...
• Pros:
• Cons:
–
–
–
–
–
–
–
–
–
it’s XML based
it uses HTTP(S)
it’s (quite) simple
it’s based around an RPC
model which is (hopefully)
a well understood concept
–…
it’s XML based
it uses HTTP(S)
it’s too simple!
It’s RPC based
…
What’s important?
• Isolate application(s) from schema evolution
– use the power of XML to create application-centric
markups and exchange those between applications
• separate the data being exchanged from:
– the transport protocol characteristics
– the semantics to be applied to the data
– the security model
– the transaction model
– the encapsulation model
– ...
XML-RPC … why it’s not the right
solution
• should not be (exclusively) bound to HTTP(S)
• should not be bound to a particular transport
“semantic” (RPC)
• should not define a markup language based
upon a (meta) programming language type
system this is not using XML’s best feature!
• should not mix data, behavior, and protocol in
the markup
• ...
What should we define?
• An XML based exchange protocol that:
– allows application(s) to embed their own
application-specific XML (schema-defined)
documents within it
– allows these encapsulated messages to be
delivered across a variety of transports (RPC, pointto-point messaging, publish and subscribe, …)
– separates the behavior from the state
– can also contain other associated information
– has bindings to particular transports such as
HTTP(S)
What does this enable?
• Data is self-describing according to public
(vertical) XML schemas
• Data is delivered (bound) via an appropriate
transport
• the implementation of the behavior is
abstracted
• loosely-coupled applications are possible
since applications can deal with schema
evolution