Post on 28-Feb-2023
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: gueorgil@mscd.edu * Corresponding author
2) Web Messenger Inc Tzarigradsko Shousse, 7 km, Sofia, Bulgaria E-mail: alex@webmessenger.bg
3) San Francisco State University
1600 Holloway Avenue, San Francisco, CA 94132, USA
E-mail: ivogeorg@gmail.com.
4) Central Laboratory for Parallel Processing acad. G. Bonchev str.bl.25A, Sofia 1113, Bulgaria, E-mail: boyanov@acad.bg.
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.
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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:
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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>
Journal of Information Technologies and Control
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>
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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
Journal of Information Technologies and Control
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].
Journal of Information Technologies and Control
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.
Journal of Information Technologies and Control
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.