Is XML-RPC the right model?

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 Transportation: • performance: • latency • bandwidth • service type: • sync/async • guaranteed delivery • security: • identity • encryption • transactions • encapsulation • interoperability • ... • Data Representation: • transformation • presentation • interpretation • interrogation • interoperation • portability • reuse • internationalization • ...

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 ... XML as a data representation

RPC: (typically) binary representation protocol model transport dependent programming language centric not extensible secure robust not easily transformed It’s implementation-centric XML: text representation document/message model transport independent language independent extensible not secure (yet) not robust easily transformed It’s application-centric RPC Vs XML

Appl icat ion XML RDBMS RPC App Vs Implementation Implementation

Pros: 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 … Cons: it’s XML based it uses HTTP(S) it’s too simple! It’s RPC based … XML-RPC ...

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, point-to-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

Is XML-RPC the right model?