KR20020061888A - Method for developing xml application program - Google Patents

Abstract

PURPOSE: A method for developing an XML(eXtensible Markup Document) document is provided to support a developer with two steps of designing a schema and developing an XML application program by applying the XML schema and automatically generating an XML storage medium schema and a DOM(Document Object Model) API(Application Program Interface) from the XML schema. CONSTITUTION: The method comprises the steps of generating the schema including the conditions of the XML application program, generating the XML schema suitable to an object type of the schema, generating an RDB(Relational DataBase) using the XML schema, generating an interface using the RDB schema, and developing the XML application program using the application interface. The schema generation comprises the steps of designing a diagram including the conditions of the application program, making a class object corresponding to the XSCS(XML Schema Class Set) by receiving an attribute and an element necessary for the diagram, and adding the class object to an object list of an UML(Unified Modeling Language) modeler.

Description

Development method of XMEL application program {METHOD FOR DEVELOPING XML APPLICATION PROGRAM}

The present invention relates to a method for developing an XML application program, and more particularly, a schema generation step of generating a schema including conditions of an XML application program, and an XML schema generated according to an object type of the schema. An LS schema generation step, an ALDI schema generation step of generating an RDB schema using the XML schema, an interface generation step of generating an interface using the ALDI schema, and an application program interface. The present invention relates to a method of developing an XLM application program that allows the user to easily and naturally transfer the contents defined in the design stage to the development stage by progressing to the development stage of the application.

Recently, XML (eXtensible Markup Language) has been in the spotlight as a standard for data exchange and document format on the Internet. XML documents are layered by semantic units and separated by tags. These semantic units and hierarchies are defined in the document type definition (DTD) of the document. By analyzing this DTD, XML applications can determine the structure of the XML document and easily extract data.

XML has received great expectations because of the ease with which various applications can be developed, but at present XML does not live up to its expectations. There are many reasons for this, but one reason is that the information presented by the DTD is lacking for the application to use. The DTD allows you to define only the structure of a document, which is not enough for an application to efficiently analyze and utilize the document. For example, even though a company's accounting documents are composed of a large number of numerical / statistical data, the DTD only shows the structure between the data and cannot provide information on the type of data. Therefore, a large amount of numerical data can only be represented as a string. In addition, it is not possible to define the data constraints that certain numerical data must have, such as an employee's salary cannot be less than 400,000 won per month. In fact, in application programs developed using DTD, the above data types and data constraints are not arbitrarily decided by the developer at the development stage or not considered at all. This means that a lot of information that needs to be specified in the design phase is provided in the development stage, and that the information that the system designer needs to write is transferred to the application developer.

Many companies already in the industry have realized the limitations of the DTD and have created and used their own XML schema definition language, and XML Schema Definition Language (XML) Schema) was proposed by the World Wide Web Consortium (W3C).

With the advent of XML Schema, it is possible to design a level of schema that has not been possible with DTDs. This makes XML Schema design more complex than DTDs, so schema modeling becomes an important issue. The design of XML Schema should be done in a conceptual and standard way. Considering that XML Schema introduces many object-oriented concepts, UML (Unified Modeling Language), the standard for object-oriented design, is the most suitable for XML Schema design.

UML is a standard object modeling language, and mapping XML Schema to UML means that you can model XML schemas in a standard way.

Currently, the mapping protocol between UML and XML schema definition language is the "UML mapping protocol for SOX" jointly proposed by Rational Software Corporation and CommerceOne. This protocol uses the UML extension mechanism to create a new UML class for components in the XML schema. The advantage of this method is that it follows the standard of UML in the method of modeling. Therefore, it has the advantage that XML schema can be modeled without any modification in existing UMASE supporting CASE tool. However, it is just a convention and the implementation is passed on to the CASE tool developer.

Schemas designed using XML Schema will contain various datatypes and data constraints. However, this information, defined at the time of design, does not benefit greatly during development. This is because developers must look at the designed schemas and reflect them during development. This problem can be solved by providing an application development foundation that performs data transformation and constraint checking in the intermediate stage between the XML document and the application as a result of the design phase. This application development foundation should be a standard and easy-to-use interface for developers. The design phase is based on using a standard interface for XML, such as the Document Object Model (DOM) or the Simple API for XML (SAX). It will be easy and natural to pass the definition defined in the development stage. This process provides developers with an XML development method called "Design and develop" that allows them to design XML schemas and start developing applications immediately.

