N-tier Architecture for Intercontinental Tracking System based on Lightweight Semantic Web Service...

Journal of Information Technologies and Control

1

N-tier Architecture for Intercontinental Tracking

System based on Lightweight Semantic Web Service

Processes

Iliya Georgiev*1, Alex Shikalanov

2, Ivo Georgiev

3 and

Kiril Boyanov4

1) Department of Mathematics and Computer Sciences Metro State College of Denver Campus Box 38, P.O. Box 173362, Denver, CO 80217, USA Fax. ++303 556 3362, Tel. ++ 303 673 9403 E-mail: [email protected] * Corresponding author

2) Web Messenger Inc Tzarigradsko Shousse, 7 km, Sofia, Bulgaria E-mail: [email protected]

3) San Francisco State University

1600 Holloway Avenue, San Francisco, CA 94132, USA

E-mail: [email protected].

4) Central Laboratory for Parallel Processing acad. G. Bonchev str.bl.25A, Sofia 1113, Bulgaria, E-mail: [email protected].

Abstract: The dominating trend is to create n-tier architecture with

web services that would allow the related enterprises to operate as a

single entity. The paper describes an approach to create lightweight

semantic web services to support easy prototyping of n-tier system,

which combines legacy software components and web service

processes. We propose an ontology framework for the web service

processes. The approach was practically implemented in a tracking

system under development.

Keyword: n-tier architecture, web services, lightweight semantic web

services.


2

1 Introduction

1.1 Open Web Services Architecture

The industry is entering a critical stage in the acceptance and support of higher-

level web services integrated systems. In the recent years the client/server model has

evolved into web-based computing, which is now evolving into web services model

(Fig.1).

In n-tier architecture, distributed computers with possible different run-time

environment (Microsoft .NET, IBM Web Sphere, J2EE, etc.) and application software

talk to each other exchanging messages using standard web services transport

protocols. Several open and industry standards strengthen the web services as a

mature technology ([2] Burner (2003), [8] Leavit (2004)). The information is

presented in XML self-describing text. The messages are packed according to the

SOAP specification that defines a message structure to include an optional header

element and a mandatory body element. The web services describe themselves using

WSDL defining messages that they accept and produce. The web services support

their own discovery by UDDI that is implemented as a separate web service to

provide the design-time and run-time discovery of web services.

The web services model has important characteristics. One is the computer-sensible

representation of product information, which has to be packed in XML form. The web

services are modeled as XML document retrievals and updates. Several worldwide

projects are to pack the product universal formats in XML documents ([9]Lubell

Client-server silos Web-based computing Web services in n-tier architecture

Internet

Server

Clients

Servers

Clients

Independent nodes

Figure 1 Evolution of distributed computing during the years


3

(2004)). Other aspect is that the web service distributed model is loose coupled. The

functions and the information are independent, the request load is asynchronous and

unpredictable, and the classical requirements to the transaction processing should be

changed because of the Internet communication efficiency.

1.2 Motivation

As web services become complex, the designers of an n-tier system will need skills in

concurrent processing to access the product information, in distributed database

management and messaging for enterprise integration. Very often, the design is

based on ad hoc approach where the complexity hides the basic n-tier architecture

features. The motivation for this research sprang up during the design of a tracking

system containing intercontinental located nodes. We have concentrated the

prototyping to web service ontology creating lightweight semantic services and also

to synchronization of the access to the shared data.

1.3 Contribution of the paper

The paper describes modeling approaches to support easy prototyping of n-tier

system based on web services. In this paper, we describe:

• a lightweight semantic model of web services based on a web ontology ;

• a synchronization model for control web services that is to help the design and the

debugging;

• practical results of the development of a tracking system.

2 N-tier Tracking System

2.1 System functionality

The system consists of geographically distributed independent nodes connected via

Internet. The nodes accept online information about the position and status of

containers and crates that are transported by the global transportation net. The nodes

run independently application software and support distributed database. All

functions of the nodes are advertised as web services.


4

2.2 Architecture

N-tier architectures address the integration of Web protocols and backend system

processing, user preferences, security, database integration, handling of unpredictable

user loads. Generally, the n-tier site can be partition functionality into logical groups

that can be maintained and deployed separately: web layer: web services; application

layer: business logic and application code; database layer: data and object store.

The system employs a set of classes and properties of web services that are

