Home
| E-Business | Main
Page | My Profile
<% Response.write Date()%>
<% Response.write Time()%>
This paper proposes a new web application developing approach – 3-tier transparent web application developing approach (3TT). A web service model is presented in this paper. The web service model is written in XML. This web service model consists of nothing about implementation techniques except business logic, i.e., business logic is isolated from three tiers. Developers are focused on describing such a web service. That is the reason why three tiers are transparent to developers with 3TT. Moreover, an interpreting tier is utilized to interpret the web service model in order to implement three tiers functionalities. Based on isolation from implementation techniques, it is possible to implement exchangeable web services.
Web applications are becoming more and more useful. Web techniques can be found from a simple online shopping site to a large-scale e-business application among companies. This paper presents a new approach to build a web application. Through this approach, developers do not need to care about techniques in three tiers [1]. They are concentrated on business logic or requirement analysis and description. Three tiers are transparent to them. This approach saves much effort on web applications’ development.
Traditionally, all the applications are built over three tiers, the front tier (the client), the middle tier [2] (web server, servlet or CGI) and the backend tier (database). To build a web application successfully, all the three tiers are required to work collaboratively. Any business logic must be embedded into the three tiers in order to implement business transactions online. This approach has a lot of drawbacks on developing. First, developers have to spend much effort on tedious techniques in three tiers besides business logic analysis and description. Second, because business logic is embedded into three tiers, when changes happen to requirements, all the three tiers have to be changed. Third, based on this traditional developing approach, codes that can be reused should not be related to requirements or applications.
This paper proposes the 3-tier transparent web application developing approach (3TT). The key point of the approach is to isolate business logics from implementation techniques. The isolated business logic is equivalent to a web service model [3]. The web service model is described in XML and interpreted by the interpreting tier. The interpreting tier translates the web service model into three tiers’ functionalities.
A web service model is presented in this paper. Generally, a web service model is made up with five elements, workflow [4], user, organization, form and vocabulary. A workflow reflects relationships among users and organizations. Those relationships include C2C, B2C and B2B [5]. A user is a simulator of a real human in the virtual world. In fact, it is an interface for a real person to get involved into business transactions over Internet. An organization is a simulator of a real company over Internet. It consists of externals and internals, which are an organization’s properties. Forms always come out as a pair of request and response, which corresponds to a pair of actions. Vocabularies are fields that are located in forms, externals and internals. According to definitions of vocabularies, forms become understandable and can be processed by the interpreting tier.
An interpreting tier interprets web services descriptions so as to establish a web application. The interpreting tier includes many functional modules. These modules are able to understand and interpret semantics of web service [6] description. Descriptions of web services are interpreted as web pages, business logics and database by those functional modules. Because web services are isolated from implementation techniques in three tiers, it is possible to implement exchangeable web services. Thus, codes that can be reused are related to requirement or applications.
Section 2 presents the concept of 3-tier transparent web application developing approach and steps to do that. Section 3 puts forward a web service model. Section 4 introduces web service interpreting tier. Section 5 explains how exchangeable web services are implemented. Section 6 discusses future research on 3-tier transparent web application developing approach.
The section presents an approach to develop web applications without caring about implementation techniques in three tiers. Web pages, servlet/CGI and database are invisible to developers. They are focused on requirement analysis and business logic description. This approach is able to adapt to changes that always happen in requirements. Not only developing effort but also change adaptations are minimized by the approach.
Traditionally, to develop a web application, three tiers, i.e., front tier, middle tier and backend tier, are needed to consider. The front tier is used for interactions between users and web applications. The backend tier stores business data. The middle tier performs business logic and transmits information between clients and backend tiers. Only after the three tiers are developed, a web service is built. If business logic of a web service is changed, all the three tiers should be changed in order to adapt to the new business logic. It costs developers a lot of efforts. The key point is that most of efforts here are spent not only on business login descriptions but also on implementation techniques.
With 3TT, developers are focused on business analysis and descriptions. Details in three tiers are hidden. From end users’ point of view, a web service is usually equal to a series of requests and responses between clients and servers. With 3TT, developers design web services through defining those requests and responses, defining each field in those requests and responses and setting up a connection between a user and an organization or two organizations. The three steps are all what developers need to do with the 3TT when developing a web service. Those steps are closed to viewpoints of end users. So it is straightforward for developers to understand and grasp. All the efforts have no relation with implementation techniques in three tiers. It minimizes developers’ work. If changes happen to a web service, it might affect requests and responses, meanings of each fields and the connection between a user and an organization or two organizations. Changes also do not affect implementation techniques (codes) in three tiers. Change efforts are also minimized. All the efforts of developers on changing are almost focused on updating a web service from end users’ points of view.
As explained above, to develop a web service with 3TT, the procedure is similar to describing a web service from end users’ point of view. As an end user, a web service usually consists of a pair of request and response. When developers implement a web service with 3TT, their efforts are focused on describing requests and responses. The task is similar to designing forms. This is the first step to develop a web service with 3TT.
Although requests and responses are defined, it is still impossible to process requests and responses because all the requests and responses are designed from end users’ point of view. So after the first step, developers are required to define each field in requests and responses. According to the definitions, requests and responses are understandable and interpretable. Both of them can be processed. This is the second step to develop a web service with 3TT.
The last step is to set up a connection between a user and an organization or two organizations. For a simple web service, the connection is also simple. However, for complex business scenarios, such as a supply chain, the connection might be a tree or even a diagram.
According to the three steps to develop a web service, all the tasks are related to business requirement descriptions from end users’ point of view. Developers do not need to care about implementation techniques in three tiers that are not related to business requirements, such as web pages, servlet/CGI and database. They are focused on business requirement analysis and descriptions. So the approach is called 3-tier transparent approach.
This section presents how to depict a web service. It is important to depict a web service in an appropriate way. That is the key to implement the idea of 3-tier transparent web application development.
In the past, a web service is embedded into three tiers. A web service is implemented with the integration of the three tiers. So developers have to care about not only all the tedious techniques in three tiers but also the details how to integrate them so as to accomplish a web service. This approach costs much effort on implementation techniques that are not related to business logic. Furthermore, because an accomplishment of a web service is based on integration of three tiers, it is difficult to adapt to changes in web services. All the three tiers have to be modified together. In the traditional way, if changes happen to requirements, the change efforts sometimes are more than developing a new one.
According to the explanation to the traditional web application development, it is difficult to design and maintain a web application. The main reason is that a web service is embedded into each of the three tiers. So developers have to worry about many technical details in each tier and should be clear about how to integrate each tier together. It means a lot of efforts are spent on implementation techniques that are not related to business logic. Thus, in order to reduce developing effort, it is necessary to find one solution to isolate web services or business logic from each of three tiers.
A web service is a web-based business transaction that is accomplished with cooperation of several participants. These participants are virtual entities that can be represented or described over Internet. In 3TT, a web service consists of five entities. They are listed as follows,
 | Workflow