Before developing an XML application, the general characteristics of the XML document that the application deals with can be classified into three categories:

First, XML documents have a complex structure. Existing documents have a simple list structure, while XML documents have many nested structures and references between elements. Because of this feature, when designing the structure of an XML document, a conceptual and logical design approach should be introduced.

Second, XML documents have persistence and are massive. XML documents are in themselves as data. This means that the document is not to be used temporarily but must be preserved permanently. Also, because XML documents can be nested, small XML documents tend to gather into one large XML document. As a result, one XML document is so large that it corresponds to one database in size. Permanent and efficient management of this huge document requires consideration of a particular XML storage medium.

Third, XML documents have various applications that use them. As much as the versatility of XML documents, there are many different applications for using them. These applications can be a subset of an XML document, a search over the entire document, or a task such as data mining. There are various applications, and there are many problems in developing an application program by directly accessing the infrastructure of the XML storage medium each time. Therefore, a separate interface that is independent of the XML storage medium is required, and the DOM API is most suitable as a standard interface.

Considering the characteristics of the XML document as described above, the present invention has to go through four steps as shown in FIG. 1 to develop an XML application.

The first step is to design your XML schema. There are many ways to design an XML schema. Existing methods extend the general XML editor to design XML schema in tree structure, and "UML mapping protocol for SOX" can design SOX schema, one of XML schema definition languages in existing UML-based CASE tool. Provide the foundation for

With this designed XML schema, the second step is to create the schema of the XML storage medium. This is to maintain the persistence of the XML document. The XML storage medium may be an XML-only storage medium, an existing database system, or a file system.

Once the XML storage media schema has been created, the third step is to write an API that converts the data stored on the XML storage media back into an XML document. This is because the way that XML storage media is stored can be different from the format of XML documents, and developers can handle XML documents in a consistent form through this written API. At this stage, the API should be a standard way to access XML, and may be the Document Object Model (DOM) or the Simple API for XML (SAX).

Once all of the above steps have been completed, the developer can finally begin developing the XML application.

Looking at the development stage of an XML application to date, developers can use the DTD modeling tool to design an XML schema, convert it to an existing relational or object-oriented database schema, and write all the APIs that the application can use. Should be. Looking at these four phases, it is clear that the second and third phases are stronger than building an actual XML application, rather than building an XML development environment.

1 is a diagram illustrating the development of an XML application program according to an embodiment of the present invention.

2 is a structural diagram of an XSD4j according to an embodiment of the present invention;

Figure 3 is a diagram of an XSD4j modeler in one embodiment in accordance with the present invention.

4 is an attribute of a pruduct element in one embodiment according to the present invention.

5 is a PurchaserOrder schema according to an embodiment of the present invention.

6 is a structural diagram of a Java DOM API in an embodiment according to the present invention;

7 is a class structure diagram of a Java DOM API generated by XSD4j in an embodiment according to the present invention.

8 is a simple purchase information management program in the application example according to the present invention.

The development method of the XM L application program according to the present invention,

A schema generation step of generating a schema including conditions of the XML application program; An XML schema generating step of generating an XML schema according to the object type of the schema; Generating an RDI schema using the XML schema; An interface generation step of generating an interface using the ALDI schema; And a development step of developing an XML application program using the application program interface.

The schema generation step may include a diagram design process of designing a diagram including conditions of an application program; And an object list adding process of inputting necessary attributes and elements in the diagram to create an object of a corresponding class in XSCS and adding the object list to an object list of a UML modeler. ,

The XLM schema generating step may further include a mapping process for mapping the UML and the XML skimmer.

In the ALDIB schema generation step, the mapping rule between the XML schema and the ALDIB schema may be characterized by using a basic shared technique, a shared inline technique, or a hybrid inline technique.

In the interface generation step, the interface may be used based on Dom API and / or SAX API.

The language used in the interface may be Java.

The present invention will be described in detail through the following examples. However, these examples are for illustrative purposes only and the present invention is not limited thereto.

EXAMPLE