connected to different processes. This approach allows the system to encapsulate the

processing. The web services support XML messaging between nodes. Analyzing the

messages, events are generated, which activate different processes providing a

particular set of functionality. The processes manipulate objects, created dynamically

as separate threads.

During the development of the system, we followed the basics of the W3C

Semantic Web Activity [14] for declaring and describing web services that are based

on the well researched ontology structuring. This allows concentrating in semantic

relationship, synchronizing and information protection.

Client interface processes are to perform data exchange and manipulation. Human

personnel interact with a web browser, connected to a client interface process,

implemented as active server pages within the web server. Other clients are special

devices, which transfer asynchronically data about the position and status of the

containers or crates. Such devices are computerized barcode readers; GPS-based

devices or cell-phones based devices. A separate client software agents handle each

client interface device.

The application processes perform the workflow and the policy decisions. The

policy agents are coupled with software procedures to use and information that is to

be obtained from the database. Policy agents can be located, as appropriate,

throughout the system or can be handled as a central facility. Nothing in the

architecture favors either solution. For instance, all contract decisions could be made

in a central purchasing node but the fulfillment of the contracts to be spread between

several nodes. Inventory workout could be concentrated in a node with a central

database or dislocated between different nodes.

Database agents handle the interface to relational database, which stores all data

about the transportation, inventory, and payment stream. In special archive, all log

files are stored for recovery and inspection purposes. The web services, activated by


5

the events from the client agents, trigger the database agents to process the stored

information.

3 Models

3.1 System node model

For the purpose of our research, we make the following idealization of the system

node:

• Receives information and control messages from other nodes;

• Creates thread for each session with another node;

• Executes business logic;

• Invokes web services to retrieve information resources;

• Provides synchronization of the shared data access;

• Evaluates exit conditions and asynchronously send information and control

messages to other sites.

3.1.1 Web service process model

The web service model is based on the description, invocation and the execution of

individual services, each consisting of several operations. The manipulating of web

services by software applications is the semantic web objective [14], where the

complex tasks are formulated in form of processes. Semantical properties of the web

processes are expressed in form of ontologies [11]. Ontology is a document or a file

that formally defines relations among terms. In web service model, ontologies consist

of hierarchical definitions of importanat concepts and description of the properties of

each concept. The ontologies can be defined in DAML-OIL or OWL, which is an

ontology language describing the primitives in XML and RDF/RDF Schema [12].

The services are represented as classes (concepts). Knowledge about a service has

two important classes: service profile and service model. A service profile is a class

that describes what a service requires and what it provides. A service model is a class

that describes properties that concern the service implementation.

Two ontologies are important for designing the n-tier tracking system. Application

ontologies describe the domain of the software application under development.

Software ontologies describe the software development web services.

During the design of the tracking system we put two objectives for creating

prototypes of the web services:


6

- the structuring of the services to be described in the concepts of the

semantic web service initiative;

- the implementation of the services to follow the development

environment specifics aiming simplicity and performance.

The objectives are contraversial: fully using ontology languages could increase the

size of the application software because of the verbosity of the semantic markup. This

was the reason to describe the created services as light weight web service processes.

3.1.2 Synchronization models

In dealing with the design of synchronized and concurrent web services, it is useful

to be able to relate the problem at hand to known problems and to test any solution in

terms of its ability to solve these known problems. Our prototype adapts a high level,

event driven approach that is based on the theoretical paradigm writers-readers that

communicate via web services. Readers and writers compete for the shared

information. The classical model satisfied the following conditions: any number of

readers may simultaneously read the file; only one writer at the time may write the

file, if a writer is writing to the file, no reader may read it [6].

Some control web services perform operations implementing the synchronization

between multiple requests simultaneously and on a schedule, incorporating

information from the database, as it become available. Implementing these services

requires more advanced programming techniques such as multi-threaded and mutual

exclusion. We created prototypes of services that illustrate how to keep the persistent

product information synchronizing the competition between writer and readers in one

thread by serializing the information flow.

4 Modeling of light weight web service processes

4.1 Services in the tracking system

The created services in the tracking system specify only those functionalities that are

publicly provided to other nodes. They are mostly related with status of the containers

in time and space, inventory and other business information. Some services

preliminary receive information from the containers, others provide accumulated and

processed information. The complicated business logic implemented in the

application software (statistics, contract for renting and purchase, accounting, specific


7

of the transportation terminals) is not advertised by the services preliminary for the

