Message Bridge simplifies and speeds development of applications for today’s competitive businesses who want to:
Generate and accept electronic orders
Tightly manage the manufacturing process, delivering on time without leaving extra product on the shelves
Streamline internal processes to improve employee productivity
Message Bridge allows you to build these kinds of collaborative applications enabling developers who need to access, generate, manipulate, and exchange documents and messages quickly and effectively.
The applications making a difference today are using the Web to enable communication and cooperation between businesses. This new focus forces Information Technology (IT) to go well beyond traditional department or company boundaries. Developing these new applications can be extremely slow and difficult. Data definitions taken from off-the-shelf applications can be cryptic and arcane. Custom application development and integration projects too often use definitions decipherable only to a company’s IT “insiders”. An effective platform for application interoperability is a goal rarely achieved.
Sometimes useful abstractions can be layered on top of a legacy application. But these abstractions are difficult to design and hard to keep up to date when support for new documents and messages needs to be added every day to a company’s application portfolio.
Java and Extensible Markup Language (XML) are breaking down some of the traditional barriers to building collaborative applications. The Java platform’s portable code capability allows Java applications to be deployed to a wide variety of platforms and to any application tier. The Java language itself is a well-designed object-oriented programming language that allows Java developers to easily build applications by creating hierarchies of objects.
XML is a syntax for defining markup languages that in many ways is analogous to Java. Using XML, documents or messages become hierarchical containers within which the data content is “marked up” in a manner that is totally independent of platform or language. Java’s object-orientation lends itself well to representing the hierarchy of XML data as a hierarchy of objects. It is important to note that XML can be processed by any language or application—there is no specific tie to Java. As such, XML allows applications to exchange data with minimal dependencies between the producer of a document or message and its recipient.
The Java community has made robust XML parsers available to developers for free, and Sun Microsystems has even defined a standard set of Java APIs for XML Parsing (JAXP). JAXP provides a straightforward API for developers to load DOM or Simple API for XML (SAX) XML parsers, and each parser provides methods that allow a developer to access the content of any XML document.
Each of these parser APIs offer its own strengths. Document Object Model (DOM) parsers allow developers to load the data of an entire XML document into memory, and provide powerful features to allow developers to modify the document while it is in memory. Using DOM, developers can both deserialize XML (read a document into in-memory objects) and serialize XML (for example, write a document out to disk). In contrast, because SAX XML parsers are read-only you do not use them to build a new XML document. The SAX event-based parser is faster and consumes far less memory than the DOM parser; consequently, it allows developers to parse the data out of an XML document more effectively.
While these parsers are powerful tools, both are limited in their ability to handle the data in XML documents productively. Although the SAX parser is efficient, when a parse is complete, the only data remaining for an application’s use is that which the developer wrote custom code to store. This is acceptable if the developer wants access to only one or two pieces of data in the document and does not mind writing SAX callbacks to capture and store the relevant data in some other custom objects they wrote. But because the document data is not stored in memory, it can require a lot of code on the developer’s part to perform data processing on the document (for example, calculating the total dollar value of a series of order line items). The developer can easily use the DOM parser to store the XML document in memory and provide Java APIs to navigate through the document. Unfortunately, the interface to every single XML document is identical in DOM, as shown in Figure 1-1.
Figure 1-1: DOM’s generic representation of unique documents
The DOM parse tree makes every document look the same from a programming API perspective: A request for quote, a purchase order, and a shipping inquiry appear identical to the developer. A purchase order has a reference number, customer information, payment terms, and a list of items being ordered—not generalized document objects, like nodes, node lists, node maps, and so on. This generic abstraction limits developer productivity: Java objects are most valuable when they have some resemblance to the physical entity being modeled.
An ideal solution would be to represent the specific document hierarchy in a corresponding object hierarchy, without requiring months of developer time to achieve the kind of useful data abstraction that permits the rest of the application to be developed quickly. This solution is shown in Figure 1-2.
Figure 1-2: Document to object hierarchy mapping
So, how might a solution be approached? The World Wide Web Consortium’s (W3C) XML specification does outline rules that XML documents must follow to be considered “well-formed”. But two well-formed purchase orders can look very different from each other. Even if they share the same concepts, such as reference number and customer information, the flexibility of XML would make two companies hard pressed to exchange these documents reliably.
Fortunately, the creators of XML recognized the need to allow document structures to be more finely constrained so that multiple parties could interpret them consistently. Generically speaking, the set of rules that outline a document’s components, structure, and content is called a schema. Schemas can be written in all sorts of languages, but the important schemas that constrain XML are Document Type Definitions (DTDs) and XML Schema. Documents that conform to a schema are said to be “valid” instead of just “well-formed”. Therefore, developers who want to use Java objects to represent the data in XML documents should model their Java classes from whatever schema constrains the XML document.
Message Bridge compiles schemas into Java classes during design and binds specific XML documents to specific Java objects at runtime, as shown in Figure 1-3.
Figure 1-3: Message Bridge design and runtime
Message Bridge helps developers build applications that make use of structured messages, such as XML documents or messages exchanged between enterprise systems or business partners. Message Bridge improves developer productivity by modeling the schema of a document or message as Java classes. When used in an application, these classes provide an intuitive way to access and manipulate message content in memory, and to read and write messages to and from the network.
Message Bridge provides a schema compiler that binds a document or message schema into Java classes. Each class provides access to the data content of the corresponding schema component through accessor (get) and mutator (set) methods similar to those used in standard JavaBeans. Because these classes model the data content of a document or message instance, we refer to them as DataBeans. In short, a DataBean is a Java binding of a particular schema.
Features are:
Message Bridge represents document or message content in memory so it can be used for data-centric applications, yet the representation is not generic—it represents data at the same conceptual level as the document’s schema.
Message Bridge provides a graphical design environment that developers use to import document or message schemas and automatically generate corresponding Java classes. As a result developers can quickly get access to document-specific data abstractions without having to spend time and effort modeling these abstractions themselves.
Developers using code generated by Message Bridge do not need to write low-level parser code. As a result, they have the freedom to extend the generated classes to fine-tune the data abstractions but do not need to create the abstractions themselves. And Message Bridge provides additional developer artifacts (XML DTDs, XML Schemas, and HTML documentation for DataBeans) to aid development of applications using DataBeans.
Message Bridge generates code (DataBeans) that developers use in their application to make generation and consumption of document and message data easier.
Developers use Message Bridge to import XML DTDs and XML Schemas. Message Bridge converts these schemas into a neutral representation that developers can modify, enhance, and group into projects with other related schemas, as shown in Figure 1-4.
Figure 1-4: Building DataBeans
Using Message Bridge, developers can generate DataBeans for the individual schema definitions they select. These DataBean classes abstract the data contained in documents or messages in an intuitive manner. Each articular DataBean leverages shared runtime classes. The DataBean framework serializes and deserializes content from the network, validates content, and provides a read/write in-memory representation of message data.
Message Bridge can also generate artifacts to assist developers in using DataBeans in their applications. These artifacts facilitate development in various ways. For example, the XML DTD and Schema provide the developer with content model descriptions of each DataBean. By using these content models during design, developers are able to bring their own XML-based tools to bear, easily modeling runtime systems based on XML data authoring, manipulation, and transmission. The HTML documentation provides the Java developer with a detailed view of each particular DataBean’s content model, facilitating the incorporation of particular DataBeans and the DataBean framework into their own custom applications.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|