The present invention implements XSD4j (XML Schema Designer for Java), a UML-based XML CASE tool that introduces XML Schema using OOAD UML Modeler. XSD4j solves the problem of DTD-based XML application development by introducing XML Schema, and proposes a two-stage program development methodology that allows developers to design XML schemas and start developing XML applications immediately. Implemented. XSD4j introduces UML during the modeling process to support the design of XML schemas at a standard and conceptual level. It also creates an XML storage media schema and automatically generates an API that maps the storage media and the DOM, providing developers with an environment to design XML schemas and start developing applications right away.

If you look at what XSD4j does, it can be divided into modeling an XML schema and building an environment in which an XML application can be developed using the modeled schema. Therefore, as shown in FIG. 2, the overall structure can be divided into two parts, one of which is XSD4j Modeler, which is related to schema modeling, and the other is a document related to XML Schema (XML schema, XML XSD4j Document Generator that generates storage schemas and DOM API code.

The XSD4j modeler supports XML schema modeling based on UML. The developer-designed XML schema is expressed as a list of XML Schema classes in XSD4j XSCS (XSD4j XML Schema Class Set), and the interface for data input uses XSD4j UI (XSD4j User Interface).

XSD4j XSCS is a set of classes that convert various components defined in XML Schema to stereotype of UML. XSD4j UI provides an interface for receiving data required for various classes of XSCS from user. XSD4j UI receives attributes or elements of each class of XSCS.

Information about each class of XSCS used by the XSD4j UI is obtained from the XSD4j Meta Information Manager. The XSD4j Meta Information Manager analyzes a document that defines an XML Schema and provides various information needed by the XSD4j modeler.

The XSD4j document generator is responsible for generating XML schema documents, XML storage schemas, and DOM APIs from the results modeled by the XSD4j modeler.

XSD4j consists of two steps of modeling an XML schema and then generating a document. When the user draws an XML schema diagram, the XSD4j UI receives the necessary attributes and elements according to the diagram type. Create an object of the corresponding class in XSD4j XSCS using the input data and add it to the object list of UML Modeler. Since XSCS class inherits UML Modeler's class as a stereotype, in UML Modeler, XSCS is treated as a general UML class.

After modeling the XML schema, the XSD4j document generator generates the XML schema document. The document generator traverses the object list of UML Modeler and generates an XML schema document according to the object type. Since XML schemas and XSCS classes are almost one-to-one correspondences, XML schemas can be created simply.

After creating the XML schema, you will be creating the XML storage schema and DOM API code. XSD4j uses a relational database as an XML storage medium. XML schemas and relational database schemas do not have a one-to-one correspondence, so work that needs to be done appropriately is necessary. Each class of XSCS includes a relational database schema generation rule. The relational database schema generated by this rule is stored in the class in the form of data structure, and this data structure is used in the DOM API generation module.

DOM API code generation is in Java language, and the code is generated referring to the relational database schema data structure of XSCS mentioned above.

By the end of this step, you will have a Java DOM API that matches the XML schema you modeled, which is the basis for writing your application.

The use of UML for schema modeling enables conceptual modeling and conforms to standards, as mentioned earlier. Thus, the XSD4j modeler allows you to design XML schemas based on UML. However, there is no one-to-one correspondence between UML and XML Schema, and therefore, XML Schema and UML mapping process is required.

In fact, an XML schema defines what elements and attributes a document will use, what conditions the values must meet, and what its hierarchy will be. In other words, the most important elements of an XML schema are elements and attributes, and these two elements are most important in the modeling process. Most of the remaining elements are those that define the datatypes or constraints of these two elements. Therefore, the information appearing on the diagram of the UML is centered on elements and attributes as shown in FIG. 3, and the remaining elements are represented by attributes of each element. Information not shown on this diagram can be represented by the attributes of each element as shown in FIG.

As a practical example, let's look at a simple purchasing information XML document that you can use in a shopping mall. The mall manages the purchase information for the date each order is made, the purchaser must be one for each purchase, and the destination of the item can be designated two places in case the buyer is absent. Let's say you have a policy of unlimited product types.

The XML schema designed to reflect this policy is shown in FIG. In other words, the purchase date, which can be an attribute of one purchase, is an attribute, and the purchaser's name, shipping address, and purchased items are treated as elements. ProductType representing product information and AddressType representing address information can be recycled in other elements, so they are designated as separate types. PurchaseOrderType, a purchase information type, refers to AddressType and ProductType as elements for address and product information, respectively. Done. If you create this schema as an XML schema, it is shown in Table 1 (XML schema related to simple ordering information).

<schema> <element name = "purchaseOrder" minOccurs = "0" maxOccurs = "unbounded" type = "PurchaseOrderType" /> <complexType name = "PurchaseOrderType"> <attribute name = "orderDate" type = "date" /> < element name = "name" type = "string" /> <element name = "address" ref = "AddressType" maxOccurs = "2" /> <element name = "product" ref = "ProductType" maxOccurs = "unbounded" / > </ complexType> <complexType name = "AddressType"> <attribute name = "value" type = "string" /> </ complexType> <complexType name = "ProductType"> <attribute name = "value" type = "string "/> </ complexType> </ schema>

There can be several XML storage media. It can be a general database system, an XML-only storage system, or a text file stored in the file system. There is much debate about which storage medium is good. However, in this paper, I will not discuss which system is good. This is because XML storage media is only a matter of choice and has little to do with the development of XML applications. This is possible because XSD4j creates a DOM API that is independent of the XML storage medium and is a standard interface.

XSD4j supports relational database systems as an XML storage medium. In the case of ODBMS, the mapping from XML schema to database schema can be almost one-to-one, and in the case of XML-only storage system, no mapping process is necessary. Even if the file system is used, a separate XML parser is introduced so that no special mapping process is required.

Mapping rules for XML schemas and relational database schemas use similar techniques to Basic Shared, Shared Inlining, and Hybrid Inlining techniques. This technique converts an XML schema originally defined by a DTD into a relational database schema.

Basic sharing techniques are explained.

In XML Schema, the elements that actually define the data that appears in the document are the Element tag that defines the element and the Attribute tag that defines the attributes . Basically, an element can be converted into a table in an RDB and an attribute can be converted into a field in a table. In the case of an attribute, one attribute type is a primitive type, so there is no problem in the conversion. So let's briefly look at the process of converting an element to an RDB schema. The basic sharing technique creates a new table (type table) for every type an element can have. In this table, only the element's attribute value is a field, and the structure between elements is solved by having a separate element table.

The algorithm is simple: first create a commonly used element table, then traverse the element types through the depth first traversal from the top element and generate a type table (Table 2 (RDB of Basic Shared Techniques). Schema generation algorithm)). According to this algorithm, the XML schema designed in FIG. 5 is generated as an RDB schema. Table 3 (the RDB schema generated using the basic shared technique).