security reasons.

Some of the services are:

Container Data Input: Some container issues a request to send status data:

location, transportation terminal or vehicle, etc. Such information could me manually

scanned by terminal personnel, or automatically sent by the container-embedded

computer. The service receives the information and stores it in the local database.

Container Data Broadcasting: The node sends a message to the other nodes that

there are changes in the local database.

Data Collection Daily Summary: The node shows the raw data points received

from a data source (container, terminal, XML file or directly EDI feed).

Terminal Data Collection Activity: The node provides information about the

transport units located at a terminal (container storage, ship, train station).

Equipment Damage, Retirement, and Lost: The node provides information about

the transport units that are recently damaged, repaired, POS (Put Out of Service) or

similar.

Equipment Life Span: The node shows all visited transportation points associated

with particular container.

Current Inventory: Shows the containers at a particular location or all available

locations at the time the report is requested.

Equipment in Transit: Shows the containers in transit between any or all pairs of

locations, optionally with the container status and type.

Equipment Flux: Shows the containers in flux in and out of a location, with initial

and final inventory levels.

Transportation Pipeline Throughput: Shows the history of the container

movement. It is a measure of the traffic between two locations. Specifically it

includes: containers shipped before the week and received during the week;

containers shipped before the week and not received yet; containers shipped the week

and received during the week; containers shipped during the week and not yet

received.

Inventory Reconciliation: The service compares the data from two sources (two

current inventory reports for example) side by side for some average idle time. Such

service is developed to enable the user to choose a particular cycle count event and

view the reports for own consideration.


8

Full Equipment Inventory Turns: The service shows what fraction of inventory has

turned around in a period, i.e. how many turns the inventory has performed. The

result could be also prepared/projected to a year.

Each service provides different user friendly views of the information. Each

report, wherever possible and whenever they are different, should have “summary”

and “detail” view. The services should link each other following the semantic. The

linking scheme has to be consistent and unambiguous (lightweight service). For

example, every time the detail view involves barcode identifier, each barcode has to

be connected to the container history service for that particular container.

There are user budgeted (target) quantities for most parameters in the system

(counts, thoughts, dwell times, transit times, etc).

4.2 Combining conventional software agents (processes) and web services

The tracking system combines several software components that have been

traditionally used for years separately: container scanning and geographically

recognition, distributed database, GUI, repair service, rent contracts, accounting, etc.

Agents will need to talk to web services that were built by different organizations for

use in unanticipated contexts. Without a way to discover the meaning of terms and

relationships, the functionality of a n-tier dynamic adaptable systems cannot be

reached. Semantic interoperability problems have a variety of causes such as

polysemy (a word has multiple meanings), synonymy (different words have similar

meanings), and inconsistent model assumptions and granularity. DARPA and the

World Wide Web Consortium (W3C) realized this and organized the Semantic Web

initiative to focus on machine-readable ontologies that are accessible to agents on the

web. Semantic web technology solves the polysemy and model

assumption/granularity problems by allowing a developer to mark up a document,

sensor, database schema, or legacy software interface by linking concepts (i.e.,

classes, relationships, instances) to other concepts defined in an ontology. Each

concept is referenced by means of a unique Uniform Resource Identifier (URI).

Semantic Web technology solves the synonymy problem by allowing explicit

declarations that term X in ontology or markup is equivalent to term Y in another

ontology or markup.

The working idea of the tracking system is to mark up various conventional

documents and database tables (using DAML-S or OWL), so that software agents can

interpret and reason with the information as shown in Figure 2. DAML supports the


9

representation of ontologies via extensions to recent web technologies including

XML and the Resource Description Framework (RDF)[4].

4.3 Service ontology

The service profile specifies the functionalities that are provided by the service,

together with a human readable description and additional requirements. Service

requesters (other nodes in the tracking system) use the profile to specify what services

they need and what they expect from such a service.

In the following example, we will use the current Web Ontology Language (OWL) to

illustrate the concepts of the lightweight service description. OWL contains modeling

concepts similar to class diagrams in the Unified Modeling Language (UML) plus

other modeling formalisms that originated in Artificial Intelligence knowledge

representation languages [5].

Ontology languages like OWL have more formally defined semantics than catalogs

and glossaries to ensure that agents interpret ontologies and markups in a consistent

