[ Pobierz całość w formacie PDF ]
.Application developmenttools that specialize in the Domain Model pattern deliver code-gen-erating and deployment utility software to make it easy to go froman XML message schema or WSDL document to deployable code.The problem with SOA and these utilities is the one-way nature ofthe utilities.When a composite application or data service needs tointeroperate with a new or updated XML schema, the utilities requirea regeneration of the code.Regeneration often means that any cus-tomization to the previous generated code is lost.Even with these utilities I find myself back in the code enoughtimes to make me wonder if there is a more efficient alternative.Native XML technology is worthy of your investigation.For instance,I wrote a data service to handle incoming purchase orders expressedin an XML message.I wrote 680 lines of Java code to implement theservice.I then wrote the same data service using native XML technol-ogy XQuery and native XML database in only 45 lines of code.(Chapter 7 teaches these native XML technologies.)Additionally, as XML message schemas change over time, thenative XML tools require fewer changes as compared with changesin the same services written in Java.There are less lines of code tomaintain.Of course, your mileage may vary and there are functionaldifferences, such as transactional capabilities, that are not as matureas those found in the Java platform.Native XML approaches to composite applications and data ser-vices are appealing because of the greater developer productivityless lines of code to write and maintain and the easier maintenancefor schema evolution and changes.1.4.2 Your Choice of XML Tools Impacts PerformanceXML comes in a variety of sizes and forms.A software developer schoice of XML tools and parsers impacts the scalability and 1.4 Can I Build SOA with My Existing Tools? 27performance of the SOA application.The topmost popular XMLparsers in the Java space are XML binding compilers such as JAXB,streaming XML parsers such as StAX, and DOM tree parsers such asXerces.Table 1-2 illustrates each parser s strengths and weaknesses.Table 1-2 Contrasting XML ParsersTechnology Plus MinusXML Binding Compiler Efficiently handles large Requires recompile of(JAXB) and complex XML data binding each time XMLby providing schema changes.No sup-namespace-aware port for multiple schemasnamed elements so your or schema evolution.application can jumpright to the needed partof an XML tree.Streaming XML Parser Excellent performance Performance degrades(StAX) for large XML docu- with complex XML docu-ments by providing ments and large (>5ability to skip unwanted megabytes) messages.elements.Document Object Acceptable performance Requires memory to loadModel (DOM, Xerces) when application needs entire XML documentto access/update most into memory.Requireselements in an XML the most amount of cod-document.ing.Native XML technology usually accounts for these XML sizes andforms.For instance, many XQuery implementations are built onstreaming data processing engines.Many native XML databases pro-vide indexes that are specially designed to handle the multidimen-sional queries through XML document collections for fast queryspeed.Chapter 4 describes XML parser performance and scalabilityissues in more detail.1.4.3 Criteria for Applying Database Technology for SOAWhile there is no SOA standard to recommend using XML, mostSOA applications I see move XML documents from service to ser-vice.XML is already widely used to express documents, documentformats, interoperability standards, and service orchestrations.Thereare even arguments put forward in the software development com-munity to represent service governance in XML form and operatedupon with XML query methods.9 28 Chapter 1 The Problem with Service-Oriented ArchitectureAs the world moves to become an XML environment, I am oftenasked to define criteria for when it makes sense to use native XMLtools.The following are common questions about using relationaldatabases in SOA environments
[ Pobierz całość w formacie PDF ]