[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)
- From: Alaric Snell <alaric@alaric-snell.com>
- To: Nicolas LEHUEN <nicolas.lehuen@ubicco.com>
- Date: Wed, 22 Aug 2001 14:33:17 +0100 (BST)
Quoting Nicolas LEHUEN <nicolas.lehuen@ubicco.com>:
> I have been developing for my company a kind of compiler that enables us
> to
> embed XPath expression in Java code. We can now access any random piece
> of
> data within a document as easily as we would have done with an object
> model,
> e.g. we can write things like invoice/line[5]/quantity in our Java
> code
> instead of invoice.getLine(5).getQuantity().
You can't write invoice.getLine(5).setQuantity(10), nor invoice.getTotalValue(),
nor invoice.checkDeliveryAddressIsValid().
> We then developed a model in which business processes where expressed in
> XML
> documents, possibly containing Java code fragments, that are compiled
> into
> Java code, then into bytecode by a standard Java compiler. The
> compilation
> is dynamic, and is done for performance purpose. If a scripting
> language
> seamlessly integrating XPath expressions existed, we could have used
> it.
Sounds nice, actually!
> At the end, we get a dynamic processing language that can easily
> manipulate
> dynamic XML data in a business-oriented way (we could not do the same
> thing
> using XSLT, for example). The "dynamic" part here is important : it
> means
> that if the data changes, we are able to promptly adapt the processes.
All the same things can be done more easily with simpler RPC models, though.
> 1) We have been using this framework for one year and a half to
> implement
> and consume web services. In fact, we first implemented some in
> january
> 2000, using a proprietary SOAP-like protocol (XML over HTTP),
> implemented
> both in Java and Microsoft technologies. As an example of benefits of
> this
> approach, we managed to integrate our 100% Java server running on
> Solaris
> with 100% Microsoft code accessing to an Exchange server running on
> Windows
> NT. This is something that would have been very difficult and expensive
> to
> implement using CORBA, DCOM or RPCs.
DCOM, yes, since MS don't make implementations freely available. But CORBA or
ONC RPC are *platform neutral*. Why do you think it would have been harder?
> 3) We don't have to worry about object model mappings to/from databases
> or
> XML ; all data is represented as XML documents.
The same can be done with any standard model; CORBA IDL will do this, as will
ONC RPC. The object model mappings are there, so you use the syntax native to
your language (thing.getFoo(5)), but it's automatically generated.
> Regards,
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software