manner [7]. Simple web service ontology is shown below. The first 4 lines declare

the XML namespaces followed by an ontology definition that states that this ontology

imports concepts from another ontology. This is followed by a series of class

definitions. In OWL, there are object properties and datatype properties. Object

Web pages: schema,

namespace, etc.

OWL ontologies

Software agents

Web services

Containers

queries

Other nodes

queries

Database

Figure 2. Interoperability between conventional processes + information via OWL ontologies

Markup links


10

properties represent class-to-class relationships. Datatype properties relate classes to

things like string and integer attributes.

Next statements declare the namespaces of the terminal ontology.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#" >

The header component follows. <owl:Ontology rdf:about="http://www.ctd-example.com/terminal"> <rdfs:comment>Ontology of the Terminal class in tracking system</rdfs:comment> <owl:imports rdf:resource="http://www.ctd-example.com/terminal.owl"> <rdfs:label>TerminalOntology</rdfs:label> </owl:Ontology>

The statements below define classes, each of which is given with a name. The BarCodeScanner is declared as a subclass of the class Terminal. The classes Terminal and Company have axiom (simple) definitions. The object restriction on the Container class states that only a company can be in a containerToCompany relationship with a container. The class Status is defined via direct enumeration of its members by using owl:oneof construct. <owl:Class rdf:ID="Terminal“/> <owl:Class rdf:ID="BarCodeScanner"> <owl:subClassOf rdf:resource="#Terminal"/> </owl:Class> <owl:Class rdf:ID="Company“/>

<owl:Class rdf:ID="Container"> <rdfs:subClassOf> rdf:resource="#Company"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="# containerToCompany "/> <owl:toClass rdf:resource="#Company"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Status"> <owl:subClassOf rdf:resource="#Container"/> <owl:oneof rdf:parseType=”Collection”> <owl:Thing rdf:about=”Intact”/> <owl:Thing rdf:about=”Damaged”/> <owl:Thing rdf:about=”Repair”/> <owl:Thing rdf:about=”POS”/> </owl:oneof </owl:Class>


11

The next statements define some object properties and a datatype property. <owl:ObjectProperty rdf:ID="terminalToLocation"> <rdfs:range rdf:resource=”#Location> </owl:ObjectProperty <owl:ObjectProperty rdf:ID=“ containerToOrganization "/> <owl:DatatypeProperty rdf:ID="geographical Place"> <rdf:datatype ="&xsd;string”/> <rdfs:range rdf </owl:DatatypeProperty>

The next example shows markup that corresponds to the ontology above. Markup

contains instances found on a web page that are linked to classes in the ontology

declared in the owl:imports statement. For example, ABC99999 is a container who

has a relationship with a company named TransporterGmbh and ABC99999 is the

same person as ABC mentioned in the document.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd =http://www.w3.org/2000/10/XMLSchema# xmlns:aac=”http://www.ctdeveloper/ship/extract.owl #”> > <owl:Ontology rdf:about=" http://www.ctdeveloper/ship/ "> <rdfs:comment>Ontology of the Ship class in tracking system</rdfs:comment> <owl:imports rdf:resource=" http://www.ctdeveloper/ship/ship.owl "> <rdfs:label>ShipOntology</rdfs:label> </owl:Ontology> <aac:Ship rdf:about="QueenAnn"> <owl:label>QueenAnn</owl:label> </aac:Ship> <aac:Company rdf:about="TransporterGmbh"> <owl:label> TransporterGmbh </owl:label> </aac:Company> <aac:Container rdf:about="ABC99999"> <aac: containerToOrganization rdf:resource="QueenAnn"/> <owl:sameIndividualAs rdf:resource="ABC"/> <owl:label> ABC99999</owl:label> </aac:Container>


12

5 Synchronization Models

5.1 Model Description

From a perspective of n-tier system, we extend the writer-reader model.

First, we consider more general case, typical for the specifics of the application.

Any of thread created for a node request or a thread of the internal process are

allowed to read or write the data area. Any method (procedure) that accesses the data

is considered a critical section and needs mutual exclusion solution. Suppose that the

shared resource is a spare parts catalog. Ordinary users read catalog to locate parts.

One or more nodes (writers) are authorized to update the catalog. In the classical

model, every access to the catalog would be treated as a critical section, which could

be unacceptable slow. At the same time, it is important to prevent writers from

interfering with each other and it is required to prevent reading while writing to