BeginRDBSchemaGeneration () GenerateElementTable (); // Create separate table for Element ElementList = GetRootElements (); for each element in ElementListdoMakeRDBSchema (element); MakeRDBSchema (element) elementType = element.getType (); // // For each element in ElementListdoMakeRDBSchema (element); elementType.GenerateRDBSchema (); // create a table with attributes as fields

CREATE TABLE XSE_ElementTable (_XSE_KEY_ int auto_increment primary key, parent int, child int, seq int default 0, TypeName varchar (255)); CREATE TABLE PurchaseOrderType (_XSE_KEY_ int auto_increment PRIMARY KEY, orderDate date); CREATE TABLE AddressType (_MSEARY_KEYcre CREATE TABLE ProductType (_XSE_KEY_ int auto_increment PRIMARY KEY, value varchar (255)); CREATE TABLE string (_XSE_KEY_ int auto_increment primary key, data varchar (255));

The XSE_ElementTable, a table that shows the parent / child relationships of elements, contains fields for the parent and child node keys, information about the key types of the child keys, and the order of the elements. The rest of the table is a table of element types.

The result generated by the basic sharing technique is that a lot of join operations between the element table and the type table occur to recreate the structure of the XML. These join operations move the contents of the element table into the type table. Can be reduced to some extent, but is not effective. In fact, join operations are the most important factor in system performance, so it is important to reduce join operations when creating RDB schemas.

Explain shared inline techniques.

Shared inline techniques are introduced to reduce join operations between tables. In other words, the number of join operations can be reduced by reducing the number of unnecessary type tables. In fact, the basic sharing technique creates a table for each type of element because the number of times an element can appear is not constant. However, if the number of times an element can appear is limited, it is possible to create pre-joined results in a table. In other words, for the finite element, the existing method is that each element exists as one row, but the shared inline technique uses the finite element as one field by arranging multiple fields in one row, so that it is represented as a single row. It is. Therefore, the result of the join is also expressed as a single row, so it can be represented as a table that is joined in advance.

The algorithm is not much different from the algorithm of the basic sharing technique. In the step of comparing the maxOccurs value of an element in the step of creating the type table of elements, the element type table is created only when the value is unbounded , otherwise maxOccurs the number of fields the element type table should have. Duplicately add to the current type table.

An example of generating the simple purchase information XML schema of FIG. 5 as an RDB schema using this method can be seen in Table 4 (RDB schema created using an inline sharing technique). In this example, you can see that you can get the value of an address or name element without a separate join operation.

CREATE TABLE PurchaseOrderType (_XSE_KEY_ int auto_increment PRIMARY KEY, parent int, seq int, orderDate date, name varchar (255), addressvalue1 varchar (255), addressvalue2 varchar (255)); CREATE TABLE ProductType (_XSE_KEY_ int auto_icrement PRIMARY KEY, parent int , seq int, value varchar (255));

XSD4j provides a Java DOM API for interfacing XML documents stored on XML storage media with actual XML applications. The Java DOM API can be used to provide a standard environment for developers to hide from a variety of complex tasks that are not very relevant to XML storage media or other XML, and to build an environment dedicated to developing XML applications. The DOM API allows the XML application developer to make assumptions that the XML document is loaded in the application's memory space, thus enabling the persistence of the XML document with minimal consideration of the XML storage medium. .

Let's look at the structure of the Java DOM API.

The structure of the Java DOM API generated by XSD4j has a form of hiding all possible infrastructures from the developer as shown in FIG. In fact, among the DOM APIs, developers, Document , Collection , and User Defined XML Elements act as interfaces, and exception handling for errors is handled in XSEException .

In fact, the Java DOM API has a class structure diagram as shown in FIG. The grayed out classes in the figure are classes that depend on the generated XML schema, and the other classes are classes that apply to all XML schemas.

Let's take a look at the integration strategy between DOM objects and XML storage media.

The DOM objects are in memory, so the load on creating and maintaining them is small, while the XML storage media requires working with persistent storage devices, so the load on them is quite large. . Therefore, the operation (creation / modification / destruction) of the DOM object should be made independent of the actual XML storage medium, and it is essential to introduce a strategy for reflecting the work result on the XML storage medium when necessary.

The DOM objects in the Java DOM API that XSD4j creates are incomplete when they are first created, containing only the basic information (keys) to read data from the XML storage medium. After that, we complete the DOM object at the point where the data is actually needed, and take the strategy of reflecting the result on the XML storage medium when the work on the object is finally completed.

For this purpose, the DOM object has four status flags, DataReady , Dirty , Deleted , and Temporary , as shown in Table 5 (status flags of DOM objects).

Status flags condition DataReady Indicates whether the DOM object is complete or not Dirty The contents of the DOM object are modified Deleted The current DOM object is deleted Temporary The currently created DOM object is a temporary object that does not exist in the XML storage medium

DataReady is false the first time a DOM object is obtained. This means that the DOM object is in an incomplete state. Then, when access to the object is made, if DataReady is false, data is read from the XML storage medium and DataReady is true. An exception is when DataReady is true when a DOM object is created, which is when the contents of the current object are known when reading the data of the DOM object's parent object. This can happen, for example, using the shared inline RDB schema creation technique mentioned earlier.

Dirty has an initial value of false. And true when the contents of the DOM object are modified. Dirty DOM objects reflect the modifications made to the XML storage medium after all work is done. You can also explicitly store DOM objects in XML storage.

Deleted is false by default. And it is true when the user deletes the DOM object. DOM objects can be deleted collectively through Collections, or they can delete themselves. Deleted objects are not immediately deleted from the XML storage media. After all operations are completed, the deleted objects are reflected in the XML storage media.

Temporary state is used to add a new element. In other words, when you create a DOM object, it is in a Temporary state. When this object is added to the DOM object Collection, the temporary state is released, and after all the work is done, the added object is added to the XML storage medium.

Explore the support for XML data constraints in the Java DOM API.

Documents defined as XML schemas are stored permanently in XML storage media as described in the previous section, and the stored contents can be read back into the structure of XML. However, the methods so far can only deal with the structure of XML documents. This section describes how XML Schema can provide XML data constraints that define the validity of XML documents.

Data constraints in XML schema can be divided into two categories. The first is constraints on types, and the second is constraints on elements. In the former case, the simpleType has constraints on the range of values that the type can have. The latter restricts the number of times an element can appear in a complexType .

Constraints on types can be broadly divided into conditions for the size of the value and conditions for the length or pattern of the string.

The condition for size is generally applied to numbers and can be converted one-to-one with inequality operators. That is, minExclusive may correspond to '>', minInclusive to '>=', maxExclusive to '<', and maxInclusive to '<='.

Conditions for strings are length and pattern. The length can be checked using the string length function (in Java, the String.length () function). Patterns appear in the form of regular expressions, so they can be implemented by providing a separate regular expression engine.

Constraints for elements include maxOccurs , minOccurs , which indicate how many times an element can appear, and fixed and nullable conditions for the characteristics of the element's value.

MaxOccurs and minOccurs, which specify the maximum and minimum values that an element can appear in, are checked when creating a Collection of elements and when adding new elements to the Collection.

The fixed attribute, which indicates that an element must have a fixed value, and the nullable attribute, which indicates that an element can have a null value, are checked when the element is read and when the element is assigned a value.

[Application Example]

Let's take a look at the process of creating a simple XML application (Fig. 8) that outputs a list of purchase information and adds data using the simple XML schema (Fig. 5) related to the purchase information. The schema designed in Figure 5 creates an RDB schema for relational databases, such as Table 3 and Table 4, and the Java DOM API, as shown in Figure 7. This created a foundation for the application, and developers can develop applications by simply using the DOM API in this environment. In fact, the code you write is shown in Table 6 (the module that reads the XML data) and Table 7 (the module that adds data to the XML document).

try // XSEDocument (DB Host, DB User, User Password, Database Name) m_Doc = new XSEDocument ("localhost", "xse", "pwxsedemo", "xse"); XSECollection elemCol = m_Doc.getRoots (); int length = elemCol.getLength (); for (int i = 0; i <length; ++ i) XSEPurchaseOrderTypeElement elem = (XSEPurchaseOrderTypeElement) elemCol.getItem (i); out.println (displayPurchaseOrder (elem)); m_Doc.preDestroy () ; catch (XSEException E) out.println ("<P> XSE Error1:" + E.ErrorMsg () + "</ P>");

tryjava.sql.Date date = new java.sql.Date (today.getYear (), today.getMonth (), today.getDay ()); XSECollection col = m_Doc.getRoots (); XSEPurchaseOrderTypeElement elem = newXSEPurchaseOrderTypeElement (); elem .setorderDate (date); col.add (0, elem); col.UpdateAll (); XSECollection products = elem.getproducts (); XSEProductTypeElement prod = newXSEProductTypeElement (); prod.setvalue (product); products.add (0, prod); products.UpdateAll (); catch (XSEException E) out.println ("XSE Error3:" + E.ErrorMsg ());

As described above, according to the present invention, two steps of "designing a schema and developing an XML application" to a developer by introducing an XML schema and automatically generating an XML storage medium schema and a DOM API from the XML schema. It is effective to support the development process of.

Claims (6)

In the development method of the XML application program, A schema generation step of generating a schema including conditions of the XML application program; An XML schema generating step of generating an XML schema according to the object type of the schema; Generating an RDI schema using the XML schema; An interface generation step of generating an interface using the ALDI schema; And a development step of developing an XLM application program using the application program interface. The method of claim 1, The schema generation step, A diagram design process of designing a diagram including conditions of an application program; And an object list adding process of inputting necessary attributes and elements in the diagram to create an object of a corresponding class in XSCS, and adding the object list to an object list of a UML modeler. How to develop XML application program. The method of claim 2, The XML schema generation step, And a mapping process for mapping the UML and the XML skimmer. The method according to any one of claims 1 to 3, Aldibi schema generation step, The mapping rule of the XML schema and the Aldibi schema is a method of developing an XML application, characterized in that using a basic shared technique, a shared inline technique or a hybrid inline technique. The method of claim 4, wherein In the interface generation step, the interface is a development method of the XML application, characterized in that using based on the Dom API (SOM API) and / or SAX API (SAX API). The method of claim 5, The language used in the interface is a method of developing an XML application, characterized in that Java.