This chapter is from the book
This chapter is from the book
This chapter is from the book
11.3 Architecture
11.3.1 Overview
As discussed in the previous section, a TAU.NET node is implemented as an extension for the Cell Systems under .NET Framework. It supports the communication between the Cell Systems of the participant agencies.
A TAU.NET member system is composed of a TAU.NET Node and a Cell System. The TAU.NET Node consists of two sets of components, TAU.NET Node Interface and TAU.NET Node Adaptor.
As shown in Figure 11-3, the Cell System contains three major modules, corresponding to the business functions that were discussed in Section 11.1.
)
Figure 11-3 Architecture of TAU.NET Node.
These are
- Inquiry module
- Reservation module
- Bill/Payment module
The modules in the Cell System are linked to the corresponding components in the TAU.NET Node so that their functions can be extended to the distributed environment of TAU.NET. The TAU.NET Node Adaptor components include the Process component and Remote Request component; they talk directly to the Cell System modules. On the other hand, the TAU Node Interface components include the Server objects and Client Proxy object for the Web Services; they talk to the remote TAU.NET Nodes via the Internet.
When an agency initiates a distributed inquiry transaction, the Inquiry module of its Cell System puts a request to the Inquiry Remote Request component in its TAU.NET Node Adaptor. This component translates the user request into the appropriate request of remote Web Services. Then the Proxy object in the TAU Node Interface is instantiated so that the remote Web Services are invoked.
In order to invoke a remote Web Service, a SOAP request message is sent to the server site, where it is received by the Inquiry Server component. Calling the services or methods of the Inquiry Process component in the TAU.NET Node Adapter on the server site, the Inquiry Server component generates the query result and sends it back to the client's TAU.NET Node. In the TAU.NET Node Adapter on the server site, the Inquiry Process component interacts with the Inquiry module of the Cell System in order to fulfill the requested query.
On the client site, the Inquiry Proxy object receives the query result and passes it to the Inquiry module of the Cell System via the Inquiry Remote Request component.
Distributed Reservation and Bill/Payment transactions can be processed in a similar way. However, databases in the Cell Systems of both client site and server site need to be updated.
Components in TAU.NET Node Adaptor are implemented using ADO.NET, which supports consistent and scalable access to various data sources. Therefore, they need to be customized for different kinds of data sources so that all the discrepancies of the data sources are concealed from the TAU.NET Node Interface. That is, the requests and results are all represented as ADO.NET DataSet objects through which the TAU.NET Node Interface objects interact with the local data.
Furthermore, ADO.NET provides abundant functionality whereby the DataSet objects can be processed in a disconnected fashion. That is, DataSet objects are filled from the database; they are then manipulated in the TAU.NET Node Adaptor, and the database is finally updated if necessary. The Fill and Update operations are carried out in batch mode, but data manipulation can be performed without a database connection. That minimizes the required resource for the interaction between the TAU.NET Node Adaptor and Cell System.
In addition, business rules are also implemented in the components of TAU.NET Node Adapter. The data in DataSet objects is manipulated based on these rules.
The communication between TAU.NET Nodes is based on SOAP, and messages in XML format deliver the requests and results over the HTTP channels. Data of any type can be transferred. More specifically, the query results can be directly delivered as a DataSet object. Consequently, the components in TAU.NET Node Interface are very simple to implement; it simply provides a transparent channel for the TAU.NET Node Adaptors to their exchange DataSets.
11.3.2 Schema for Data Exchange
As we have decided, the DataSet class is used for data exchange. The DataSet can be represented in XSD Schema, which is an XML standard.
11.3.2.1 Schema for Inquiries About TAU Products and Services
Generally speaking, there are several fields in the schema that are crucial to a travel product or service:
- Unique Product/Service ID
- Category
- Destination or Location
- Rate and Unit
- Effective and Expiration date
In addition, there may be multiple line items as details and references to original sources.
The schema can be represented as DataSet, XML, and its outline in VS.NET.
See Figure 11-4 for DataSet ERD, and Figure 11-5 for XML outline and XML Schema file TauServiceDataSet.xsd.
)
Figure 11-4 TauServiceDataSet entity relational diagram in VS.NET.
)
Figure 11-5 Schema outline for TauServiceDataSet in VS.NET.
The schema file is in XML format as follows.
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema id="TauServiceDataSet"
targetNamespace=
"http://tempuri.org/TauServiceDataSet.xsd"
elementFormDefault="qualified"
xmlns="http://tempuri.org/TauServiceDataSet.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:element name="TauServiceDataSet"
msdata:IsDataSet="true">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="TAU_SERVICE">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SERVICEID"
type="xsd:string" />
<xsd:element name="BOOKINFOID"
type="xsd:string"
minOccurs="0" />
<xsd:element name="CATEGORYCODE"
type="xsd:string"
minOccurs="0" />
<xsd:element name="RATE"
type="xsd:decimal"
minOccurs="0" />
<xsd:element name="UNIT"
type="xsd:string"
minOccurs="0" />
<xsd:element name="EFFECTIVEDATE"
type="xsd:dateTime"
minOccurs="0" />
<xsd:element name="THROUGHDATE"
type="xsd:dateTime"
minOccurs="0" />
<xsd:element name="LOCATIONCODE"
type="xsd:string"
minOccurs="0" />
<xsd:element name="TAU_SERVICE_DETAIL">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SERVICEID"
type="xsd:string" />
<xsd:element name="LineItemOrder"
type="xsd:int" />
<xsd:element name="ItemDesc"
type="xsd:string"
minOccurs="0" />
<xsd:element name="ItemUrl"
type="xsd:string"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
<xsd:unique name="TauServiceDataSetKey1"
msdata:PrimaryKey="true">
<xsd:selector xpath=".//TAU_SERVICE" />
<xsd:field xpath="SERVICEID" />
</xsd:unique>
</xsd:element>
</xsd:schema>
11.3.2.2 Data Schema for Inquiries About Member Services
There is no central server in TAU.NET, nor is there any central controller in the entire Internet. As far as name resolving is concerned, TAU.NET may use Internet standards. That is, member systems store each other's reference information, and messages are passed between them to synchronize this reference information. To achieve this, the members should share the basic information about their service scope, such as category and destination or location.
The schema should have basic information fields, such as member ID, member name, and service URL. One member may have one or more categories of service to provide and one or more locations or destinations to serve. Figures 11-6 and 11-7 show the schema in two views.
)
Figure 11-6 Diagram of a member service information schema.
)
Figure 11-7 Document outline of a member service information
In XML format, the schema file of TauMemberServiceDataSet has text as follows.
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema id="TauMemberServiceDataSet"
targetNamespace= "http://tempuri.org/TauMemberServiceDataSet.xsd"
elementFormDefault="qualified"
xmlns=
"http://tempuri.org/TauMemberServiceDataSet.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:element name="TauMemberServiceDataSet"
msdata:IsDataSet="true">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="TauMember">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="MemberID"
type="xsd:string"
minOccurs="0" />
<xsd:element name="MemberName"
type="xsd:string"
minOccurs="0" />
<xsd:element name="WebServiceUrl"
type="xsd:string"
minOccurs="0" />
<xsd:element
name="TauMemberServiceCategory">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="CategoryCode"
type="xsd:string"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element
name="TauMemberServiceLocation">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="LocationCode"
type="xsd:string"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>
11.3.2.3 Other Schema for Data Exchange
The reservation transaction information schema is shown in Figure 11-8. The service may have booking information in diverse forms based on the category or vendor. BOOKDATA stores the booking data based on the schema referred by BOOKINFOID.
)
Figure 11-8 Schema for booking a service.
The schemas for data exchange to serve Billing and Payment transactions are beyond the scope of this case study.
11.3.2.4 Classes for the Schemas
When VS.NET is used to construct the schema, the corresponding classes are generated by the tool, creating programs TauServiceDataSet.cs, TauMemberService.cs, and TauBookDataSet.cs. Alternatively, the classes of a schema may be created using command xsd.exe. The following commands generate the classes in TAU namespace:
xsd TauServiceDataSet.xsd /dataset /n:TAU xsd TauMemberService.xsd /dataset /n:TAU xsd TauBookDataSet.xsd /dataset /n:TAU
11.3.3 TAU.NET Node Interface
11.3.3.1 Server Objects for Web Services
Having defined the schema for data exchange, we can work on setting the protocol of the Web methods for data exchange. Each member should implement all those Web methods in order to communicate with each other.
First, let's consider the Web Service for inquiries about products and services. Two criteria, category and destination or location, may be commonly used to inquire about travel services; consequently, two Web methods should be provided, as follows:
[WebMethod]
public TauServiceDataSet
GetServiceDataSetByCategory(
String categoryCode);
[WebMethod]
public TauServiceDataSet
GetServiceDataSetByLocation(
String locationCode);
The categoryCode string may be a code for information about lodging, airline tickets, or car rentals. The locationCode string is about the destination or location the travel agency serves.
Second, let's consider the Web Service for inquiries about member services. This method is used to get an overview of available services provided by this member. Using this information, other members can build up or refresh their own repositories for member services in TAU.NET.
[WebMethod] public TAU.TauMemberServiceDataSet GetMemberServiceInfo ();
Finally, let's consider the Web Service for making reservations. Two methods are required here. One is used to get the reservation information for a specific travel service:
[WebMethod] public TauBookDataSet GetReservationInfo(string serviceID);
The other one is for making a reservation on a particular service specified by a given DataSet:
[WebMethod] public string MakeReservation (TauBookDataSet bookData);
All these methods can be gathered in one Web Service file, TauService.asmx. Figures 11-9 and 11-10 show the Web Service Description screens on Internet Explorer.
)
Figure 11-9 -Using a Web browser to display the TauService Web
)
Figure 11-10 WSDL of the TAU.NET Web Service TauService.
11.3.3.2 Proxy Objects for Web Services
The .NET utility program, wsdl.exe, can generate the Client Proxy for the TAU.NET Web Service.
The following command creates the code TauService.cs, which defines a Client Proxy class, TauService in the TAU.Proxy namespace. The Client Proxy class serves as an access point at the client site to the remote Web Services.
wsdl http://localhost/TAU/TauService.asmx /n:TAU.Proxy
Because all the members implement a Web Service with a standard interface, the same service on various member systems may be invoked by using a general-purpose Client Proxy object. In this case, the URL of the target service needs to be specified as a property of the Client Proxy object. For example, if we want to request the Web method GetServiceDataSetByLocation in http://www.TauMember1.com, we first need to create a new object:
TAU.Proxy.TauService objService; objService = new TAU.Proxy.TauService();
Second, we set its Url property value:
objService.Url = "http://www.TauMember1.com/TAU/TauService.asmx";
Third, we instantiate the DataSet to receive the return:
TAU.Proxy.TauServiceDataSet objDataSetTemp; objDataSetTemp = new TAU.Proxy.TauServiceDataSet();
Finally, we specify the Web method to fill the DataSet:
objDataSetTemp =
objService.GetServiceDataSetByLocation(
"BOSTON");