prevent the access of inconsistent information.

Second, the send or receive primitives of message passing communication implies

some level of synchronization: the receiver cannot receive a message until it has been

send by another node. When a send primitive is executed, there are two possibilities:

either the sending process is blocked until the message is received, or it is not.

Similarly, when a node issues a receive primitive, there are two possibilities: if there

is a waiting message, the message is received and execution continues; if there is no

waiting message the process is blocked or the process continues to execute. Thus both

the send and receive can be blocking or nonblocking. Nonblocking send and blocking

receive is the preferred combination. It allows a node to send one or more messages

to a variety of destinations. A node that must receive a message before it can do

useful work needs to be blocked until such a message arrives. In our synchronization

model the message passing can be used to enforce mutual exclusion.


13

5.2 Synchronization in the control web-service

In each PLM node there is a control web service that dispatches the access to the

shared data area. Our design of such control service oriented to PLM specifics is

schematically shown on Fig.3. There are two types of threads: session thread and

executive thread. Session threads are created under request from another node. They

control the message passing with the partner node and organize a queue to the shared

data. The basic thread Executive is a dispatcher of writers and readers from all session

threads; it is responsible for the mutual exclusion.

5.2.1 Session thread

Other nodes wishing to access the data area initialize a session, send a request

messages to the control service, are granted access with a reply messages, and

indicate completion of access with a "finalize" message. The control web service

creates a thread for each session with a partner PLM node. All messages with a

request to the shared data are stored in a queue of readers and writers. The

corresponding session thread manipulates the queue.

In general case, there are data dependencies between readers and writers (read-after-

write, write-after-read or write-after-write dependences). Here we could differentiate

two processing scenarios for so-called secure reader-writer problem. First is to keep

strong sequential flow in a session without creating child threads for concurrent

Local Variables

Condition Variables

Write Procedure

Read Procedure

Service

Procedures

MONITOR

Session Thread

R R … W

.

.

.

Session Thread

W R … R

Messages

Messages

Executive

Wait

or

or

condition

Wait buffer

bufferIn

Wait Buffer

bufferIn

Readers

Writers

Figure 3 Control service using a monitor


14

processing. The second approach takes advantage of a priori knowledge of the

dependencies and semantic of message information creating concurrent child threads.

Despite increased performance, we do not recommend the second approach for a

tracking system realm for several reasons: complexity, application dependent,

extremely difficult for debugging, controversial performance profit, etc.

5.2.2 Executive thread and monitor synchronization

Solutions to reader-writer problem normally use semaphores, barrier locks and

monitors. We have prototyped web services with a monitor construct that has been

implemented in most web-services run-time environment. Local variables are

accessible only by the monitor’s procedures (methods). All write and read methods to

the shared data are incorporated in the monitor. Although a reader or writer from a

session thread can enter the monitor by invoking one of its procedures, we can think

of the monitor as having a single entry point that is guarded so that only one process

may be in the monitor at a time. Other session threads that attempt to enter the

monitor join a queue of threads blocked waiting for monitor availability. Once a

reader or writer is in a monitor, it may temporarily block itself on condition by

issuing wait signal. It is then placed in a queue of threads waiting to reenter the

monitor when the condition changes, and resume execution at the point in its program

following the wait call. If a reader or writer that is executing in the monitor detects a

change in the condition variable it issues condition signal, which alerts the queue that

the condition has changed.

Analyzing the system specifics, we implemented three different policies in control

web services for managing shared information.

The first policy (first come first serve) is more oriented to share product

documentation. The readers have concurrent access to the information, which is

considered read-only. Behind the scene, the writer could change the original copy that

is later replicated through the system.

In the second policy (readers have priority) as long reader holds the resource and

there are new readers arriving, any writer must wait for the resource to become

available. The first reader accessing the shared resource must compete with any

writers, but once a reader succeeds, other readers can access directly the shared

information, provided that at least one reader is still in the critical section. Readers

can dominate the information resource so that the writer must wait until all readers

have completed.


15

The third policy (writers favored). Several applications need the update to take

place as soon as possible. When a writer accesses to the shared resource, any

subsequent reader must wait for the writer to gain access to the shared information

and then release it. This policy still allows a stream of readers to enter the critical

section until a writer arrives. Once a writer arrives, it takes priority over all

subsequent readers, except those already accessing the shared resource. When all

