[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML.COM: How I Learned to Love daBomb

• From: Michael Brennan <Michael_Brennan@a...>
• To: "'Al B. Snell'" <alaric@a...>
• Date: Wed, 22 Aug 2001 13:16:26 -0700

XSLT isn't the only option. XPath can be used with other technologies to
provide malleable mappings between a wire format and the data structures and
interfaces needed for processing.

I think it is evident you have a deeper understanding of RPC protocols than
I do. I can't argue with you on that basis. But I can speak from my own
experience. I've done EJB development, and I've done COM development. I've
also done work with our own integration technologies that use a declarative
language leveraging XPath for mapping arbitrary XML structures into
potentially quite different data structures and method calls. We have found
far higher levels of productivity with this custom integration technology
then with the process of recoding server stubs to support a new interface.

Indeed, we often get remarks from our customers regarding how rapidly we can
build custom integrations, and how easily they can implement their own end
of the integration. As one example, we had one customer who praised our
openess with the jocular remark that "the [Allegis] system is so open, we
could probably integrate it to a snow cone machine if we needed to"
(http://www.allegis.com/news/articles/destinationcrm_can_you_collaborate.htm
). He was exagerrating, of course. We are not providing SOAP-enabled snow
cones. It is still rewarding to hear this sort of praise, though, and I
can't help but feel that if this customer had to use ONC-RPC or IIOP to
integrate with us, we would not be hearing this same level of praise.

Utimately, that is the litmus test for us. Do our customers find our
integration interfaces and tools easy to work with? If so, we have
succeeded. If not, no amount of rational argument regarding the technical
merit of our approach has any relevance.

The XML over HTTP approach has served us and our customers well for a few
years, now, and we regularly receive praise from our customers regarding how
much easier it is to integrate systems with Allegis then with other
enterprise software packages. What one developer considers easy may be
unweildy and intimidating to others. It is rather presumptious to speak on
their behalf without listening to them. We have to listen to them, or we
will go out of business, and they are telling us that XML is easier than the
alternatives they've had to work with, and internally we are achieving
higher levels of productivity than we've seen with integration technologies
centered entirely on mapping programming APIs onto wire protocols.

> -----Original Message-----
> From: Al B. Snell [mailto:alaric@a...]
> Sent: Wednesday, August 22, 2001 1:53 AM
> To: Michael Brennan
> Cc: xml-dev
> Subject: RE: XML.COM: How I Learned to Love daBomb
> 
> 
> On Tue, 21 Aug 2001, Michael Brennan wrote:
> 
> > RPC could never displace EDI technologies. It's too rigid 
> and inflexible. If
> > you want to adapt to a particular format over the wire, you 
> have to write
> > the source for your business services to match that format. 
> Every new format
> > requires the coding of a new interface.
> 
> So does XML! If you expect:
> 
> <order>
>  <item>Food Sensor</item>
>  <qty>10</qty>
>  <send-to>...</send-to>
>  <bill-to>...</bill-to>
> </order>
> 
> And you get:
> 
> <request>
>  <item-name>Food Sensor</item-name>
>  ...
> </request>
> 
> then you're shafted.
> 
> Of course, with XML, you can *add* extra elements and 
> attributes and the
> recepient gets to guess whether they are just irrelevant 
> information it
> can ignore, or some criticial information it can't process the order
> unless it can understand. ONC-RPC avoids this multi-version issue by
> putting version numbers on requests and having negotiation 
> mechanisms for
> implementations of different protocol versions to come to 
> agreement with
> each other; the client would ask the server if it supported 
> the version
> with the new fields in, and if not, it would either give up 
> (if it *needs*
> those new fields to be understood) or not send the new fields. ASN.1
> extends this by allowing special added fields to be marked as 
> such so that
> the recepient can skip over them, just like XML does, but 
> again this time
> there are rules about what those fields can mean; if they are 
> encoded as
> later-version extension fields, earlier verion recepients are 
> allowed to
> ignore them. If they contain vital information then the 
> sender uses a new
> format that is not a backwards-compatible version of the old 
> one, and the
> recepient will barf, and in an interactive transaction that connection
> will never get set up when transfer encodings are agreed upon 
> if the two
> ends cannot talk a mutually acceptable language.
> 
> > XML-based technologies can displace EDI, because they can 
> easily support an
> > adaptive layer that can map different XML structures into 
> the same core
> > business services.
> 
> So can other RPC technologies. Whereas in XML you might abuse 
> XSLT to do
> this (it's not what it's meant for and you can get burnt 
> easily), with RPC
> technologies you just write a different set of server stubs 
> that accept
> the requests and call your middleware functions. This is done 
> in practice,
> and it works fine.

• Prev by Date: Re: XInclude vs SAX vs validation
• Next by Date: RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)
• Previous by thread: RE: XML.COM: How I Learned to Love daBomb
• Next by thread: test (sorry)
• Index(es):
  • Date
  • Thread