Chapter 4 XML Processing
157
documents, transforming them from external schemas to internal schemas and, in
some cases, mapping them to domain specific objects.
For example, consider a system processing a purchase order that sends the
order to a supplier warehouse. The supplier, to process the order, may need to
translate the incoming purchase order from the external, agreed upon schema
(such as an XSD based schema) to a different, internal purchase order schema
(such as a DTD based schema) supported by its components. Additionally, the
supplier may want to map the purchase order document to a purchase order busi 
ness object. The business logic handling the incoming purchase order must use an
XML processing API to extract the information from the document and map it to
the purchase order entity. In such a case, the business logic may be mixed with the
document handling logic. If the external purchase order schema evolves or if an
additional purchase order schema needs to be supported, the business logic will be
impacted. Similarly, if for performance reasons you are required to revisit your
choice of the XML processing API, the business logic will also be impacted. The
initial choice of XML processing API may handicap the integration of other com 
ponents that need to retrieve part or all of the purchase order document from the
purchase order entity. 
The design shown in Figure 4.10, which we refer to as the XML document
editor (XDE) design, separates application logic (business or interaction logic)
from document processing logic. Following a design such as this helps avoid the
problems just described.
The term  Editor  used here refers to the capability to programmatically
create, access, and modify that is, edit XML documents. The XML document
editor design is similar to the data access object design strategy, which abstracts
database access code from a bean's business logic. 
The XML document editor implements the XML document processing using
the most relevant API, but exposes only methods relevant to the application logic.
Additionally, the XML document editor should provide methods to set or get doc 
uments to be processed, but should not expose the underlying XML processing
API. These methods should use the abstract 
Source
 class (and 
Result
 class) from
the JAXP API, in a similar fashion as JAX RPC, to ensure that the underlying
XML processing API remains hidden. If requirements change, you can easily
switch to a different XML processing technique without modifying the applica 
tion logic. Also, a business object (such as an enterprise bean) that processes
XML documents through an XML document editor should itself only expose
accessor methods that use the JAXP abstract 
Source
 or 
Result
 class. Moreover, a
business object or a service endpoint can use different XML document editor






New Page 1








Home : About Us : Network : Services : Support : FAQ : Control Panel : Order Online : Sitemap : Contact : Terms Of Service

java web hosting

 

 

 Our partners: | PHP: Hypertext Preprocessor | Best Web Hosting | Java Web Hosting | Inexpensive Web Hosting |

Jsp Web Hosting | Cheapest Web Hosting | Jsp Hosting | Cheap Hosting

 

Virtualwebstudio. Business web hosting division of Web Design Plus. All rights reserved