xml-dev - XML IDL and XML RPC

[Joe Lapp <jlapp@webmethods.com>]

(This is a renaming of the thread titled "Corba data -> XML")

At 03:55 PM 9/22/1998 -0700, G. David Kuhlman wrote:
>All these proposals (WebMethods, WebBroker, and also ILU http) seem
>to revolve around the same thing [...]
>Has anyone done a comparison of them.  Are they all replacements
>for CORBA and DCOM?  That would be great; CORBA is way too complex. 

I'll give a brief lo-down on the webMethods architecture.  It's
really very simple by comparison to conventional architectures.
These are the workings of the webMethods Business-to-Business
Integration Server (B2B):

(1) The object and method are given in the URL.  Our terminology
uses the terms "interface" and "service," but both of these terms
are somewhat overloaded so "object" and "method" do a better job
of explaining what we've done.  We also support naming the method
within the request message (outside the URL).

(2) Interface specifications are defined using WIDL.  Once you
have a spec you can use it to either generate code for various
programming languages (client or server).  It's a very simple
IDL that has proven amazingly useful despite its simplicity.
This has sort of become a theme for webMethods -- we focus
primarily on solutions that are both powerful and simple.

(3) An RPC occurs as an HTTP request/response pair.  Our server
will accept requests in any of the following formats:

  (a) CGI query parameters submitted via HTTP GET
  (b) CGI query parameters submitted via HTTP POST
  (c) XML documents submitted via HTTP POST
  (d) binary data submitted via HTTP POST

We break (c) down into the following document types:

  (c1) Generic XML RPC encodings -- This includes the RPC that

       both webMethods and Userland support, and it includes
       John Tigue's webBroker encoding, though we don't support
       this latter encoding (at this time, anyway).  Such
       encodings are capable of representing any RPC message.
  (c2) Specific XML RPC encodings -- These are XML document
       types that are specific to the problem domain.  e.g.
       a doc type for purchase orders.  Send a PO document to
       a URL that names the object and method, and we'll
       interpret that document as containing the parameters
       of the method call.
       
(4) Our server returns responses in any of the following formats
(via the standard HTTP response mechanism):

  (a) Generic XML RPC encoding
  (b) Specific XML RPC encoding
  (c) binary encodings
  (d) HTML pages

One may use templates on the server to generate the XML.  We have
a really simple template language.  (d) is interesting because the
B2B server has an admin interface (read: admin object).  It exposes
a bunch of services (read: methods) that are invoked via URL with
CGI query parameters.  Our admin interface consists of HTML web
pages generated by templates in response to service invocations.

(5) Users write Integration Modules (IMs) on the server side.  They
conform to the WIDL specifications and access the back-end system.

(6) B2B uses WIDL mappings to bridge the impedance mismatch that
exists between programming languages and documents.  Programmers
don't want to have to navigate a document to get at data.  They
just want to issue function calls and get back return parameters.

WIDL makes this happen using the WOM query language (webMethods
Object Model -- not to be confused with the DOM API).  WIDL mappings
(XML files that extend WIDL specifications) contain WOM queries
and construct programming language structurs from document info.
We'll build strings, arrays, records, etc.

(7) Because B2B uses HTTP and XML, it need only sit on the sides
that don't already speak HTTP and XML.  Everybody's got an HTTP
stack, and XML parsers are easy to come by.  Unlike distributed
computing architectures that implement generic encodings, you
don't need an ORB sitting on both ends.  You only need agreement
on the semantics of XML tags.  You'd use B2B to web-enable and
XML-enable an application (our clients are typically enabling
large legacy ERP systems).  The clients can be as stupid or as
smart as you desire.

(8) Since WIDL mappings implement specifications to bridge between
document structure and programming constructs, programs need have
no knowledge of XML tag names or XML data structure.  WIDL will
hide all of this.  The DTD for the RPC encoding could completely
change, and any side that is shielded by B2B is shielded from
these changes.  One need merely update the declarative WIDL mapping.

(9) All of the above not only provides a way to use XML over HTTP.
It also provides what we call a "ladder of integration."

Say you already have a web site whose CGI programs already capture
so much of the business logic that you need to enforce.  You want to
give your clients automated access to your data, but you don't want to
write anything new.  No problem: put B2B on top of it and use WIDL
to make your web site look like a bunch of object interfaces.

Suppose you later want to go directly into your backend database
and skip the slow CGI programs.  No problem: without affecting
existing automated clients at all, replace the WIDL mappings with
an integration module.

Suppose you now want to migrate to Microsoft's Site Server.  No
problem: Just put Site Server on the backend and B2B will keep the

clients from having to change in order to speak to the new Site
Server interfaces.

The B2B architecture allows you to automate your clients now while
postponing your backend architecture decision.  It allows you to
take the easy migration path from whatever you have now to the
future end-all be-all Microsoft Site Server business platform.

So I'm more inclined to conclude that the B2B architecture is more
an architecture for bridging architectures.  It provides a safe
way to isolate changing systems and still provide communication
between the systems as they change.  We just want applications to
play nicely together regardless of native architecture or interfaces.

>And how does one develop an object or an application that provides
>the service?  Is there a framework that it runs on top of?  [...]

One can deploy B2B applications by writing XML and marshalling code
by hand, or one can do it with our special IDE called the B2B
Developer.  Both are extremely easy to do.  The Developer also goes
a step further by allowing you to interact with the web site that
you wish to wrap inside of program interfaces.

>Are these all XML App Servers?  OK. OK. I admit that I'm trying to
>categorize through the application of buzzwords.

We call B2B an "integration server."  We focus on interoperability
and network access/security/management issues.  We don't focus at
all on application management.  We usually expect the applications
to be self-contained and generally ignorant that our server exists.
B2B is a super-sophisticated bridge between applications.  The B2B
architecture focuses on giving applications XML smarts, HTTP smarts,
network security smarts, protocol translation smarts, and smarts
to allow the admin to manage all of this.

So that's the rundown on the webMethods architecture and on how I
think it compares to and works with CORBA and DCOM.  I go into a bit
more detail in the "WIDL and XML RPC" and "Supply chain integration"
chapters in _The_XML_Handbook_.  Also, I'll be giving a speech on
the WIDL framework at XML '98 in November, should you be interested.
--
Joe Lapp             | Senior Engineer
jlapp@webmethods.com | webMethods, Inc.
jlapp@acm.org        | http://www.webMethods.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)