[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XML IDL and XML RPC
(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@w... | webMethods, Inc. jlapp@a... | http://www.webMethods.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|