196

Conclusion

Table 4.2

Guidelines for Using XML Judiciously for Component Interaction

Data Passing 

Remote Components

Local Components

Between 

Components

Java Objects

Efficient

Highly efficient

(Fine grained access}

Document Object 

Very expensive, nonstandard 

Only for document centric 

Model

serialization

architectures

Serialized XML

Expensive, but interoperable

No reason to serialize XML 

for local calls

4.6

Conclusion

This chapter covered much of the considerations a developer should keep in mind

when writing applications, particularly Web services based applications, that use

XML documents. Once these issues and considerations are understood, then a

developer can make informed decisions about not only how to design and imple 

ment these XML based applications, but if the applications should even be based on

XML. In a sense, the developer is encouraged to ask this question first:  Should this

application be based on XML?  

Once the developer decides that XML is appropriate for the application, then

the next task is for the developer to design a sound and balanced architecture.

Such an architecture should rely on XML only for what XML is good at. That is,

the architecture should use XML for open, inter application communication, con 

figuration descriptions, information sharing, and especially for accessing domains

for which public XML schemas exist. At the same time, XML may not be the

appropriate solution of choice when application interfaces are not exposed pub 

licly or for exchanging information between components that should be communi 

cating in a tightly coupled manner.

The chapter also considered the factors a developer must weigh when decid 

ing where and how to perform XML processing. Should XML processing be

limited to the interaction layer of a Web service as a pre  or post processing stage

of the business logic, or should the business logic itself be expressed in terms of