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! Convince you that my problem is your problem! Explain why a standard solution is crucial Explain why a standard solution is crucial Suggest that XML-RPC isnt sufficent Suggest that XML-RPC isnt sufficent explore the requirements of the real solution explore the requirements of the real solution

XML based Internet APM

Common beliefs? HTTP(S) is the transport for the Internet HTTP(S) is the transport for the Internet XML is (increasingly) the data representation for exchange of data between loosely coupled (hetrogeneous) systems 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 (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 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: Data Representation: – transformation – presentation – interpretation – interrogation – interoperation – portability – reuse – internationalization –... Data Transportation: Data Transportation: – performance: latency bandwidth – service type: sync/async guaranteed delivery – security: identity encryption – transactions – encapsulation – interoperability –...

XML as a data representation Pro: Pro: – (verifiable) universal, self- describing, extensible syntax – I18N “ready” – namespace support (composition) – transport independent –... Con: Con: – not time/space efficient – not intrinsically secure – no transaction support – no transport semantics –...

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

App Vs Implementation Implementation ApplApplicaticationionApplApplicaticationion XML RPC RDBMS

XML-RPC... Pros: 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: Cons: – 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 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: 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 (exclusively) bound to HTTP(S) should not be bound to a particular transport “semantic” (RPC) 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 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 should not mix data, behavior, and protocol in the markup......

What should we define? An XML based exchange protocol that: 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 self-describing according to public (vertical) XML schemas Data is delivered (bound) via an appropriate transport Data is delivered (bound) via an appropriate transport the implementation of the behavior is abstracted the implementation of the behavior is abstracted loosely-coupled applications are possible since applications can deal with schema evolution loosely-coupled applications are possible since applications can deal with schema evolution