Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to L
 Michael Brennan wrote : <snip/> >Developers still need to write business logic, and they need to get the >information from the XML document into data structures better suited to >supporting that business logic. All of the APIs in the XML world are >unsuited for this. They force the developer to mold their >logic to fit an >API that is only suited for modeling a document structure, rather than >letting the developer mold their data structures and APIs to align with >business concepts and processes. This is maybe a somewhat bizarre question, but what exactly prevents somebody from writing business logic that operates on a document structure ? If the answer is "a document model isn't usable as a business data model" then the whole XML industry in trouble ; if the answer is "XML APIs just don't help us doing this", this is a problem that can be solved. 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(). 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. 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. Investigations on this approach lead us to the following reflexions / issues / questions : 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. 2) The use of an intermediate compiler enables us to insulate our developers from underlying XML APIs. We can therefore change of DOM implementation, selecting for example JDOM, or dom4j, or a custom one. Likewise, we can choose the XPath API we want, etc. This allows us to always select the most effective library. This is very important because most XML technologies implementations have yet to mature, both on the compliance level and on the performance level. 3) We don't have to worry about object model mappings to/from databases or XML ; all data is represented as XML documents. This is good, because it saves a lot of code writing, and increases our flexibility. The bad side is that non-textual data (e.g. numeric values) are not handled easily. But that's something we plan to solve by implementing our own DOM. 4) This separation between data and processes is totally against most object-oriented practices. This is somewhat considered as "bad", especially in France where people are very strict about it :). But in fact if you take a close look at most EJB architecture, you'll discover that processes (in Session EJBs) are usually separated from data (in Entity EJBs), and that implementing business methods in data object is not an easy task (not even speaking about evolution of the model). 5) Our greatest current problem is about schemas. As I've wrote previously on this list, our approach raises a dire need of a simple schema language, simple enough so that developers can write and use schemas without having to read thousands of pages of specifications. We are currently investigating languages such as RELAX NG, Schematron, Examplotron or a custom language we named RESCALE to solve this problem. Regards, Nicolas Lehuen Responsable R&D / Head of R&D UBICCO, the Multi-Access Software Vendor http://www.ubicco.com/ mailto:nicolas.lehuen@u... Phone : +33 1 53 24 99 79 Fax : +33 1 53 24 17 23 Mobile: +33 6 61 90 76 40 
|
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
|
|||||||||