writers have completed, the readers are then allowed to use the information resource.

6 EXPERIMENTAL RESULTS

6.1 Tracking system development

We have implemented several prototypes of web services according to the selected

policies. The prototypes were used to create several versions of web services

incorporated in the development of tracking n-tier architecture with different

subsystems: for manipulating product documentation, container scheduling and real-

time tracking of auto spare-parts distribution. Each node runs distributed database.

Some of the subsystems are in experimental stage. Fully implemented is the

tracking and reporting subsystem of containers for auto parts. It tracks where the auto

part containers are in the network, in what condition they are, and how they are being

used. It reports statistics about the part movement and utilization.

The subsystem makes attempts to fix missing data, rearrange data, or enter missing

location data. The reports are related mostly with inventories and times spent by parts

in particular statuses and in transit. The reports are organized around a 2D graphical

agent that shows the node network and displays relevant information on a Mercator

map. The 2D interface contains important totals and links to the reports for auto parts.

Fig. 4 shows an example of the map and subsystem’s GUI.


16

6.2 Results and analysis

Leveraging web semantic model and a dedicated writer-reader model, we created a

robust framework, which help designer and programmers alike more quickly from

idea to implementation. In general, the opinion of the developers about our

prototyping approach has been very positive.

We carefully have analyzed the preferences of the developers to the priority policy

in different application-oriented web services. For our tracking system the clear

winners are:

• first-come-first-served policy for the product documentation subsystem;

• readers-have-priority for the scheduling subsystem;

• writers-favored for the tracking subsystem.

Development specifics are beyond the scope of the paper, but we explored a suite

of web service design patterns.

XML view of the information. Web services make XML schemas central to the

internal and external product data interpretation.

Usage of general purpose interfaces. The interfaces to the data elements are

recommended to be a combination of basic reader/writer interfaces like query, delete,

Figure 4 GUI of the developed PLM n-node system


17

update, and add. Because of their high latency, web services have to use large

messages activating generic processing of the data.

Symmetric web service design. For n-tier architecture it is useful to implement web

service pairs to exchange product information in one request-response cycle.

Non-blocking messaging. For services with non-predictable latency a good

approach is not to block on service access. The session thread can post a request to a

partner, after that use a response as acknowledgment, then disconnect, and later poll

the partner for completion. Also the session thread should clean up unresponsive

requests and take compensatory actions to handle duplicated messages that could

incrementally update service state.

Availability failure processing. The greatest limit of web services is the

vulnerability of the tracking functionality dependent on Internet availability. The

issue is to avoid blocking on network requests. This issue needs to be addressed both

organizationally and in service design. The web service has to support appropriate

cashing functions on the documents it produces so partners can reduce their service

requests.

Creation of ontology. Markup of the non-structured text sources is time consuming

activity. Each system processes a large quantity of legacy documents that need some

form of automated markup assistance.

7 RELATED WORK

There have been done much work in analysis of synchronization methods in

different levels (objects, components, web services) of distributed computing. Since

our prototyping is practically oriented to the specifics of tracking systems, it cannot

provide the complex functionality common to these methods. For the same reason, it

is also difficult to compare it to them. Nevertheless, several publications discussing

such methods have influenced our work. Our sources fall into several distinct areas.

Web services prototyping. The standard web services provided in the development

environment (MS .NET, J2EE, IBM Web Sphere’s) give excellent development

ideas. Good web service analysis is given in [8] (Leavit 2004) and [2] (Burner 2003).

[11] (Vincent 2003) focuses on the role of prototyping using scripts.

Semantic Web technology, ontology modeling. Experience in prototyping of

semantic web technology and explanation of challenges and corresponding research is

given in [6.1]. Survey of the most relevant ontological modeling approaches is made

in [5]. Formal ontology framework is proposed in [12].

https://www.researchgate.net/publication/234782151_Scripting_Web_Services_Prototypes?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==

https://www.researchgate.net/publication/234826776_The_Deliberate_Revolution?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==


18

Synchronization models and coordination. [1] (Buhr 1995) is an exhaustive survey

of monitors. [6] (Kang 1998) is an instructive analysis of 12 different scheduling

policies for the readers/writers approach.

[9] (Nanda et al. 2004) focuses on synchronization between components of a

decentralized composite web service in several nodes. XML messaging plays a strong

role in coordination. [3] (Ciancarini et al. 2002) focus on the XML specifics in