| User
| Organization
| Form
| Vocabulary | |
A workflow represents a connection among users and organizations. It reflects relationships among users and organizations. It can be a tree or a diagram. That depends on the complexity of a business transaction.
A user, which is a node in a workflow, is a virtual human over Internet. This entity is able to invoke requests to organizations and other users. It is a simulator and interface of a real customer in a particular business transaction. A real customer can interact with organizations and other users through it.
An organization is an entity that represents a business unit. Such a unit is also a node in a workflow. It can be looked as a simulator of a company that is involved in business transactions. An organization is an independent entity to participate a business transaction. It is different from a user because no real human beings can interfere its behaviors.
A form represents information transmitted within a workflow. Usually, forms consist of a pair of request and response. A form is associated with a behavior between a user and an organization or two organizations.
A vocabulary represents a field in a form. Each vocabulary includes information about which form it locates, where its value comes from, how to calculate its value and what impacts it brings to others. According to definitions of vocabularies, the interpreting Tier is able to process requests from users or organizations and give feedbacks in corresponding responses. After defining a vocabulary, the vocabulary becomes a meaningful keyword and is unique in the vocabulary library. No conflict on a vocabulary is allowed.
According to the definition of a web service, the description of a web service is equal to descriptions of its five entities. The integration of the five entities’ descriptions is a description of a web service.
To describe a web service, an appropriate description tool is important. In 3TT, XML [7] is chosen as the tool to depict a web service.
XML allows users to use any nametag. These independent nametags allow users to write documents meaningful to the context of the document. To comprehend these tags, XML provides various methods that include Document Type Definitions, Style Sheet, Parsers, and Extensible Linking Language, etc. Furthermore, XML is independent on platforms and tools. There is no barrier to use XML on different systems. So it is convenient to exchange XML data over Internet.
A workflow represents relationships among users and organizations. The relationships that a workflow includes are customer-to-customer, business-to-customer and business-to-business. The following figure shows all kinds of workflows.
border=0 v:shapes="_x0000_i1025">
According to the above figure, it is found that a workflow is made up with three factors, role, action and data flow.
A role is a participant in a workflow. It can be a user or an organization.
An action is a behavior of a user or an organization. An action is always associated with a form. Similar to a form, an action also has a corresponding action. For example, the action of buy has a corresponding action of sell. The action of buy is related to the order form, and the action of sell is related to the receipt form. The order form is a request and the receipt form is a response to it.
A data flow represents information in forms exchanged between two users, a user and an organization or two organizations.
As mentioned before, a user is a virtual human being in a workflow. A user is able to invoke a transaction in which the user get involved. To describe a user, two factors must be taken into account. One is the email system and another is an account. A real person is able to sign in with his account. He can also communicate with other users or organizations via email. One issue about the email system is that it is different when a user communicates with users from when the user communicates with organizations. When a user sends an email to another user, the receiver can understand whatever the format of the email is because both of them are real human beings. However, when a user contacts an organization, the email has to be in a format that can be understood by the organization. The format is the same as a particular form. Thus, the email system should be integrated with forms when users interact with organizations.
In 3TT, an organization consists of two elements, internals and externals.
Internals represent an organization’s factors that are invisible to outside. Only the organization itself is able to access them. For example, Current Cash is a factor that is invisible to outside. Only the organization itself has the right to change it during processing transactions. So Current Cash is one of internals in the organization.
Externals are an organization’s factors that are visible to outside. Users and other organizations can access externals when business transactions are being processed between them. For example, Merchandise is a factor that is visible to both users and other organizations outside. Anyone who would like to buy merchandises from an organization is able to know what the available number of the particular merchandise is and what its price is. So Merchandise is an external of such an organization. Meanwhile, Merchandise might consist of a few properties, such as InStock, Price and MerchandiseName. In some organizations, customer accounts might be externals. For example, in a bank, each account must have a saving or a checking. Users have the right to be able to access them.
A form is used to represent a request or response exchanged between a user and an organization or two organizations. For example, an order form is a request from a user to an organization. A receipt form is a response from an organization to a user. But forms here are different from real forms that are used in a store or a market. Forms here must consist of not only all the fields that are in real forms but also certain fields that are invisible to users or organizations. These invisible fields are used as temporary variables in order to calculate visible fields’ values.
After forms are defined, the next step is to define each field in forms. The aim to describe vocabularies is to make forms understandable. Otherwise, it is impossible that those forms are processed. The properties of a vocabulary are as follows
| Name
indicates the unique name of the vocabulary used in forms.
| InForm
indicates the form the vocabulary locates.
| Type
indicates the value type of the vocabulary.
| Source
indicates if the vocabulary comes from externals or internals. If so, the
Source value is External or Internal. If not, the Source value is null.
| SourceKey
indicates a key that is related to the vocabulary in externals or internals.
According to the key, the system is able to retrieve the value of the
vocabulary from externals or internals.
| PassiveFactor
indicates the first factor in forms that might determine the value of the
vocabulary.
| ActiveFactor
indicates the second factor in forms that might determine the value of the
vocabulary.
| Relation
indicates the arithmetic relation between PassiveFactor and ActiveFactor.
| ImpactName
indicates vocabularies may be affected after updating the vocabulary’s value. | |
After all the properties are defined, a vocabulary becomes a standard one in a vocabulary library. The vocabulary should be the unique one existing in the library in case of misunderstanding during the procedure of business transaction processing. According to the definitions of all the vocabularies in a form, the form becomes understandable and can be processed.
In 3TT, all the efforts developers need to do is to describe web services. The describing procedure is closed to describing business logic. There are no tedious techniques that have no relation with requirements in the web service description. It saves much effort to develop a web service. A web service model is shown in the following figure.
A web service is written in XML. A tier that is able to understand the semantics of XML will interpret the descriptions of a web service. The interpreting tier hides the three tiers from developers.
Although web services are described, it is still not a real web application. So right now the problem is how to convert those web services in XML to three tiers and how to perform three tier functionalities based on the descriptions of the web service. The web service interpreting tier is in charge of interpreting web services and generating corresponding three tiers functionalities.
Functional modules are able to understand semantics of XML and interpret that into particular functionalities. With the support of advantages of XML, different functional modules can interpret an entity in XML into different meanings. This feature can be shown in the following figure.
To establish a web application, the following functional modules are needed.
| DTD
parser is the fundamental to other functional modules. The module is able to
analyze the structure of XML/DTD. Other functional modules to generate
particular functionalities need to use the analyzing results of DTD parser.
| HTML
generator is able to understand and interpret entities in XML/DTD. After
interpreting elements in XML/DTD, the HTML generator creates HTML interfaces
in order that users are able to interact with web servers.
| Entity
generator is used to create specific entities based on analysis of XML/DTD
structure. Combined with input from interactive HTML pages created by the HTML
generator, an entity in XML becomes a specific and meaningful one instead of a
blank structure.
| Database
adaptor is capable to create database structures and SQL statements
automatically for an entity in XML based on analysis of XML/DTD structure.
Entities in XML are stored into database by it periodically.
| XML
repository adaptor is used to store all the entities in XML into an XML-based
file system automatically. The XML-based file system is called XML Repository,
which is just like a database. Entities in it are easy to store, modify and
retrieve.
| Search
engine adaptor is able to adapt to changes in XML entities and generate
corresponding search information automatically.
| Exception
processor is able to process exceptions during interactions between users and
organizations or business transaction processing procedures.
| Vocabulary
calculator is used to calculate value of each vocabulary according to
definitions of vocabularies. Vocabulary calculator is able to understand the
semantics to define a vocabulary. | |
The structure of web service interpreting tier is shown in the following figure.
All the functional modules are required to work collaboratively to interpret a web service. A web application consists of more than one web services. Such an application can be established through interpreting those web services.
The interpreting procedure can be explained by the following example.
A classic web service is shopping online. After users sign up or sign in a web application, they can take a search on externals of such an organization according to the descriptions of an organization. For example, a book might be one external of the organization. Users can learn the book’s price, author and content from the organization’s externals. The search adaptor based on analyzing externals in XML establishes the search functionality. Then users determine to buy it. Hence, they submit an order form. The form should be filled out online. So a dynamic HTML web page must be generated. The HTML generator is able to do that based on analyzing forms in XML. Users fill out the form and submit it. If any errors in the form when filling out it, the exception processor is able to make a feedback to users by creating a static HTML pages, which is also done by analyzing forms in XML. If no errors are found in the form, the entity generator creates a specific form based on the blank order form. The XML repository adaptor stores it into the XML repository automatically. After a correct order form is submitted, the web service interpreting tier processes the form. Each field in the form must be calculated according to definitions of vocabularies. The vocabulary calculator does that and a receipt form is generated according to the receipt form by the entity generator. The receipt form is also stored into the XML repository and a static HTML web page is created to notify users about their orders processing status. If there are some exceptions in forms, the exception processor will give a prompt to users during processing the order. All the entities in XML repository are stored into database periodically by the database adaptor.
Vocabulary calculator is the most important functional module. Actually, business transaction is processed by it. The vocabulary calculator follows the definitions of vocabularies. Actually, business logic is expressed in the combination of the definitions of vocabularies and forms. It is the key reason that 3TT is able to process business transactions.
When a form is being processed, each field in it must be scanned and its value should be calculated. All the calculating processes follow the definitions of vocabularies exactly. The following figure shows the exact procedure to calculate the value of each vocabulary.
According to the procedure, the value of each vocabulary is obtained. The vocabulary calculator first checks the Relation of the vocabulary. If the Relation is “match”, the vocabulary calculator tries to PassiveFactor and ActiveFactor so as to compare with them each other. If they are the same, that means match is successful. If not, that means match is failed. The Relation “match” is used to validate password, credit card number and etc.
If the Relation is not “match”, the vocabulary retrieves the value of the vocabulary in the following sequence,
i) Retrieve in the current form;
ii) Retrieve in the External and Internal;
iii) Calculate by the formula: value of vocabulary = [PassiveFactor] (Relation) [ActiveFactor]
If the value of the vocabulary can be obtained in one of the above steps, the left steps will not be executed. For example, in the order form, a merchandise’s Price must be obtained in the step i. A merchandise’s InStock can be found in Externals of an organization (i.e., step ii). A user’s Payment cannot be retrieved from the order form, Externals and Internals. But Payment’s PassiveFactor is MerchandisePrice and its ActiveFactor is OrderedNumber. Values of MerchandisePrice and OrderedNumber can be found from the order form. Furthermore, the Relation between MerchandisePrice and OrderedNumber is “multiply”. So the Payment value is equal to “MerchandisePrice Í OrderedNumber”. So the value of Payment is obtained.
After obtaining the value of the vocabulary, impacts of the vocabulary must be checked. Some vocabularies have impacts on others and some vocabularies have no impacts on others. One regulation here is that only Externals and Internals might be affected by vocabularies. For example, InStock is one property of an external. It must be affected by the value of OrderedNumber. InStock’s PassiveFactor is InStock and its ActiveFactor is OrderedNumber. The Relation between InStock and OrderedNumber is “minus”. So the value of InStock is equal to “InStock – OrderedNumber”. Until impacts are processed one vocabulary calculation is done.
According to the above explanation, it is clear that the Vocabulary Calculator is able to understand semantics of vocabularies. Moreover, business logics are expressed in the definitions of vocabularies and forms. They are not embedded into three tiers as traditional approaches. Based on interpreting each vocabulary and processing each form, business logic is completed by the Vocabulary Calculator. In this way, with other functional modules’ support, a web service is established without caring about three tiers’ details that have no relation with business logic. Thus, a web application is set up after several web services are established with 3TT.
In the past, if a new web service is needed in a web application, developers have to redesign the system structure in order to accommodate the new service. All the three tiers are required to code again even if the service has already been implemented by other web applications.
With the approach of 3TT, a web service is exchangeable. That means if a web service in another web application meets requirements, it can be exchanged to the target web application. The exchanged service is implanted into the target web application seamlessly.
One condition to implement exchangeable web services is to isolate business logic from techniques.
Traditionally, business logics are embedded into three-tiers or codes. So once requirements change, developers have to modify the application system in codes. At that time, only codes that are not related to applications or requirements can be reused. That kind of codes might be functions and components. But even those codes cannot be exchanged among applications.
If business logics are isolated from codes or techniques, it is possible not to modify codes when changes in requirements occur. Only business logic descriptions are required to change. Here, web service exchanged to a target web application is able to modify business logic descriptions. In this way, new features are added without recoding.
To isolate business logics from techniques, it is essential to find a tool to describe them. XML is a good candidate to do that. First, tags in XML can be defined freely. Developers can choose meaningful tags to represent particular information. Second, XML can be used to represent complex data structure such as trees and diagram. Almost all the entities in the real world can be represented by XML. Third, XML is an international standard and it is independent of platforms and tools. So it is a good approach to exchange data over different platforms and tools. Fourth, XML is understandable and interpretable not only by human beings but also by software. Each entity in XML can be interpreted as different meanings by different software modules. So it is easy to design an interpreting tier based on XML.
After business logics are isolated from implementation techniques, it does not mean a web application is built. An interpreting tier must be designed and developed with traditional techniques. But when designing such a tier with techniques, the principle is to implement required functional modules that are able to understand and interpret descriptions of business logics. Thus, the tier should be able to adapt to different business logic changes. Exchangeable web services are exchanged over those interpreting tiers. Actually, the essence of exchangeable web services is to implement exchangeable business logic.
Although 3TT makes web applications develop easily, there still exist some drawbacks. It is straightforward to ask a question – is it possible to use the approach to implement complex business transactions such as B2B or supply chain management? Is it possible to develop general client/server applications with the approach? Finally, what about the performances of web applications built with 3TT?
Although business logic requirements are met with 3TT, it is difficult to generate practicable web pages. Now only web pages related to business logics are created. In the meantime, those web pages are too simple. It is better to allow artists to design practicable web pages based on those pages. Furthermore, practicable web applications usually have some web pages that have no relation with business logics. This is another issue how to integrate the two types of web pages together.
Similar to web applications, ordinary client/server applications are also built over three tiers structure. It is possible to design a 3-tier transparent client/server applications developing platform. GUI generator needs to design because such a system usually has high requirements on GUI at client ends. This GUI generator should be able to work based on XML.
B2B or supply chain management has more complex business scenarios. Is it possible to describe such a complicated business logics in the same way as mentioned in the paper? If not, what issues are existed in it? What solutions to deal with so complex business?
Although most functional issues in web applications are resolved with the new approach, it is still a problem what about the nonfunctional issues, such efficiencies, security, safety and scalability. All the issues have not been considered.
[1] Srinivas Koushik and Pete Joodi, E-Business Architecture Design Issues, IT Pro, May 1, 2000
[2] Raymond J. Posch, Using Middleware for Interoperable Systems, 1999 by CRC Press LLC
[3] Adam Bosworth, Developing Web Services, 2001 IEEE
[4] Rob Allen, Workflow: An Introduction, http://www.wfmc.org/
[5] Nitin Nayak, Kumar Bhaskaran and Raja Das, Virtual Enterprises – Building Blocks for Dynamic e-Business, 2002 IEEE
[6] Sheila A. McIlraith, Tran Cao Son, and Honglei Zeng, Semantic Web Services, 2001 IEEE Intelligent Systems
[7] Jaideep Roy and Anupama Ramanujan, XML: Data’s Universal Language, 2000, IEEE
<?xml version="1.0"?>
<!DOCTYPE OwnerAction SYSTEM "owner_action.dtd" >
<OwnerAction>
<ActiveOwner>
<Owner>libing</Owner>
<Action>buy</Action>
<Accepter>EggHead.com</Accepter>
</ActiveOwner>
<ActiveOwner>
<Owner>EggHead.com</Owner>
<Action>sell</Action>
<Accepter>libing</Accepter>
</ActiveOwner>
</OwnerAction>
OrderOnline_action.xml
<?xml version="1.0"?>
<WorkflowUserTree>
<EggHead.com>
<libing/>
</EggHead.com>
</WorkflowUserTree>
OrderOnline_node_tree.xml
<?xml version="1.0"?>
<!DOCTYPE WorkStatus SYSTEM "workflow_status.dtd" >
<WorkStatus>
<Node>
<UserName>EggHead.com</UserName>
<Status>wait</Status>
</Node>
<Node>
<UserName>libing</UserName>
<Status>wait</Status>
</Node>
</WorkStatus>
OrderOnline_status.xml
<?xml version="1.0"?>
<!DOCTYPE WorkflowUserIndex SYSTEM "workflow_user_index.dtd" >
<WorkflowUserIndex>
<WorkflowUser>
<SourceUser>libing</SourceUser>
<TargetUser>EggHead.com</TargetUser>
</WorkflowUser>
</WorkflowUserIndex>
OrderOnline_node_index.xml
<?xml version="1.0"?>
<!DOCTYPE UserInbox SYSTEM "user_inbox.dtd" >
<UserInbox>
<Mail>
<From>admin</From>
<To>libing</To>
<Subject>Re: UserInfo</Subject>
<Content>OK, you are allowed to join.</Content>
<Replyable>001</Replyable>
<Time>Sun Sep 16 09:58:18 MST 2001</Time>
<New>yes</New>
</Mail>
<Mail>
<From>admin</From>
<To>libing</To>
<Subject>ChineseWF</Subject>
<Content>Please finish the assignment, OK?</Content>
<Replyable>001</Replyable>
<Time>Sun Sep 16 11:17:21 MST 2001</Time>
<New>yes</New>
</Mail>
</UserInbox>
libing_inbox.xml
<?xml version="1.0"?>
<!DOCTYPE UserOutbox SYSTEM "user_outbox.dtd" >
<UserOutbox>
<Mail>
<From>libing</From>
<To>EggHead.com</To>
<Subject>OrderOnline</Subject>
<Content>Action: buy</Content>
<Replyable>010</Replyable>
<Time>Sun Sep 16 11:40:40 MST 2001</Time>
<New>yes</New>
</Mail>
<Mail>
<From>libing</From>
<To>EggHead.com</To>
<Subject>OrderOnline</Subject>
<Content>Action: buy</Content>
<Replyable>010</Replyable>
<Time>Sun Sep 16 17:03:12 MST 2001</Time>
<New>yes</New>
</Mail>
</UserOutbox>
libing_outbox.xml
<?xml version="1.0"?>
<!DOCTYPE People SYSTEM "UserInfo.dtd" >
<Account>
<UserInfo>
<ConciseDescription>admin desc</ConciseDescription>
<UserName>admin</UserName>
<Password>111111</Password>
<Privilege>111111111</Privilege>
<Manager>Administrator</Manager>
</UserInfo>
<UserInfo>
<ConciseDescription>libing desc</ConciseDescription>
<UserName>libing</UserName>
<Password>111111</Password>
<Privilege>111111111</Privilege>
<Manager>admin</Manager>
</UserInfo>
</Account>
UserAccount.xml
<?xml version="1.0"?>
<ExternalPool>
<CurrentCash>12385.0</CurrentCash>
</ExternalPool>
EggHead.com_internal.xml
<?xml version="1.0"?>
<ExternalPool>
<ExternalName>libing</ExternalName>
<Username>libing</Username>
<CreditCardNumber>1234567890</CreditCardNumber>
<Password>111111</Password>
</ExternalPool>
EggHead.com_libing.xml
<?xml version="1.0"?>
<ExternalPool>
<ExternalName>PC</ExternalName>
<InStock>3</InStock>
<MerchandisePrice>399</MerchandisePrice>
</ExternalPool>
EggHead.com_PC.xml
<?xml version="1.0"?>
<!DOCTYPE FormFormat SYSTEM "form_format.dtd" >
<FormFormat>
<Table>
<TableName>OrderForm</TableName>
<Schema>
<Field>
<FieldType>null</FieldType>
<FieldName>OrderNo</FieldName>
<Display>Order Form</Display>
<Exception>NA</Exception>
<ExceptionDisplay>null</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>OrderForm:ExternalName</FieldName>
<Display>Ordered merchandise</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in ordered merchandise</ExceptionDisplay>
</Field>
<Field>
<FieldType>int</FieldType>
<FieldName>OrderedNumber</FieldName>
<Display>Ordered number</Display>
<Exception>>=0</Exception>
<ExceptionDisplay>Error in ordered number</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>InputCreditCardNumber</FieldName>
<Display>Credit Card Number</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in credit card number</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>OrderFormBuyer:ExternalName</FieldName>
<Display>Buyer</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in buyer</ExceptionDisplay>
</Field>
<Field>
<FieldType>float</FieldType>
<FieldName>MerchandisePrice</FieldName>
<Display>null</Display>
<Exception>null</Exception>
<ExceptionDisplay>null</ExceptionDisplay>
</Field>
<Field>
<FieldType>float</FieldType>
<FieldName>Payment</FieldName>
<Display>null</Display>
<Exception>null</Exception>
<ExceptionDisplay>null</ExceptionDisplay>
</Field>
</Schema>
</Table>
<Table>
<TableName>ReceiptForm</TableName>
<Schema>
<Field>
<FieldType>null</FieldType>
<FieldName>ReceiptNo</FieldName>
<Display>Receipt Form</Display>
<Exception>NA</Exception>
<ExceptionDisplay>null</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>OrderNo</FieldName>
<Display>Order No</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in order number</ExceptionDisplay>
</Field>
<Field>
<FieldType>float</FieldType>
<FieldName>Payment</FieldName>
<Display>Payment</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in payment</ExceptionDisplay>
</Field>
<Field>
<FieldType>int</FieldType>
<FieldName>MerchandisePrice</FieldName>
<Display>Merchandise Price</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in merchandise price</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>OrderForm:ExternalName</FieldName>
<Display>Merchandise Name</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in ordered merchandise</ExceptionDisplay>
</Field>
<Field>
<FieldType>varchar(20)</FieldType>
<FieldName>CreditCardNumber</FieldName>
<Display>Credit Card Number</Display>
<Exception>null</Exception>
<ExceptionDisplay>Error in credit card number</ExceptionDisplay>
</Field>
</Schema>
</Table>
</FormFormat>
form_format.xml
<?xml version="1.0"?>
<!DOCTYPE ActionResource SYSTEM "action_form.dtd" >
<ActionResource>
<ActionItem>
<Action>buy</Action>
<Form>OrderForm</Form>
</ActionItem>
<ActionItem>
<Action>sell</Action>
<Form>ReceiptForm</Form>
</ActionItem>
</ActionResource>
action_form.xml
<?xml version="1.0"?>
<!DOCTYPE VocabularyLib SYSTEM "vocabulary_lib.dtd" >
<VocabularyLib>
<Vocabulary>
<Name>CurrentCash</Name>
<InForm>Internal</InForm>
<Type>float</Type>
<Source>Internal</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>CurrentCash</PassiveFactor>
<ActiveFactor>Payment</ActiveFactor>
<Relation>add</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>Payment</Name>
<InForm>OrderForm</InForm>
<Type>float</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>MerchandisePrice</PassiveFactor>
<ActiveFactor>OrderedNumber</ActiveFactor>
<Relation>multiply</Relation>
<Impact>
<ImpactName>CurrentCash</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>InStock</Name>
<InForm>External</InForm>
<Type>int</Type>
<Source>External</Source>
<SourceKey>OrderForm:ExternalName</SourceKey>
<PassiveFactor>InStock</PassiveFactor>
<ActiveFactor>OrderedNumber</ActiveFactor>
<Relation>minus</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>MerchandisePrice</Name>
<InForm>OrderForm</InForm>
<Type>float</Type>
<Source>External</Source>
<SourceKey>OrderForm:ExternalName</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>OrderedNumber</Name>
<InForm>OrderForm</InForm>
<Type>int</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>InStock</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>OrderForm:ExternalName</Name>
<InForm>OrderForm</InForm>
<Type>string</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>CreditCardNumber</Name>
<InForm>External</InForm>
<Type>string</Type>
<Source>External</Source>
<SourceKey>OrderFormBuyer:ExternalName</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>InputCreditCardNumber</Name>
<InForm>OrderForm</InForm>
<Type>string</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>InputCreditCardNumber</PassiveFactor>
<ActiveFactor>CreditCardNumber</ActiveFactor>
<Relation>match</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>OrderFormBuyer:ExternalName</Name>
<InForm>OrderForm</InForm>
<Type>string</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
<Vocabulary>
<Name>OrderNo</Name>
<InForm>OrderForm</InForm>
<Type>string</Type>
<Source>null</Source>
<SourceKey>null</SourceKey>
<PassiveFactor>null</PassiveFactor>
<ActiveFactor>null</ActiveFactor>
<Relation>null</Relation>
<Impact>
<ImpactName>null</ImpactName>
</Impact>
</Vocabulary>
</VocabularyLib>