coordinating middleware.

8 SUMMARY AND CONCLUSION

N-tier decentralized systems have more complex coordination than other distributed

systems. In this paper we have focused on creating reliable prototypes of control web

services for a tracking system. We first determine modification of the writer-reader

theoretical paradigm and synchronization policies appropriate for the tracking system

functionality. Then we created well-defined prototypes of services that illustrate how

to keep the persistent product information, synchronizing writer and reader requests

from one partner node in one session thread by serializing the information flow. The

synchronization of the competition to shared data by a monitor is incorporated in a

executive thread that organizes the priority policy. Finally, we experimentally

evaluated each of them during the design and development of tracking system for

auto parts. In general, our synchronization modeling demonstrates improvement in

quality and scalability of the tracking system development.

Acknowledgment

Our thanks to the team for the precise development.

References

1 Buhr, P., and Fortier, M. 'Monitor Classification'. ACM Computer Surveys,

March 1995. .

2 Burner, M. 'The deliberate Revolution'. ACM Queue, vol. 1, No 1, pp. 29-38,

2003.

3 Ciancarini, P., Tolksdorf, R., and Zambonelli, F. ‘Coordination middleware for

XML-centric applications’. Proceedings of the ACM Symposium on Applied

Computing, 2002.

https://www.researchgate.net/publication/221000652_Coordination_Middleware_for_XML-Centric_Applications?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==






https://www.researchgate.net/publication/220095022_Synchronization_Analysis_For_Decentralizing_Composite_Web_Services?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==


19

4 DAML Initiative. DAML+OIL Ontology Markup. http:/www.daml.org.

5 Kalinichenko, L., Missikoff, M., Schiapelli, F., and Skvorzov, N. Ontological

Modelling. Proceeding of the 5th

Russian Conference on Digital Libraries, St.-

Petersburg, Russia, 2003.

6 Kang, S., and Lee, J. 'Analysis and Solution of Non-Preemptive Policies for

Scheduling Readers and Writers'. Operating Systems Review, July 1998.

7 Kogut P., J. Heflin. Semantic Web Technologies for Aerospace. Proceedings of

IEEE Aerospace Conference, 2003.

8 Leavit, N. ‘Are Web Services finally ready to deliver?’ Computer, vol.37, No

11, pp.14-18, 2004.

9 Lubell, J., R.Peak, V. Shrinivazan, and Waterbury, S. (2004) ‘Step, XML, and

UML: Complementary Technologies’. Proceedings of DETC 2004, Salt Lake

City, USA, 2004..

10 Nanda, M., and N. Karnik. ‘Synchronization Analysis for Decentralizing

Composite Web Services’. International Journal of Cooperative Information

Systems, vol. 13, No 1, 2004.

11 Pahl, C., and M. Casey. Ontology Support for Web Service Processes.

Proceedings of EEEC/FSE 2003, Helsinki, Finland, September 2003.

12 Smith, M., Chris Welty, and Deborah L. McGuinness . OWL Web Ontology

Language Guide. W3C Recommendation, http://www.w3.org/TR/2004/owl-

guide/

13 Vincent C. ‘Scripting Web Services Prototypes’. ACM Queue, vol.1, No 1, pp.

22-28, 2003.

14 W3C Semantic Web Activity. Semantic Web Activity Statement, 2002.

http://www.w3.org/sw.

https://www.researchgate.net/publication/221560233_Ontology_support_for_web_service_processes?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==

https://www.researchgate.net/publication/221560233_Ontology_support_for_web_service_processes?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==



https://www.researchgate.net/publication/4035961_Semantic_web_technologies_for_aerospace?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==

https://www.researchgate.net/publication/4035961_Semantic_web_technologies_for_aerospace?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==




https://www.researchgate.net/publication/228057927_OWL_Web_Ontology_Language_Guide?el=1_x_8&enrichId=rgreq-e7a057d7455e6ae11fa86028123a6939-XXX&enrichSource=Y292ZXJQYWdlOzIyODcxODY3OTtBUzoxOTAxMjk1MjgzODU1MzlAMTQyMjM0MTgyMDk5Ng==



N-tier Architecture for Intercontinental Tracking System based on Lightweight Semantic Web Service...

Documents

Transcript of N-tier Architecture for Intercontinental Tracking System based on Lightweight Semantic Web Service...