Download SyDUPRev - Waymond Scott

Title Of Invention
Method and System for Developing and Deploying Collaborative Applications on Multiple Data-Stores:
System on Devices (SyD)
Cross-Reference to Related Applications
Two co-pending utility patent applications on utilizing SyD framework to real-world
applications: (i) A System of Calendars on Independent Data-Stores and (ii) A Mobile Fleet
System.
Background of the Invention
Field of Invention:
This invention pertains to programming methodology for distributed applications and
middleware framework to support heterogeneous set of data stores and their mobility.
Description of Prior Art:
Limitations of Current Technology: The current technology for development of group
eService and database application over heterogeneous set of wired or wireless devices and
networks has several limitations. Developing an application requires explicit and tedious
programming on each kind of device, both for data access and for data communication. The
application code is governed by the type of device, data format, and the network. The database
server is typically a centralized logical entity providing only a fixed set of database services,
with little flexibility for user-defined ad hoc services or the ability of user applications to
dynamically configure a collection of independent data stores. Applications running across
mobile devices are complex because of the lack of persistence of their data due to their weak
connectivity. Other limitations include poor support for maintaining global consistency of data
stores, poor mobility and middleware support, difficult peer-to-peer interaction, and poor
support for Quality of Service (QoS), disconnectivity, location independence, and group
communication.
SyD is a methodology for rapidly developing collaborative application and is a specification for
a middleware framework that enables developers to develop distributed applications
independent of the underlying device, data, or network. SyD also consists of specifications for a
thin clientware that helps in hiding device, data, and network technology heterogeneity. The
SyD middleware can be implemented/deployed anywhere in the spectrum ranging from a
centralized server model to a pure peer-to-peer model. SyD allows application developers to
assume a "uniform" virtual device, "uniform" virtual data type, and a "uniform" fully connected
network regardless of the nature of the actual devices, data types, and network technologies and
topology. In addition, the SyD middleware provides support for group creation, group
maintenance, group communication, and quality of service, while handling mobility, and
disconnectivity. SyD is an object-based technology. Everything in SyD from data, to users to
groups of users are treated as objects.
1
SyD is fundamentally different from and superior to the existing database and middleware
technologies. The existing database technologies, such as the distributed and multi- databases,
either cannot handle a collection of independent databases, or are inflexible and need custom codes
dependent on the individual databases and their integration architecture. The user programs are
network-and-database specific, with limited capabilities bound by the database services provided.
SyD, on the other hand, hides the network and data heterogeneity completely from the platform
independent user program, provides a rich set of data and network services and Quality of Service
(QoS) guarantees, and allows for unlimited capabilities of providing user-defined ad hoc services
and dynamic groups.
SyD vs. Existing Middleware Technologies:
SyD framework specification enables qualitatice features which set it apart from the existing
middleware technologies. We now consider capabilities of some of the existing middleware
technologies, which may be leveraged to implement the SyD middleware. Currently, the
database interactivity and collaboration can be achieved by a mixture of existing technologies.
They include network programming, database access using JDBC in Java, XML, web
programming with servlets, and some newer coomunication protocols such as SOAP (Simple
Object Access Protocol) or the upcoming Microsoft .net/HailStorm architecture. Automating
many common network-programming tasks such as object location, registration, activation and
operation dispatching can be accomplished via the Common Object Request Broker
Architecture (CORBA) [6,14,43]. CORBA is mainly for client-server model, and usually
involves one server or a few servers. Enterprise Java Beans (EJB) [39,41,24] aims at leveraging
the transactional database support of enterprise networks. EJB creates enterprise-backbone
logic by hooking together legacy applications wrapped in Java. EJB is not about dynamic,
runtime, discovery, and reconfiguration of components. Distributed COM (DCOM) [35] is
another architecture which is a middleware designed by Microsoft that allows COM
components to transparently communicate over the network. Below is a comparison of current
middleware with SyD framework.

CORBA is object based but does not address QoS, mobility, disconnectivity, location
independence, group communication.

ALICE is CORBA with mobility support but does not address QoS, disconnectivity,
location independence, group communication, peer-to-peer deployment.

MobileIP is for mobility support in the Internet but does not address QoS,
disconnectivity, group communication, peer-to-peer deployment, and is not an enabling
middleware technology.

QoSArch provides QoS support in the Internet but does not address disconnectivity,
group communication, peer-to-peer deployment and is not an enabling middleware
technology.
2

Ipmulti provides multicast support in the Internet but does not address QoS, mobility,
disconnectivity, location independence, peer-to-peer deployment and is not an enabling
middleware technology.
SyD vs. Existing Database Technologies:
In today's omnipresent computer networks, the user is constantly interacting with data that is
stored in various devices that are part of the network. Individuals maintain their personal
databases such as address books or calendars while organizations have databases for all aspects
of the business, sometimes managed by huge ERP implementations or data warehouses with
terabytes of data. While these databases are of variety of sizes, in different models and owned
by different entities, there is an interaction among them and there exists a need for "database
collaboration" at the global application level. Database interactivity and collaboration demands
multiple functionalities: global constraint specification, global triggering mechanisms, global
querying etc. Database literature has primarily proposed three types of solutions to this
collaboration/sharing /global querying problem which has existed ever since DBMSs became
available in mid-sixties. We briefly summarize their salient features and compare the SyD
architecture with them in table below.
 Distributed Databases: Assumes a homogeneous set of databases [3] that are
geographically distributed but act as a single database with a single global schema which
is itself typically distributed and made available to all individual sites. This architecture
strives to achieve full transparency in terms of location, design, and distribution of data,
and the location and execution of applications [29] but was never offered as a full-scale
commercial system.

Federated Databases: Refers to a loosely coupled collection of databases in which a
central federated server maintains one or more predefined "unified schemas" which
represent a merging of the "export schemas" that represent the shared part of the
component databases [36]. This is the most investigated and oldest [7,16,36] area of
research including schema integration [4,12,13], O-O approach [20], security [30], and
consistency control [47].

Multi-databases: In this architecture [23,49], there is no single global schema, but based
on a global query or data request, a schema is constructed "on-the-fly" to support that
request.

Mobile Databases: This is a more recent development [17,1] which involves partially
replicated databases carried by clients on laptops and PDA’s, with particular attention
paid to location determination [10], cache management [5,37], cell-boundary crossover
problems [9,27], and battery power conservation among other problems [2, 19, 31,33,
40,]. Update propagation and synchronization are special problems when application
needs demand disconnected operation [28,48,15,32] or there are network failure
problems [45]. In table below we have summarize the comparative advantage of the SyD
architecture in comparison to these. The boldfaced entries show the places where SyD
can be claimed to be superior.

OO-DBMS: There are also commercial products called object-oriented database systems
(OO-DBMSs) such as Objectstore and O2 [see 11] that allow seamless application
3

development in Object-oriented languages and make objects persistent. They combine
features of an OO system: complex objects, object identity, encapsulation, types or
classes, inheritance, overriding combined with late binding, extensibility and
computational completeness. While SyD will be implemented using the O-O features
[14], we do not contemplate using a commercial OODBMS or developing a full-fledged
OODBMS.
Active object-oriented database systems [38,42] are especially useful in the area of
nonstandard applications in order to implement an event-driven and constraint-driven
system environment. Several approaches exist in literature integrating active concepts
into object-oriented databases. For most systems, their knowledge model is based on
Event/Condition/Action rules, and their execution model is based on coupling modes,
specifying the temporal relationships between rule triggering and condition evaluation,
and between condition evaluation and action execution, respectively. SyD allows
application developers to specify global triggers, execute global queries as well as
express global constraints. The implementation of SyD will be responsible for
maintaining global data integrity specified by the constraints, firing trigger rules
specified in global triggers as well as producing answers to global queries.
SyD vs. Existing Database Technologies
Issue
Use of Global
Schemas
Handling Ad
hoc Data
Sources
DBMS
Processing at
Client Site
SyD
Distributed
Database
Multi
Database
Federated
Database
NO
YES
Known to all
participants
NO
NO
NO
YES
Unified
predefined
schema for
each
application
NO
YES
YES
YES
NOT
NECESSARILY
Dynamic inclusion
of databases and
generation of views
YES
NOT
NECESSARILY
Mobile Database
NO
Involves subsets of
schemas with
replication
MAYBE
Can connect to new
sources at will
Location
Transparency
YES
YES
Intended
Limited
Limited
NO
Execution
Transparency
YES
YES
NO
NO
NO
Ability for Peerto-Peer Data
Requests
YES
NO
NO
NO
NO
4
Support for Ad
hoc Service
Creation
YES
NO
NO
NO
Note: The boldfaced YES are areas where SyD has a competitive advantage.
References
[1] B. R. Badrinath and S. H. Phatak, “An Architecture for Mobile Databases”, Department of
Computer Science Technical Report DCS-TR-351, Rutgers University, New Jersey.
[2] Budiarto, K. Harumoto, M. Tsuamoto, S. Nishio, and T. Taine, “Replica allocation
strategies for mobile databases”, IEICE Trans. Inf. & Sys vol.E81-D, no.1, pp.112--121,
1998.
[3] S. Ceri and G. Pelagatti. Distributed Databases. McGraw Hill, 1985.
[4] S. Chakravarthy, Whan-Kyu Whang, and S.B. Navathe, “A logic-based approach to query
processing in federated databases”, Information Sciences, 79:1--28, 1994.
[5] B. Chan A. Si and H. V. Leong, "Cache Management for Mobile Databases : Design and
Evaluation," Proc. Int'l Conf. on Data Eng., 1998, pp. 54-63.
[6] Common Object Request Broker Architecture, OMG, July, 1995
[7] U. Dayal and H. Hwang, “View definition and generalization for database integration in
MULTIBASE: A system for heterogeneous distributed databases”, IEEE Trans. Software
Engineering, SE-10, 6, 628-644, 1984.
[8] L. Dittmann, P. Fankhauser, and A. Maric, “A MetaCar -- a mediated eCommerce-Solution
for the Used-Car-Market”, In Ralf-Detlef Kutsche, Ulf Leser, and Johann Christoph Freytag,
editors, Workshop "Federated Databases", November 1999, Berlin, Germany, Proceedings,
pages 18--33. Technical University of Berlin, 1999.
[9] G. Dong and M. Mohania, “Algorithms for view maintenance in mobile databases”, In 1st
Australian Workshop on Mobile Computing and Databases, Monash University, 1996.
[10] M. H. Dunham, V. Kumar, “Location Dependent Data and its Management in Mobile
Databases”, Ninth International Workshop on Database and Expert Systems Applications:
414-419, 1998.
[11] R. Elmasri and S.B. Navathe Fundamentals of Database Systems, Ed 3, Addison Wesley,
2000.
[12] R. Elmasri, J. Larson, and S. Navathe. Schema Integration Algorithms for Federated
Databases and Logical Database Design. Technical report, Honeywell Corporate Systems
Develpment Division, Golden Valley, MN, 1986.
[13] M. Garca-Solaco, F. Saltor, and M. Castellanos. “A semantic-discriminated approach to
integration in federated databases”, Proc. of CoopIS-95, pages 19--31, 1995.
[14] C. Gransart and D. Simplot, "Communicating Mobile Objects, an overview,", The
Gemplus Developer Conference 2000, Montpellier, France, 20 -21 June 2000.
[15] J. Holliday, D. Agrawal, and A. El Abbadi, “Planned Disconnections for Mobile
Databases”, Technical Report TRCS 00-07, Department of Computer Science, University
of California at Santa Barbara, May 2000.
[16] D.K. Hsiao, “Federated databases and systems: Partone - a tutorial on their data sharing”,
VLDB Journal, 1:127--179, 1992.
[17] Imielinski, T. and B. Badrinath, Mobile Wireless Computing: Challenges in Data
management, CACM, 37:10, October 1994.
[18] E. Knapp, “Deadlock detection in distributed databases”, ACM Computing Surveys,
19(4):303-- 328, 1987.
[19] S. J. Lai, A. Zaslavsky, G. M. Martin, and L. H. Yeo, “Cost-Efficient Adaptive Protocol
with Buffering for Advanced Mobile Database Applications”, 4th International Conference
on Database Systems for Advanced Applications, DASFAA'95, April, 1995, Singapore.
5
NO
[20] Q. Li and D. McLeod, “An object-oriented approach to federated databases”, in
Kambayashi et al. [KRS91], pages 64--70.
[21] Y-B. Ling, “Failure Restoration of Mobility Databases for Personal Communication
Networks”, Wireless Networks, 1:367--372, 1995.
[22] Y.-B. Lin, “Eliminating Overflow for Large-Scale Mobility Databases in Cellular
Telephone Networks”, IEEE Trans. on Computers, April 2001.
[23] W. Litwin, L. Mark, N. Roussopoulos, “Interoperability of Multiple Autonomous
Databases”, ACM Computing Surveys 22(3): 267-293 (1990).
[24] T.F. Lunney and A. McCaughey, “Component based distributed systems CORBA and EJB
in context", Computer Physics Communications, 2000, in press.
[25] V. Madisetti, et al. 2001. System of Databases (SyD): Collaboration Links and
Applications, Procs.Industry Advisory Board Conference, Yamacraw, Atlanta, April
25-26. Provisional patent filed.
[26] V. Madisetti, et al., 2001. System of Databases (SyD): An Overview, In Procs. Industry
Advisory Board Conference, Yamacraw, Atlanta, April 25-26. Provisional patent filed.
[27] S. K. Madria, M. Mohnia, J. Roddick, “Query Processing in Mobile Databases Using
Concept Hierarchy and Summary Database”, Proceedings of 5th International Conference
on Foundation of Data Organization, Japan, Nov. 1998, 16-20
[28] S. Mahajan, M. J. Donahoo, S.B. Navathe, M. Ammar, S. Malik, "Grouping Techniques for
Update Propagation in Intermittently Connected Databases," in Proceedings of the IEEE
14th Int. Conf. on Data Engineering , Orlando, FL, February 1998.
[29] M. T. Oszu and P. Valduriez. Principles of Distributed Database Systems. Ed. 2, Prentice
Hall, 1999.
[30] G. Pernul , “Canonical Security Modeling for Federated Databases”, Proc. of IFIP
TC2/WG 2.6 Conf. on Semantics of Interoperable Database Systems (DS'5), Lorne,
Australia.
[31] S. Phatak and B. R. Badrinath, “Multiversion Reconciliation for Mobile Databases”,
Proceedings of the 15th International Conference on Data Engineering, 1999.
[32] S. Phatak and B. R. Badrinath, “Data partitioning for disconnected client-server databases”,
Proceedings of the MobiDE, August 1999.
[33] E. Pitoura and B. Bhargava, “A Framework for Providing Consistent and Recoverable
Agent-Based Access to Heterogeneous Mobile Databases”, ACM SIGMOD Record,
24(3):44--49, Sept. 1995.
[34] K. Ramamritham, “Real-Time Databases, Distributed and Parallel Databases” 1(1993),
pp.199-226.
[35] R. Sessions. COM and DCOM: Microsoft's Vision for Distributed Objects. John
Wiley & Sons,1997.
[36] A. P. Sheth and J. A. Larson, “Federated Database System for Mapping Distributed
Heterogeneous, Autonomous Databases”, ACM Computing Surveys, 22:3, September
1990, pp.183-236.
[37] A. Si and H.V. Leong, “Adaptive caching and refreshing in mobile databases”,
Personal Technologies, September 1997.
[38] M Skvld, “Active Database Management Systems for Monitoring and Control”, PhD
thesis, Linkvping University, Sweden, 1997.
[39] Sun Microsystems Inc. Enterprise java beans technology. http://java.sun.com/products/ejb/.
[40] J. Tayeb, “Design and Performance Evaluation of Indexing Methods for Dynamic
Attributes in Mobile Database Management Systems”, Master's thesis, Bilkent University,
May 1997.
[41] A. Thomas, Patricia Seybold Group, "Enterprise JavaBeans Technology."
http://java.sun.com/products/ejb/white paper.html, Dec. 1998.
[42] A. Vaduva, “Rule Development for Active Database Systems”, PhD thesis, Univ. of
Zurich, 1998.
[43] S. Vinoski, “CORBA: Integrating Diverse Applications Within Distributed Heterogeneous
Environments”, IEEE Communications Magazine, February, 1997.
[44] G. Walborn and P. K. Chrysanthis. “An Escrow Method to Support Disconnected Mobile
6
Database Operations”, CS Technical Report 95-09, University of Pittsburgh, Feb. 1995.
[45] T. P. Wang, C. C. Tseng and W. K. Chou, “An aggressive approach to failure restoration of
PCS mobility databases”, ACM Mobile Computing and Communications Review. 1(3),
21-28, 1997.
[46] M. Weeks, et al., 2001. System of Databases (SyD): Fleet System Application, In Procs.
Industry Advisory Board Conference, Yamacraw, Atlanta, April 25-26. Provisional patent
filed.
[47] G. Wiederhold and X. Qian, "Consistency Control of Replicated Data in Federated
Databases," Procs. of the IEEE Workshop on Management of Repl. Data, Houston, Texas,
Nov.1990, p.130-32.
[48] W. Yee, M.J. Donahoo and S.B. Navathe, “ A Framework for Designing Update Objects
to Improve Server Scalability in Intermittently Synchronized Databases,” Proc. ACM
CIKM Conf., Philadelphia, November 2000.
[49] C. Yu, W. Sun, S. Dao, and D. Keirsey, “Determining relationships among attributes for
interoperability of multi-database systems”, Proceedings of the1st International Workshop
on Interoperability in Multidatabase Systems, pages 251--257, Kyoto, April 1991. IEEE CS
Press.
Brief Summary of the Invention
System on Devices (SyD) is a specification for a middleware framework and a programming
methodology that addresses the key problems of heterogeneity of device, data format and network,
and that of mobility. SyD combines ease of application development, mobility of code, application,
data and users, independence from network and geographical location, and the scalability required
of large enterprise applications concurrently with the small footprint required by handheld devices.
SyD uses the simple yet powerful idea of separating device management from management of
groups of users and/or databases. Each device is managed by a SyD clientware (SyDCW) that
encapsulates it to present a uniform and persistent object view of the device data and methods.
Groups of SyD devices are managed by the SyD middleware (SyDMW) that brokers all interdevice activities, and presents a uniform world-view to the SyD application to be developed and
executed on. All objects hosted by each device are published with the SyD middleware that enables
SyD applications to dynamically form groups of objects hosted by devices, and operate on them in a
manner independent of devices, data, and underlying networks [25,26,46]. The SyD middleware
hosts the application and other middleware objects, and provides a powerful set of services for
directory and group management, and for performing group communication and other
functionalities across multiple devices. A detailed architecture is presented later.
Rapid Application Development: SyD allows rapid development of a range of portable and
reliable collaborative applications. The calendar application is an example of a typical SyD
application in which several individuals are maintaining their independent schedule information
in their hand-held devices [25]. The typical functionalities provided in such an application are:
(i) set up meeting among individuals with certain conditions to be met such as a required
quorum, (ii) set up tentative meetings which could not be set up otherwise due to unavailability
of certain individuals, and (iii) remove oneself from a meeting resulting in automatic triggers
being executed that may possibly convert tentative meetings into confirmed ones. To
implement the calendar application with the current technology involves cumbersome
7
programming, especially with respect to database activities such as opening connections to
database servers, executing individual queries against several databases and accumulating
results of these queries, and manually enforcing constraints (by writing code) that the databases
as a whole need to satisfy. Another problem with the current technology is that it is difficult to
deal with multiple types of heterogeneity that is potentially present in the representation of
schedule data in the calendar example. One individual may have a relational database while
others may be using a flat file to record their schedule data. In the section on “Detailed
Description”, we present the steps involved in developing Calendar and two additional SyD
applications, namely, a package delivery system comprising a fleet of trucks [46] and an airport
application. SyD provides well-defined steps and a layered middleware environment to quickly
develop application by composing and linking multiple existing and new constituent objects.
Heterogeneity and Mobility Addressed: SyD encapsulates different devices into a persistent
object framework thus addressing device and data heterogeneity problem. The uniform object
view and its persistence are enabled by the SyD clientware on each device. SyD seamlessly and
dynamically integrates a collection of disparate data-stores using a standard SyD middleware
that also enables development as well as execution of SyD applications completely independent
of device, data, and network. SyD empowers users and application developers by allowing
them to define ad hoc applications, ad hoc services over a collection of heterogeneous devices,
as well as ad hoc services on individual devices. The first two are enabled by the middleware
and the last by the device clientware. SyD middleware can function with or without a backbone
infrastructure, on weakly connected networks as well as on ad-hoc networks providing varying
levels of QoS guarantees. The SyD technology can possibly set standards in the future for
developing network application on Internet and other networks. Standard definition of
interfaces for the SyD clientware and middleware and their core objects allows third party
development of all SyD components. SyD’s uniqueness, compared to major database and
related technologies, also comes from the fact that it has been developed by a top-down
discovery method, starting with the considerations of applications, extracting their requirements,
then designing the SyD layers with functionalities needed to support these applications from the
standpoint of device, data and network independence, and of mobility. Section on “Detailed
Description” presents the core services offered by SyD middleware and clientware, and
provides insights into their implementation.
8
Brief Description Of The Several Views Of The Drawing
9
Detailed Description Of The Invention
1. Overview of SyD
This section presents a overview of SyD framework specification. After describing the SyD
architecture, an example of a SyD application is explored. Then, the SyD infrastructure is
briefly discussed. These topics are explored in depth in the subsequent sections.
1.1 What is SyD?
The System on Devices is a specification for a system to enable rapid prototyping and
implementation of applications that need a collection of heterogeneous, independent databases
to collaborate with each other. Each individual database in SyD may be a traditional database
such as relational or object-oriented, or may be an ad-hoc data store such as a flat file, an
EXCEL worksheet or a list repository. These may be located in traditional computers, in
personal digital assistants (PDAs) or even in devices such as a utility meter or a set-top box.
These databases are assumed to be independent of each other, i.e. they do not share a global
schema. The databases in SyD co-operate with each other to perform interesting tasks and we
envision a new generation of applications to be built using the SyD framework. The SyD
architecture is captured in Figure 1.
SyDApp
SyDAppO
Published Library of SyDCOs
SyD Middleware (SyDMW)
SyDMWO
SyD Clientware
SyD Clientware
SyD Clientware
SyDCO
--Ordered Data
On PDA’s
Oracle Lite
SyDCO
--Ordered data
On PC’s Outlook
SyDCO
-Ordered data on
A settop box
Figure 1. SyD Architecture
The SyD architecture has three layers. At the lowest level, individual data stores are
encapsulated by SyD Client Objects, referred to as SyDCOs. These client objects export the
data that the client devices hold along with methods/operations that allow access as well as
10
manipulation of this data in a controlled manner. At the middle layer, there is SyD middleware,
a logically coherent collection of services, APIs, and objects that facilitates the execution of
application programs. At the highest level are the applications themselves (SyDApps) that are
independent of device, database and network. They rely on the directory services maintained by
the SyD middleware. These applications include instantiations of SyDCOs, SyDApp Objects
that are aggregations of SyDCOs, and SyDMW objects. The three-tier architecture of SyD
enables applications to be developed in a flexible manner without knowledge of device,
database and network details.
SyD software technology is characterized by the following:
1. Ordered stores of data, be they formal databases or ASCII lists, stored on PDAs or on
mainframes, are supported by SyD client software that allows the construction, naming, and
publication of SyD Client Objects (SyDCO) that operate on these data stores through
methods.
2. SyD middleware (SyDMW) is responsible for making software applications (anywhere)
aware of the named objects and their methods/services, executing these methods on behalf
of applications, allowing the construction of SyD Application Objects (SyDAppO) that are
built on SyDCOs, and providing the communications infrastructure between SyD
Applications (SyDApps), in addition to providing QoS support services for SyDApps.
3. SyDApps are applications written by and for the end users (human or machine) that operate
on the SyDAppOs alone and are able to define their own services that utilize the
SyDAppsOs, without directly depending on either the location or the type of database or
type of device (PDA or mainframe) where a certain information field is stored. The SyD
middleware (SyDMW) provides only a named SyDCO for use by the SyDApps, without
revealing the physical address, type or location of the information store.
SyDApps are thus truly portable, network and database independent, and are able to
operate across multiple networks and multiple databases, relying on the SyDMW to provide the
supporting services that translate the SyDApps code to the correct drivers, for both
communications and computing, translating and interpreting and eventually conveying
instructions for the execution of one or more SyDCOs. SyDApps can also decide on their own
features and services they offer, without relying on these services being offered by individual
databases residing on remote computing devices.
1.2 SyD Applications
As an example of the SyD framework, we use an individual’s (say Phil) calendar as a basic
SyDCO. This calendar could be stored on a PC, a web server, or a PDA that supports the SyD
clientware software. The SyD clientware names and publishes the SyDCO object,
Phil_calendar_sydco and registers this object with the SyD middleware, SyDMW. A SyDApp
constructs an object called Calendars_of_phil+andy+suzy_SyDAppO that “links” together and
defines a set of methods that can operate on the calendar objects of all three individuals,
assuming Andy and Suzy also publish their calendar SyDCOs for use by SyDApps via the
SyDMW.
11
The SyDAppO called Calendars_of_phil+andy+suzy_SyDAppO may support the
following methods:
Find_earliest_meeting time(),
Change_current_meeting_time_to_next_available (), etc.
The SyDAppO, Calendars_of_phil+andy+suzy_SyDAppO would be instantiated from a general
class called Calendars_of_committee_SyDAppC that could be provided by a vendor or written
by users themselves.
What is important to note is that the execution of the SyDApps is reliant on the SyDMW
for locating, communicating with, and operating on the various SyDCOs that could be
distributed across the internet, intranet or an ad hoc heterogeneous network, and the SyDMW
could be hosted on a local machine or hosted through an Application Service Provider (ASP).
The SyDMW is also responsible for QoS issues as required by the SyDApps. Figure 2 clarifies
the composition of SyDAppOs through an UML object diagram.
Figure 2. UML object diagram of SyDAppO architecture: SyD application objects (SyDAppO) consist of
SyD middleware objects (SyDMWO). SyD middleware objects are either SyD client objects (SyDCO) or
SyD link objects (SyDLink). A SyD link object is a link among a number of SyD client objects. SyD link
objects are primarily of two types: coordination and subscription links.
How would this application work in current practice? In current practice, the
calendars of each user would have to be located explicitly and entries would have to be written
explicitly by the committee calendar program to each unique database, after taking into
12
consideration that it is a PDA or a PC or a web-server, each with its own native communications
mechanism. The resultant code would also not be portable, and very difficult to maintain.
Methods that can trigger the committee calendar when individual calendars are changed cannot
be easily written and their execution is not efficient.
1.3 SyD Infrastructure
The SyD infrastructure is discussed in brief in this section. Detailed treatment appears in
Section 3. The SyD infrastructure includes two major components: the SyD middleware and the
SyD clientware. The responsibilities of SyD middleware include:
1. Directory and Ad-Hoc Group Management services: The SyD middleware maintains a
directory of active devices, their proxies (if any), active applications, active groups of
devices/users, etc. The middleware is also responsible for maintaining a directory of
SyDCOs that have been published by the individual devices, as well as the SyD middleware
objects (SyDMWOs) that may provide domain-specific services, such as financial services.
It maintains dynamic information on all objects and their proxies, their methods and
services, and QoS gurantees, and supports efficient, yellow- page-like, searching of objects
by (i) name, (ii) of specified classification, (iii) with a particular method or (iv) of specified
QoS guarantees on one or more methods, and thus supports run-time substitution of
SyDCOs by the SyD middleware,
2. Communication and Event Management Services: SyD Middleware is responsible for
providing communication services across devices. Services such as broadcast and multicast
to a group of devices are included in these services. Event management service listens for
the events specified by the users on the ad-hoc objects created by them. It propagates the
event to the event listeners when the event occurs.
3. SyD Quality of Service management: SyD middleware provides communication specific
QoS support, such as reliability, quorum, delay, cost, fault-tolerance, real-time constraints.
4. SyD Data Services: The middleware provides data services that include global querying and
update of data stores managed by the SyDCOs.
The SyD clientware, which manages the devices, is responsible for creation and management of
SyDCOs and for providing the execution engine for the SyDCO methods. SyDCOs are defined
and implemented by the vendors of the devices or by developers specializing in device
programming.
2. SyD Application Development
In this section, we present the steps involved in developing SyD applications. We employ three
distinct applications to illustrate the key step of modeling applications with various SyD-based
objects. The first is a calendar scenario, where many users store their schedules on their
distributed computing devices (e.g. PDAs). The second application is that of a package delivery
system comprised of a fleet of trucks. The final application is that of an airport, where
13
passengers can interact with each other in an ad hoc fashion. The calendar application is further
used for showing development of its server and client code.
2.1 Developing and running SyD Applications
The steps involved in developing a SyD application are as follows.
Step 1: Model the application using SyDCOs, the device-based predefined or new
objects, SyDMWOs, the available middleware objects, and SyDAppOs, new or
previously designed application objects developed by an application platform developer.
Create those SyDCOs and SyDAPPOs that are unavailable, by specifying their data and
methods.
i.
Model the new distributed application in terms of typically one but possibly
more composite objects (referred to as SyDAppOs) comprising basic objects
providing core services/methods and data sources (SyDCOs), existing SyD
middleware objects (SyDMWOs) providing specialized services, and other
existing applications and their inter-relationships.
ii.
Search and locate the required SyDCOs, SyDMWOs, and SyDAppOs by
employing the SyD Directory Service. If all the needed SyDCOs found then
skip Step (iii) below. If all the needed SyDAppOs found, then also skip Step
(iv) below.
iii.
Develop and deploy new SyDCOs by starting either with the SyD skeleton
for a SyDCO, containing predefined core SyDCO functionalities, or with a
related pre-existing SyDCO and adding the desired new functionalities by
defining and implementing methods and persistent data structure/schemas,
and launch the new SyDCO, thereby registering it, along with its QoS
attributes, with the SyD Directory Service.
iv.
Develop and deploy new SyDAppOs by employing suitable generic or
domain-specific GUI-based SyD application developer service as follows:
a.
Choose the needed SyDCOs, SyDMWOs and SyDAppOs to be part
of this SyDAppO.
b.
Define new group functionalities, by employing suitable SyD
templates classes, in terms of the individual functionalities of the
constituent SyDCOs, SyDMWOs and SyDAppOs.
c.
Launch the SyDAppO thereby registering it with the SyD Directory
Service.
Step 2: Develop high-level application server code that runs on the SyDMW by
employing the objects/methods in Step1. A separate client code, which typically is
like a browser/GUI page, is also developed, that runs on the SyD clientware. The
high-level application server code employs the objects/methods of the SyDAppOs –
typically the server code simply invokes the functionalities of a single SyDAppO in
which case the application is basically the SyDAppO itself. The client code is
developed by extending the generic interfaces for SyD applications/SyDAppOs, if
needed.
The Figure 3 below shows the details of process of building and publishing a SyD objects using
an UML use case diagram.
14
Figure 3. UML use case diagram for building and publishing SyD objects.
Users can also develop and deploy ad-hoc collaborative applications on-the-fly by leveraging
off the pre-existing providers of services/methods and data sources, SyDCOs, SyDMWOs and
SyDAppOs, by composing the SyDCOs and others in an application-specific structure by
linking them through SyD-links as follows:
i.
Search and locate the required SyDCOs and other objects by employing the SyD
Directory Service.
ii.
Develop and deploy the ad-hoc collaborative application SyDAppO by
employing a suitable domain-specific GUI-based SyD ad-hoc application
developer service as follows:
a. Choose the desired SyDCOs and other objects to be part of this adhoc application SyDAppO.
b. Create SyD-links among the SyDCOs and other objects and define
the attributes of each link thereby establishing the required constraints
and dependencies among the constituent objects (or their parts), and
verify the intended functionality and QoS attributes by a simulated
execution.
15
c. Launch the ad-hoc application SyDAppO thereby registering it with
the SyD Directory Service.
To run an application, the application is launched on a home SyDMW (each application
may have a home SyDMW providing specialized SyDMWOs), and registered with the home
and other SyDMWs. A typical user may run this application by joining the group of users
executing on the home SyDMW. Another option is that client’s SyDMW downloads the
application and launches it. The third scenario is that the client’s SyDMW runs the application
locally, but employs the home SyDMW for its special services. As can be seen, the process of
developing SyD applications is highly distributed. Data stores are accessed via SyDCOs that
encapsulate them, SyDAPPOs coordinate the collection of SyDCOs involved in the application,
and SyDMW provides the various services that enable group and communication primitives.
This highly distributed approach to application development creates flexibility and ease of
programming, allowing rapid development of applications.
2.2 Object Modeling of SyD Applications
Hand-held device's (HHD's) computational capabilities make it possible to use these devices as
both a client and server at the same time, allowing peer-to-peer computing. Small databases,
such as Oracle Lite are available for these devices as well. The calendar application exemplifies
the use of database links, while the fleet application demonstrates the use of communications.
The airport application shows the need for ad hoc group creation. Together, these applications
show the flexibility of SyD technology and how it addresses issues related to databases, creation
of peer-to-peer networks, and communication.
Calendar Application: The calendar application deals with setting up a meeting among a group
of people [25]. A typical scenario for a meeting setup is that a user enters the dates between
which he wants to setup a meeting, and the people whom he wants to call for the meeting. Out
comes a list of open slots common to all the participants, and then with a click on the desired
slot, the meeting is scheduled. Of course, there may be additional criteria, such as A and B
must attend, but one of C, D, and E may suffice. Even after finding an empty slot, the meeting
may get scheduled only tentatively, because during the delay between the enquiry for the empty
slots and the actual scheduling, the status of the participants may have changed. Someone may
also want to voluntarily change his schedule later, potentially causing the meeting to either
become tentative or canceled. Likewise, call for a higher priority meeting may bump a
previously scheduled meeting. A tentative meeting may be confirmed, at a later time, due to
some cancellations. Finally, an executive may want to delegate the task of scheduling a meeting
to a staff, and this staff would be able to call the meeting with the transferred authority of his
boss. Table 1 identifies the key SyD objects required for the calendar application including
Calendar_SyDCO and Calendar_of_Committee SyDAppO, and the specific SyDMW services
invoked by the SyDAppO.
Truck Fleet Application: Another practical implementation of the many features introduced by
SyD [46] is a truck fleet that operates an automated-package delivery system. In this system, a
user may connect through the Internet to the Web and Data Center (WDC), request delivery of a
16
package, and give information pertaining to the package, such as where the package can be
picked up, its priority, and where it should be delivered. The WDC passes this on to a depot,
which schedules a pick-up. A truck will arrive according to the schedule and take the package
to its next stop. The trucks, depots and WDC form a heterogeneous network with different
types of communications links between them. Each entity has its own database of varying
capacity. A truck will hold information about the packages, such as the package ID, its current
location, and where it needs to go. A depot keeps similar, but more involved data, such as
which truck has the package, the status of the truck (location, speed, heading), and where the
package ultimately needs to be delivered.
Figure 4. The Fleet application’s hierarchy
We present the architecture of the fleet system as a hierarchy (Figure 4). The user
connects to the Web and Data Center (WDC), which provides the user interface and serves as a
repository for retired records. That is, once a package has been delivered, the trucking company
will want to keep information about that package for a time, so the WDC acts as a backend
database. The WDC connects to depots, and passes along information, such as the record for a
package. Depots have wireless connections to their respective trucks, and the trucks can
communicate with each other directly through their wireless devices. There is no reason why
the trucks cannot communicate directly with the WDC if needed, though this is typically
unnecessary. Table 1 contains the SyD objects for the fleet application.
Airport Applications: In this situation, a person will join a network for a short time, use
applications that he finds of interest, then disconnect from the network. The applications do not
need to be stored on a central server. Instead, the person may launch the application, or
possibly download it from another person. The devices may be different in size and capacity,
but they will function as peers. A person could enter the airport with electronic coupons for th
17
SyDAppOs
Calendar
Fleet
Airport
Calendar_of_Committee (A, B,
C ,…):
{
Group_of_Calendar_
SyDCOs (A,B,C,..);
Fleet_SyDAPPO(Trucks,
Depots):
{ Delivery_Schedule_Table on
Truck; Local_Schedule on
Depot;
Update_Schedule_Table on
WDC;
Truck_Status_Table on Depot;
Traffic_Information_Table on
Depot; etc.
Airport_SyDAPPO(Tickets,
Coupons):
{
Goods (e.g. Tickets);
Items_Wanted; Group_List;
Group_Members; etc.
Set_Up_Meeting();
Cancel_Meeting();
Set_Up_Tentative_Meeting();
Find_Earliest_Meeting_Time();
Find_Latest_Meeting_Time();
Change_To_Next_Available ();
Change_Meeting_Time(time);
}
SyDMW/
SyDMWOs
Intersect(); Min();
SyD_Synchronize();
SyD_Create_Link();
SyD_Delete_Link();
SyD_ID(); SyD_PassWord()
SyDCOs
Calendar_SyDCO:
{
Calendar_Table;
Create_Calendar();
Find_Earliest_Time();
Setup_Meeting();
Cancel_meeting();
Setup_Link();
Cancel_Link();
Setup_Tentative_Meeting();
Show_Schedule();
Schedule_Update();
Deliver(); Delay_Deliver();
Cannot_Deliver(); Accident();
Slow_Traffic();
Broadcast_Trucks();
Multicast_Trucks();
REC_On_Truck();
REC_On_Depot(); etc.}
SyD_Synchronization();
SyD_Query();
SyD_REC();
Publish_Methods(); etc.
Truck_SyDCO:
{ MyDepot; Packages;
Location;
Estimated_Time_To_
Delivery();
Have_Package();
}
Search();
Broadcast_Everyone();
Multicast_Chat_Partners();
REC_On_Other();
Trigger_Handler();
Group_Check_In();
Group_Check_Out(); etc.
}
SyD_Query(); SyD_Select()
and SyD_Join();
SyD_REC();
SyD_Create_Link();
SyD_Delete_Link();
SyD_Link_Structure();
Find();
Ticket_SyDCO:
{ MyTickets;
MyDesiredTickets;
Show_Goods();
Show_Wanted();
Exchange_Ticket();
}
Depot_SyDCO:
{ My_trucks[];
Make_schedule();
Package_delivered();
Package_status();
}
}
WDC_SyDCO:
{ My_depots[];
New_package();
}
Table 1. SyD Modeling of the three applications
businesses inside, start or join an application for trading coupons, exchange a few of them, then
leave the application. It is even possible for the user to start an application, and then leave it, with
the application continuing on in the devices of others. People can join a network for information
18
(flight arrivals, restroom locations, etc). Airport patrons may wish to join groups not necessarily
hosted by the airport, such as a chat room for people traveling on a particular flight. Table 1
contains its SyD objects for this environment.
Table 1 does not include device SyDCOs, and methods common to all applications. Each
device would need its own SyDCO, and would come with data such as Device_profile, Proxy, and
methods such as Display(), Read(), Write(), Set_up_Proxy(), etc. Methods common to all
applications include Send(), Receive(), Broadcast(), Multicast(), etc., which would be hosted in the
SyD middleware, and have been elaborated in Section 3.
Mall Application: The software architecture and implementation details for the shopping mall and
the airport applications share many common components, thus, they are grouped together here.
Both applications feature anonymity, the need for an ad-hoc network, and both applications have
bartering in the form of trading goods: airline tickets, frequent flier miles, coupons, special deals,
etc. For the shopping mall, we envision an environment where shoppers with SyD enabled devices
can search for goods and services among the stores. The user may enter a key word such as
"jewelry" into their device's interface. Their device connects to the nearest mall's computer, and
requests a search. This mall's computer passes on the request to its nearest neighbors, other SyD
enabled devices from participating stores. When matches are found, relevant data such as store
locations and walking directions will be sent back to the user. Optionally, stores may inform the
user's computers of merchandise sales, or even upload an application to the user's device. Such an
application could be an interactive form allowing the user to decide if the store is worth a visit, if
the items fall within the user's price range, and if a salesman should be alerted to meet the user with
a display case of the item he is interested in purchasing.
The airport scenario has users looking to pass the time before their flight, as well as people
new to the area looking for food, lodging, or transportation accommodations. People there may also
want to barter: a last minute traveler may look for a good deal on a flight, a person with tickets in
hand may want to eat at a certain restaurant that would give frequent flier miles, while someone else
may want to trade his aisle seat for one next to a window.
The software architecture must therefore support finding of groups to join (e.g. a seat
bartering discussion group), joining the group, searching the group (e.g. for users on the same
flight), sending chat-style messages to the group/individual, updating the databases of the airline
(e.g. two people agree to swap tickets), leaving a group, and searching for keywords. For the
shopping mall, the finding of groups could be applications other users have set up (e.g. coupon
exchange) like above, or they could be groups formed by the stores themselves, allowing potential
customers to search their inventory. The other capabilities of joining, searching, etc. must be
supported. Help can be offered in the form of a frequently asked questions document, or searched
by question.
2.3 Developing Server and Client Application Code
In this section, we illustrate the second step of SyD application development, the high-level
controlcode development. Consider the calendar application where individuals are maintaining
their personal schedule information in their hand held devices and are making this information
available to the application for read as well as write purposes. A sample GUI for a part of the
calendar client is shown in Figure 5. In this GUI, the client is requesting a meeting setup among
19
three individuals: A, B and C at the earliest time on a particular date. Figure 5 also shows the
resulting link structure established among the databases after meeting is setup [25].
Figure 3. Client GUI Interface and SyD Links for Calendar Application
The Server code for this client request may look as follows:
Calendar_of_A+B+C = new Calendar_of_Committee (A,B,C);
TimeSlot = Calendar_of_A+B+C.Find_Earliest_Meeting_Time(t1,t2));
If (Calendar_of_A+B+C.Set_Up_Meeting(TimeSlot) = success)
Then confirm meeting to the client
Here, Calendar_of_Committee is a SyDAPPO object that is already developed. This
method most likely will invoke the SyD_Create_Group(A,B,C)SyDMW service.
One of the SyDCO methods provided by all SyDCOs in the calendar application may be:
Calendar_A.find_all_free_times(t1,t2):
Execute SQL Query on the Calendar_A table and return free
time slots in between t1 and t2, assuming it is relational DB.
Else, data format specific code is generated.
The SyDAppO method body for Find_Earliest_Meeting_Time is coded as follows:
Min(SyD_Intersect(SyD_Broadcast (Calendar_of_A+B+C,
execute_method(Calendar_X,find_all_free_times,t1,t2)))
where Broadcast, Intersect and Min are built-in SyDMW services. Thus, application programming
is carried out at a very high-level, with the accompanying ease and reliability.
20
3. An Implementation Framework for SyD Methodology
This section describes the SyD middleware and clientware class hierarchy. It also describes details of a
possible implementation of a Calendar System using this API framework. Also described here is the way
SyD can let its users build ad-hoc applications over a collection of SyDCOs.
3.1 SyD Packages
syd : A package that declares methods and data members for the SyD objects, SyDCOs, SyDPOs (SyD
proxy objects), the ad-hoc objects and the SyD event on the ad-hoc objects
syd.services : A package that provides the services component for the SyD middleware. This also includes
the part of the middleware that needs to go onto the client side.
syd.event : This package defines the events that could take place on the ad-hoc objects and the the action
listeners for them. This package is similar to the java.awt.event package.
syd.device : This package provides a wrapper for all the device specific libraries and drivers that SyD might
use.
syd.gdb : A package that provides methods for group transactions at the database level.
syd.protocol : A package with the protocol details.
We explain building of SyD applications using the syd, syd.services, syd.event and syd.devices packages.
The API of these packages is also explained briefly.
Package syd
Package syd
syd.SyD{
Vector <SyDCOs, SyDPOs>;
Methods
Void add (SyDCO c1);
Void add (SyDPO p1);
Void delete (SyDCO c1);
Void delete (SyDPO p1);
Void createLink (SyDCO c1, SyDCO c2);
Void createLink (SydCO c1, vector<SyDCOs);
Void createLink (SydCO c1, SyDCO c2, syd.SyDEvent e);
}
syd.SyDCO{
String Name;
IPAddress IPAddress;
Other essential data elements and methods for the SyDCO;
}
syd.SyDPO{
String Name;
IPAddress IPAddress;
Other essential data elements and methods for the SyDPO;
21
}
Package syd contd…
syd.SydEvent{
Constructor
SyDEvent (SyDCO c1, SyDCO c2);
Captures all the events that could take place between two SyD objects. Some of
them could be
c1.equals (c2);
c1.property.equals (c2.property);
}
syd.AdhocObject{
SyDCO headOfLink;
Vector <SyDCOs >;
SyDEvent e;
Methods and Constructors
Void addSyDActionListner ( );
AdhocObject (SyDCO head, SyDCO c1);
AdhocObject (SyDCO head, vector <SyDCOs);
AdhocObject (SyDCO head, SyDCO c1, SyDEvent e);
}
The syd.SyDEvent could be extended by the application object SyDAPPO, for handling events specific to
the application. This is described in the Application Development sub-section.
Package syd.services
This has five sub packages named
 syd.services.dataservice
 syd.services.directoryservice
 syd.services.qosservice and
 syd.services.commservice
 syd.services.eventservice,
each taking care of the specified functionality.
Each service is again subdivided into three packages,
 client package
 proxy package and
 server package.
Only the client packages are deployed onto the client devices, i.e., the device hosting a SyDCO. Similarly,
the proxy packages are deployed only onto the device hosting a SyDCO proxy. Together, these two packages
22
constitute the SyD clientware services. The server packages are deployed onto the device(s) hosting the
SyDMW, the SyD middleware, thus serving the SyD groups. These servers can be bootstrapped either from
the application (i.e the SyDAppO) or they can be started manually prior to starting the SyDAppO. This split
would save the RAM on the client PDA.
Package syd.services
Package syd.services.directoryservice
Package syd.services.directoryservice.disclient
Package syd.services.directoryservice.disproxy
Package syd.services.directoryservice.disserver
Package syd.services.dataservice
Package syd.services.directoryservice.dasclient
Package syd.services.directoryservice.dasproxy
Package syd.services.directoryservice.dasserver
Package syd.services.qosservice
Package syd.services.directoryservice.qosclient
Package syd.services.directoryservice.qosproxy
Package syd.services.directoryservice.qossserver
Package syd.services.commservice
Package syd.services.directoryservice.commclient
Package syd.services.directoryservice.commproxy
Package syd.services.directoryservice.commserver
Package syd.services.eventservice
Package syd.services.directoryservice.esclient
Package syd.services.directoryservice.esproxy
Package syd.services.directoryservice.esserver
23
The syd.event package:
The event package consists of the classes required for the ad hoc object to identify the changes on itself. The
ActionListener interface has one method named actionPerformed. This method is invoked when the
SyDEvent takes place on the ad hoc object.
Package syd.event
Interface syd.event.ActionListner{
Methods
actionPerformed(SyDEvent e);
}
All other Event classes and the interfaces for other possible events
3.2 Application Development
In this section, based on the API specified, the process of developing the SyD applications is explained. SyD
application development consists of four primary steps
1.
2.
3.
4.
Modeling using the SyDCOs
Developing the SyDAPPO
Developing the high-level application server
Providing the client side GUI.
These steps are explained for a Calendar System.
Modeling the SydCOs
In this case the SyDCO is the Calendar. The Calendar_SyDCO is inherited from the syd.SyDCO object.
Only two methods setupMeeting( ) and cancelMeeting( ) are demonstrated for the Calendar System.
Calendar_SyDCO extends syd.SyDCO{
calendarTable;
Methods
setupMeeting( );
cancelMeeting( );
}
The calendarTable consists of the users calendar. The methods setupMeeting ( ) and cancelMeeting ( )
handle the device/driver specific calls.
24
Modeling the SyDAPPOs
SydAPPO application object consists of group of SyDCOs. This inherits from the syd.SyD class.
Calendar_SyDAPPO extends syd.SyD {
Vector calendarGroup;
Methods
Void add(Calendar_SyDCO c1 );
Void delete( Calendar_SyDCO c2);
Void createLink (Calendar_SyDCO c1, Calendar_SyDCO c2);
Void createLink (Calendar_SyDCO c1, vector <calendars>);
Void createLink (Calendar_SyDCO c1, Calendar_SyDCO c2, CalendarEvent e;
Group Methods
Void setupGroupMeeting( );
Void cancelGroupMeeting( );
}
The overwritten add( ) and delete( ) methods add and delete Calndar_SyDCOs to the calendarGroup. The
createLink( ) methods also use the Calendar_SyDCO objects to form the links. Calndar_Event represents an
event specific to the Calendar system.
Calendar_Event extends syd.SyDEvent {
Calendar_Event( Calendar_SyDCO c1, Calendar_SyDCO c2);
}
Event service propagates a calendar event when two Calendar_SyDCOs satisfy the condition for the
specified event. The createLink ( ) method can be implemented in the following manner for two SyDCOs
and the specific CalendarEvent
Void createLink (Calendar_SyDCO c1, Calendar_SyDCO c2, CalendarEvent e) {
syd.eventService.register(e);
AdhocObject o = new AdhocObject (c1, c2);
o.addSyDActionListener(new syd.event.ActionListener( ) {
void actionPerformed(e) {
do the desired functionality;
}
}
}
25
Group methods like setupGroupMeeting ( ) and cancelGroupMeeting ( ) would have to be dispatched to the
clients in the form of setupMeeting ( ) and cancelMeeting ( ). Since the SydAPPO is inherited from the
syd.SyD, these methods can be implemented as follows:
void setupMeeting( ) {
for each Calendar_SyDCO in calendarGroup{
setupMeeting( );
}
}
void cancelMeeting( ) {
for each Calendar_SyDCO in calendarGroup{
cancelMeeting( );
}
}
Developing the high-level application server
The application server properly bootstraps all the services and registers the objects, the events, the SyDCOs
and the SyDPOs etc. This could be done as follows
Calendar_Server_App {
syd.services.directoryservice.disserver.DiServer.start( );
syd.services.dataservice.dasserver.DaServer.start( );
syd.services.qosservice.qosserver.QosServer.start( );
syd.services.commservice.commserver.CommServer.start( );
syd.services.eventservice.esserver.EventServer.start( );
}
Providing the client side GUI
Client-side GUI provides with the user an ability to select the group of the Calendar_SyDCOs that the user
wants to form a group with. This GUI also transmits the user SyDCO to the server through the middleware
and registers it with the server services.
Calendar_GUI_Client_App {
Calendar_SyDCO c = new Calendar_SyDCO
RegisterWithAllServices (c);
DisplayAllGroupMembers ( );
App1 = Create new Calendar_Syd_APPO( );
Execute methods on App1;
}
( );
26
3.3 Execution of the Application
In this section the execution of the calendar application for a group of calendars is explained. The following
steps need to be performed:
1. Start the server application.
2. Start the Calendar GUI application on the client. This would add the Calendar_SyDCO to the
directory services. Then it will display all the available Calendar_SyDCOs registered with the
directory services.
3. The user would then be given a choice to select a chosen group of Calendar_SyDCOs. This would
create a SyDAPPO object for the user. The user would be able to create ad hoc objects also by
creating links between the chosen group of Calendar_SyDCOs. This would also register the events
with the event services.
4. Event services would notify all the ActionListener’s waiting for an event e, thus performing the
necessary action whenever the event takes place.
For example, an event could be propagated whenever the Calendar is updated. The updateEvent could be
registered with the event services. Whenever there is an update on this SyDCO object, the SyDAPPO will be
notified of this through the ActionListener. If we have defined a link between two SyDCOs in the
SyDAPPO, this link is executed and the desired action is taken place. This can be demonstrated as follows
Void createLink (Calendar_SyDCO c1, Calendar_SyDCO c2, CalendarEvent e){
syd.eventService.register(e);
AdhocObject o = new AdhocObject (c1, c2);
o.addSyDActionListener(new syd.event.ActionListener( ) {
void actionPerformed(e) {
do the desired functionality;
}
}
}
SyD provides support for both Client/Server as well as the peer-to-peer modes of operation for the devices.
The device can act in a peer-to-peer fashion with other devices as long as it possesses the requirements for
the device to be hosting a SyDCO. On the other hand, if the device does not satisfy all the requirements, the
device can be a client to a Proxy that is acting on behalf of the device. SyD also provides transparent
transition between these two models.
For example, if a user of an iPaq wants to create an ad-hoc SyDAppO comprised of two SyDAppOs, namely
a Calendar_SyDAppO and a Ticket_SyDAppO. Assume, here the Calendar_SyDAppO is capable of setting
up meetings with all other calendars in the group using Calendar_SyDCOs present on the devices in a peerto-peer fashion whereas the Ticket_SyDCO needs a large local database that is a constraint not satisfied on
the iPaq. In that case the user can host his the Ticket_SyDCO on a Proxy (which is nothing but the
Ticket_SyDPO) and interact with it in a Client/Server mode.
Method for Ad-hoc Applications:
For example, a user wants to create an ad-hoc application (object composition) consisting of his
Ticket_SyDCO T and his Calendar_SyDCO C, linking them in a way such that they would schedule
themselves with out time conflicts. This could be realized in the SyD by following the steps below
27
1. The user first selects the SyDCOs that he wants to link using a browsing facility provided by the
directory service.
2. The user then creates a link between them by selecting the constraints on the SyDCO’s he has
chosen
3. Then the user specifies the action to be taken once the constraint is satisfied
4. The user registers this ad-hoc object with the directory services
5. At the same time the constraints are registered with the event services through the event listeners
6. Event manager listens for any changes in the object
7. If the change on the object corresponds to the constraint on the object, then the event manager
notifies all the event listeners waiting for this particular constraint to be satisfied
8. Event listener would take care of updating the schedules with out conflicting times
A typical code snippet might look like this
Void createLink (Calendar_SyDCO C, Ticket_SyDCO T, CalendarEvent e){
AdhocObject o = new AdhocObject (C, T);
syd.directoryService.register(o);
syd.eventService.register(o,e);
o.addSyDActionListener(new syd.event.ActionListener( ) {
void actionPerformed(e) {
do the desired scheduling with out conflict;
}
}
}
4. SyD Infrastructure
In this section, we specify the core services available from the SyD middleware and clientware. We
then provide insights into the implementation of the middleware and clientware.
4.1 SyD Middleware and Clientware Interfaces
There are three classes of core middleware services: directory and group management services,
group communication and QoS services, and data manipulation services. The clientware services
support SyDCO management and execution.
4.1.1 Directory and Ad Hoc Group Services
A SyD directory service that enables locating SyD objects, devices, groups, and active applications
(in the vicinity, on a local wireless or wired network, or on the internet) is integral in supporting the
SyD groups. The objects in a group are typically SyDCOs, but are not limited to them. In the
discussions below, we refer to SyD devices for clarity, but, for all practical purpose, a SyD-enabled
device, represented by its SyDCW, is assumed to have a default SyDCO exporting the basic device
capabilities. The following are the primitives for group management.
28
Directory Services: A SyD user finds a list of all SyD objects/devices/groups/applications in the
vicinity, on the local network, in a group, etc. It also supports finding the current location of a
specific SyD device.
o Find a specific device (Location Management)
 SyD_Location = SyD_Locate (SyD_Device_Id)
o SyD_Publish_SyDCO (SyDCO_name, SyDCO_interface) publishes a SyDCO with all
its data and methods and access privileges specified in SyDCO_interface with the
SyDMW; Unpublish_SyDCO().
o SyD_SyDCO_List = SyD_Find_SyDCOs (Where)
Where = {distance, local_net, SyD_Group_ID, …) - finds all SyDCOs.
o SyD_Group_List = SyD_Find_Groups (Where); Find all SyD groups.
o Find all SyD applications: SyD_Application_List = SyD_Find_Application (Where)
o Register_SyDCW() attaches a SyD clientware (SyDCW) to a SyDMW
o Register_Proxy_of SyDCW(SyDCW_Id, Proxy_Location)
Group Management: One of the key features of SyD is its ability to define a SyD group object (a
SyDMWO), which is a logical group of SyD objects. A SyD group may be ad hoc, formed
dynamically by the users to run SyD applications, maintained efficiently by the SyDMW, and
disbanded by the users.
o SyD_Group_id = SyD_Create_Group (SyD_object_id1, SyD_object_id2, …)
o SyD_Group_id = SyD_Merge_Group (SyD_Group_Id1, SyD_Group_Id2)
o SyD_Join_Application (SyD_Group_Id, SyD_Application)
o SyD_Temp_Disconnect_From_Application (SyD_Group_Id, SyD_Application_Id)
o SyD_Disconnect_From_Application (SyD_Group_Id, SyD_Application_Id)
Proxy Execution and Ad Hoc Applications:
o Proxy Execution: Executes a function on another SyDMW in proxy.
 SyD_Proxy_Execute (SyDMW_Service, SyDMW_Id)
o Ad hoc application: Download/Upload an application .
 SyD_Download_Application(SyD_Application, SyDMW_Id)
 SyD_Upload_Application(SyD_Application, SyDMW_Id)
Group Configuration:
o Hand-off: Hand off a neighboring device connected through a device to another member
in a group: SyD_Hand_Off (SyD_Device_Id, SyD_Group_Id)
o Reconfigure a group’s topology for efficiency
 SyD_Reconfigure_Group (SyD_Group_Id)
Coordination Links (SyD Links): We introduce a new primitive SyDMW object, called
coordination or SyD link [25], which may be employed to create groups of objects, execute global
atomic updates, and coordinate ad hoc network topology and proxies. SyD links allow creation and
enforcement of interdependencies, constraints and automatic updates among groups of SyD entities.
An entity may be an object or its component. Two types of coordination links are defined: (i)
subscription links are useful for automatic updates and synchronization; (ii) negotiation links, with
specified logical constraints, enforce interdependencies. A link is specified by its type
(subscription/negotiation), references to one or more entities, triggers associated with each
29
reference (event-condition-action, ECA, rules), a priority and status (committed/tentative). Let an
entity A be linked to entities B and C, which may in turn be linked to other entities. If the SyD link
is a subscription link, then a change in A will trigger attempted changes in B and C; if it is a
negotiation link, say with and logic, then A can be changed only if both B and C can be
successfully changed.
o SyD_Create_Link (Link_Type,Link_Constraint, Source, Destinations, Triggers,
Priority) and SyD_Delete_Link(): Creates/deletes a negotiation or a subscription link
from entity Source to the group of entities in set Destinations with underlying ECA
triggers and Priority. If a negotiation link type, then its kind is specified by
Link_Constraint (and, or, xor, atleast K, exactly K, etc.). Likewise, SyD_Destroy_Link
(), and SyD_Change_Link() to change link’s parameters.
o SyD_Invoke_Link() invokes the link and enforces its constraints
o SyD_Lock() /SyD_Unlock() atomically locks (unlocks) a group of SyD entities linked in
a hierarchy, or chain, and SyD_Synchronize() synchronizes the entities linked in a
hierarchy or a chain.
Section 6 contains details on SyD coordination links specification, sematics and execution.
4.1.2 SyDMW Communication and QoS Services
It is envisioned that the SyD will comprise a collection of devices that may or may not be
geographically distributed based on the application. An added dimensionality considered is the
mobility of the devices. By virtue of the users and devices in SyD being potentially mobile, the
group membership of a SyD object can be highly time variant both because of transient
disconnections of users from the Internet and because of conscious turning off a device by the
concerned user. Finally, SyD's design also accommodates for objects to exist in highly limited
environments that are characterized by low bandwidths, resource-constrained devices, etc.
SyD Communication Primitives
The SyD middleware plays two critical roles in supporting network independent operation of the
SyD. First, once the SyD members are identified (through the group management explained
earlier), the middleware creates and maintains a virtual backbone that serves as a communication
infrastructure between the objects of the SyD. Once the virtual infrastructure is established by SyD,
any communication between members of an object use the underlying virtual infrastructure for
communication. The goal of the SyD virtual machine is to mask most of the communication
complexity from the SyD application developer. To this end, SyD provides a set of primitives that
the application developer can make use of when implementing a specific SyD class or application.
While we do not present details about the virtual infrastructure in the paper because of lack of
space, we present below the set of primitives and use the calendar application example to show how
the primitives might be used by the developer:
 Unicast: Communication between one sender and one receiver. In the calendar application
the unicast primitive can be used for finding out the schedule of a particular member of the
SyD object: getSchedule(user_id2) => SyD_unicast(user_id1,user_id2,getSchedule)
30




Multicast: Communication between one sender and multiple receivers. A possible use for
this primitive in the calendar application is, say, for all calendars of a particular subset of the
members of the group to be updated with a RSVP request:
reqRSVP(user_id2,..,user_idk) => SyD_multicast(user_id1,user_id2,..user_idk,reqRSVP)
Broadcast: This is a special case of the multicast primitive wherein all members of the SyD
object except the sender receive the message. A key difference is that the sender does not
need to know the membership of the object to use this primitive. An example usage is a
new member advertising to the rest of the group:
newMemberNotify() => SyD_broadcast(all_users, newMemberNotify)
Anycast: This is a primitive wherein the message sent by a receiver will be delivered to atleast one of the receivers that belong to the targeted anycast group. For example, in the
calendar application, if a member knows that the answer to his query will be available with
any one of a set of other members, using the anycast primitive will be an effective way of
gathering information:
getPhoneNo(user_id2, ..,user_idk, GCATT) =>
SyD_anycast(user_id1, user_id2, .., user_idk, getPhoneNo, GCATT)
Reverse Groupcast: This primitive is the same as that of multicast except that the data flow
is in the opposite direction. This primitive can be used in tandem with the multicast
primitive. For example, in the calendar application, if a member M desires to know the
earliest time at which each of the other members can make themselves free on a particular
date, the replies from each member need not reach the M. The information being sent by
the other members can be collated, processed, and appropriately filtered to only let the
member M know when the collective earliest time is:
At user M: getEarliestFreeTime(user_id2,user_id3,..,user_idk) =>
SyD_multicast(user_id1, user_id2, .., user_idk, getEarliestFreeTime)
At each other member i: SyD_reversegroupcast(user_idi, user_id1, earliest_time_i)
SyD Quality of Service Support for Communication Primitives
While SyD supports the above communication primitives, it also provides the application developer
several communication specific quality of service (QoS) parameters that can be associated with the
communication primitives to support a certain degree of QoS (akin to SLA) to the application user.
Some of these parameters include:
- Reliability: Whether the communication is reliable, un-reliable, or partially reliable.
- Quorum: Whether a certain number of members are required for the communication to be
successful. A variation is requiring a particular subset of members for success.
- Delay: Whether there is a specific deadline to be met for the communication.
- Cost: Whether any cost needs to be minimized when performing the communication (say total
latency, average latency per user, amount of bandwidth consumed, etc.)
- Priorities: If no absolute cost needs to be minimized or QoS requirement to be met, priority
resolves how the communication is treated when compared to the other ongoing
communications of that particular SyD object and other SyD objects.
4.1.3 SyD Middleware Data Services
31
SyD Middleware provides various data services that operate on group objects created within
applications. Some of the services are:



Aggregation of results of query methods on SyDCOs. As an example of this service,
consider the SyDAPP object, which is created out of the SyDCOs participating in the calendar
application. Assume that each of the SyDCOs in this group object supports the
Find_Available_Times method which returns a set of free times in the individual’s calendar. To
find the earliest available time for a meeting, the SyD application can first invoke the
SyD_Broadcast primitive of the SyDMW to execute this method on all SyDCOs in the group.
Then, the SyD application can use the SyD_Intersect followed by MIN data services to find the
earliest available time for the group to meet.
Execution of global SQL query (query with references to several relational SyDCOs) on a
group of relational SyDCOs. Assuming a SyDAPP object is created from a collection of
relational SyDCOs – SyDCOs encapsulating relational databases, the SyD Middleware provides
the capability of executing a global query against such a SyDAPP object. The results of such a
query are available to the application in the form of a cursor similar to SQL database cursors.
Enforcement of global constraints on a group of SyDCOs. Global conditions that must be
met by collection of SyDCOs in a group object are also enforced at the SyD Middleware. An
example of global constraint in the Calendar application is: The number of participants in a
particular meeting must be at least five. SyD Middleware provides the ability to specify such
constraints and the enforcement of such constraints is handled by the middleware.
Section 5 contains details on global query and constraint specifications.
4.1.4 SyD Clientware Interface
SyDMW relies on certain core services that SyDCW provides. The main clientware services
include managing SyDCOs and their execution locally or through proxy and, for intermittently
connected SyDCW, managing their persistence through proxy.
SyDCO Management:
- Execute_method (SyDCO_name, SyDCO_method, method_parameters): The named SyDCO’s
method is executed by the SyDCW.
- Create_SyDCO (SyDCO_name, SyDCO_Interface, SyDCO_Body); Delete_SyDCO().
- List_SyDCOs(); Find_SyDCO();
- Proxy_Execute(SyDCW_Service, SyD_Device): For execution of heavy-duty services, such as
SyDCO execution.
Proxy Management: This is useful for intermittently connected SyDCWs.
- Start_proxy(SyD_device), Stop_Proxy(): SyDCW initiates a voluntary setup of its proxy. After
its registration with the SyDMW, SyDMW can interact with its proxy.
- Sync_With_Proxy() synchronizes device data with its proxy periodically, and SyDCW may
choose to un-register its proxy once connected.
32
4.2 Insights into Implementation of SyD
4.2.1 Implementation of SyD Middleware and Its Services
While Section 4.1 outlines the interfaces exported by the SyD middleware, in this section we
provide some insights into the implementation of the SyD middleware. Note that SyD does not
stipulate a particular implementation model for the middleware. In contrast, SyD provides a
framework within which a range of implementations can be achieved depending upon the
constraints and requirements of a particular target domain.
Support for both the client/server mode of operation, and the peer-to-peer mode of operation
are possible. In the peer-to-peer architecture, the middleware is hosted in a distributed fashion by
the devices that form the SyD. Thus, each device will have a portion of the middleware running on
it. The clientware on the device then can talk directly to the middleware on the device. Since the
middleware is not a distributed entity, the middleware components on each device are more
intelligent and coordinate with one another in ensuring the correct operation of the middleware.
Although the middleware is distributed, each individual middleware entity is self-contained in the
sense that a device will be able to form a SyD group by itself. As more members join the group, the
tasks of the middleware layer (directory service, maintenance of virtual infrastructure) is delegated
among the group members such that an individual device is not overloaded. Thus, a methodology
for an adaptive network model by providing support for hosting of the middleware in a pure peerto-peer networked environment where all end-systems cooperate to host the middleware in a
collaborative fashion, as well as for supporting the traditional client/server mode of operation for
SyD clients and the SyD middleware (with the middleware hosted by a server) is possible as
follows:
i.
If a dedicated server capable of hosting the middleware exists, SyD hosts the
middleware on the server, and all SyD clients communicate with the server.
ii.
In the absence of a dedicated server, all end-systems part of SyD cooperatively host
the middleware that executes in its distributed mode.
Simple Centralized Model: At one end of the spectrum of implementation models possible is the
conventional client server model. In this model, the middleware can be hosted entirely on a
powerful server. All devices that are part of the SyD will then act as a client to the server hosting
the middleware. Note that this mode of implementation still fits in with the logical model of SyD
where the clientware on the SyD device communicates with the middleware. The Figure 6 below
depicts the centralized model.
33
Figure 6. UML deployment diagram for a SyD client-server architecture. Clients are heterogeneous devices,
including PCs, PDAs, etc. Communication could be on Internet via wireless and wired connections.
Such a client-server model implementation of the middleware will be of use for large scale
and popular applications. The server hosting the middleware can be visualized as a SyD portal that
devices then can hook up to. The assumption is that devices have consistent connectivity to the
server. If the server were a regular Internet server, this model would require that all devices
belonging to the SyD have connectivity to the backbone Internet.
An example application domain where this model might be used is the airport application
discussed in Section 2. Specifically, since the airport authorities are supporting a certain SyD
application (e.g. walking directions or ticket bartering), it would be a feasible solution for a SyD
middleware server to be hosted in the airport. The clientware on the SyD devices would then
communicate with the middleware on the server. This would also relieve the devices from having
to expend precious resources (CPU, memory, etc.).
The advantages of this model are: (i) the middleware logic can be simple by virtue of being
centralized, (ii) the devices do not have to use up their scarce resources in hosting a portion of the
middleware, (iii) the SyD operation becomes less vulnerable to device disconnects, (iv) it is a
model that fits in with the current client-server model predominant in the Internet, However, the
disadvantages include: (i) devices need to be connected to the backbone Internet; this might
prevent say a group of devices from forming a SyD group if they are not connected to the Internet
or if they have not subscribed to a central middleware server, and (ii) for reasons of security and
privacy, devices might not want to use a centralized middleware server that can be cognizant of all
the operations of the SyD group. While this can be overcome by appropriate security measures, this
will add additional overhead to the operation of the SyD.
Peer-to-Peer Model: At the other end of the spectrum is a pure peer-to-peer model. In this model,
the middleware is hosted in a distributed fashion by the devices that form the SyD. Thus, each
device will have a portion of the middleware running on it. The clientware on the device then can
talk directly to the middleware on the device. Since the middleware is not a distributed entity, the
middleware components on each device should be more intelligent and coordinate with one another
in ensuring the correct operation of the middleware. Although the middleware is distributed, each
34
individual middleware entity is self-contained in the sense that a device will be able to form a SyD
group by itself. As more members join the group, the tasks of the middleware layer (directory
service, maintenance of virtual infrastructure) is delegated among the group members such that an
individual device is not overloaded. Figure 7 below depicts the peer-to-peer model.
Figure 7. UML deployment diagram for a SyD peer-to-peer achitecture. Clients include both middleware and
clientware for peer-to-peer communication via Internet or other network.
Such a peer-to-peer model would be applicable in domains where the applications are not
heavyweight, the users might not have connectivity with the Internet backbone at all times, and/or
the need for security and privacy precludes maintaining a centralized middleware server as an
option. An example application where this model might be used is the calendar application
discussed in Section 3. Specifically, each user can choose to belong to one or more SyD calendar
objects, and the middleware appropriately maintain the information (atleast in part) required for the
virtual infrastructure (on a per-SyD object basis) and directory services.
The advantages of this model are as follows. (i) The devices need not have any connectivity
to the backbone Internet, (ii) ad-hoc groups can be formed on the fly without the need for a
centralized server, (iii) privacy is not an issue as the devices themselves host the middleware, and
(iv) the single source of bottleneck possible in the centralized server model is eliminated. However,
achieving these advantages comes at a certain complexity cost and the following disadvantages. (i)
The devices that are potentially resource limited will have to bear the additional burden of
supporting the middleware, (ii) the disconnection of a device will result in the SyD operation being
interrupted (although schemes can be devised to recover from such interruptions, this is still a
drawback), and (iii) the directory service to be maintained by the middleware will have to be
distributed. This is not a critical problem when the devices are geographically co-located (say
inside the same local area network). However, since the SyD framework does not preclude devices
geographically distributed from forming a SyD object, an important issue is how devices will
access the directory service when it is distributed over the Internet (in some arbitrary fashion
depending upon the membership at that point).
A solution to the last problem is a hybrid solution where a centralized server is maintained
for directory services but the middleware is distributed among the devices. Note that this still does
35
not take away the ability of devices disconnected from the Internet to form a SyD as such devices
will have to be co-located anyway.
Commercial Technologies: We now consider capabilities of some of the existing middleware
technologies, which may be leveraged to implement the SyD middleware. Currently, the database
interactivity and collaboration can be achieved by a mixture of existing technologies. They include
network programming, database access using JDBC in Java, XML, web programming with servlets,
and some newer coomunication protocols such as SOAP (Simple Object Access Protocol) or the
upcoming Microsoft .net/HailStorm architecture. Automating many common networkprogramming tasks such as object location, registration, activation and operation dispatching can be
accomplished via the Common Object Request Broker Architecture (CORBA) [6,14,43]. CORBA
is mainly for client-server model, and usually involves one server or a few servers. Enterprise Java
Beans (EJB) [39,41,24] aims at leveraging the transactional database support of enterprise
networks. EJB creates enterprise-backbone logic by hooking together legacy applications wrapped
in Java. EJB is not about dynamic, runtime, discovery, and reconfiguration of components.
Distributed COM (DCOM) [35] is another architecture which is a middleware designed by
Microsoft that allows COM components to transparently communicate over the network.
Our prototyping effort has presently involved the SOAP protocol and we expect to make
extensive use of XML for data interchange. However, the SyD implementation is not be tied to any
particular commercial technology mentioned above.
4.2.2 Implementation of SyD Clientware and Its Services
SyD clientware encapsulated the device, and maintains and executes SyDCOs. It is critical in
presenting uniform and persistent object view to the SyD middleware. Persistence may be achieved
through efficient management of proxies. We highlight the key issues associated with SyDCW and
provide insights into their implementation.
Implementation of a SyD application process starts with the creation of the SyDCO. This
initial operation may start a new SyDCO or select predefined SyDCOs. The execution stage is
mainly designed to execute the methods associated with each SyDCO. The execution process
allows SyDCOs to get the data of interest by accessing it via the services offered by the SyDMW,
with a uniform interface to all devices that are sources of data. Actual execution may occur on the
local client or remotely depending on how the SyDCW is implemented and what proxies have been
designated. The local execution can be achieved using a local Virtual Machine service while the
remote execution process is carried out by a proxy. The user may select the location and the type of
engine that can be used for the execution from a predefined clientware execution profile. The
optional execution profile can be used to select the location of the execution engine that could be a
remote proxy capable of supporting the execution of specific tasks such as SQL for executing
database commands.
The data in SyD are assumed to be heterogeneous, i.e. they may be relational database,
object-oriented or even a flat file system. A uniform view of the data may be achieved using
XML/XSL or similar representational languages. Work is currently under way to design wrappers
based on XML schema mappings. The unified object view generator is the device dependent layer
of SyDCW that transforms the local data or files into the common SyD object view. The unified
object view includes peripherals that support data communications between various SyD objects.
36
The other key issue related to the quality of service and reliability is the setup of a backup
device in the form of a proxy. SyDMW communication object can then redirect all communication
protocols to the client proxy that has been predefined in the client profile.
SyDCOs that are related to database applications are implemented such that a collection of
heterogeneous, independent databases collaborates among themselves. These databases are
assumed to be independent, i.e. they do not share a global schema. Each maintains its own schema
and the knowledge of other schemas may be embedded within application logic. External schemas
may also be retrieved on demand. The databases in SyD could be formed in a group of visible
objects with respect to each other to perform and share interesting tasks.
The device speed relative to CPU speed can be used by the clientware in a baseline device
decision on local vs. proxy execution options. Device storage capacity can be used as a parameter
for a decision on employing local storage vs. remote one. Device local data format (relational_DB,
OO_DB, XML, file, …) could be tailored for the implementations of DB related services.
SyD device profile is a device specific profile, that may include a higher level of service
used to invoke several other services and may also yield other additional profile information such as
access to proxy execution. The device profile can also include level of security and quality of
service, etc.
4.2.3 Location Transparency
Transparency to the geographical distribution of data, devices, and services, as long as they are
reachable through the Internet (or alternately the peer-to-peer) infrastructure. The distribution of the
different entities is fully hidden from the application developer who can assume the co-location of
all required entities. SyD allows user, end-system, and object mobility. Further, SyD supports
dynamic object composition and decomposition. Application developers can compose objects from
multiple atomic and composite objects on the fly and the SyD middleware will provide a consistent
abstraction for method invocations on the object by decomposing requests to the respective requests
on the atomic objects. The support for on-the-fly object composition is something that is unique to
the SyD technology.
SyD's transparent execution model consists of four primary components: (i) Object composition:
All entities in SyD are provided with an object view. While application developers can assume the
co-location of all available objects, they can further compose objects in a dynamic fashion and the
resulting interfaces and methods defined on the composite object are realized by the SyD
middleware transparent to the application developer. (ii) Group communication: While most
existing middleware technologies are based on a client-server unicast model, SyD in accordance
with the goal of enabling collaborative applications, has rich support for group communication
between peer applications. While on one level the support for group communication is in the form
of primitives for efficient group information delivery, at another level the primitives enable
scalability by hiding the entire group membership from any individual peer. An example primitive
such as QueryAllMembers can be invoked by a peer without any knowledge of the group
membership. This is particularly relevant for large scale applications. (iii) Mobility Support: Since
one of the goals of SyD is to facilitate application development for heterogeneous devices ranging
from hand-helds to powerful-servers, object (device, data, or service) mobility is another aspect
that SyD explicitly supports and hides from the application.
37
SyD framework supports mechanisms to provide location transparency to distributed, composite,
and collaborative applications as follows:
i.
SyD allows users to dynamically compose applications from existing and potentially
geographically distributed objects, and in the process does not require applications to be
aware of the physical locations of the objects and coordinate group primitives:
a. User chooses a set of objects {O1, O2, .., On} (referred to as sub-objects from
hereon) that physically reside at locations {L1, L2, .., Ln} and defines the methods
of the composite object CO in terms of combinations of methods of the existing
objects.
b. SyD handles all method invocations on the composite object CO by appropriately
coordinating the invocations of the methods of the sub-objects in their respective
locations, and the passage of parameters and results.
ii.
iii.
SyD provides applications support for optimized and lightweight group communication:
Any individual application of a collaborative application consisting of n applications is
unaware of the other constituent applications. SyD through its knowledge of the
topology of the peer-to-peer networked middleware efficiently delivers group
invocations to the appropriate members of the group.
SyD supports application, object, and device mobility:
a. When a device loses connectivity with the SyD middleware, a pre-appointed SyD
proxy takes over the role of the device and serves all transaction requests. Upon
reconnection of the device to the middleware, appropriate synchronization is
performed and conflicts resolved.
b. SyD supports application and object mobility through forward references at the
original location, and optimizes such a mechanism further by patching
communication routes subsequently.
A key usage of the location transparency is thus a method to specify and dynamically enforce QoS
in a distributed environment, integrating QoS at user/application level, by executing a group
functionality of a collaborative application with user-defined QoS attributes by calculating the
available QoS on-the-fly and invoking the constituent services on dynamically selected SyDCOs as
follows: :
ii.
iii.
User invokes the specific group functionality of the desired SyDAppO by
providing the needed QoS attributes.
SyD middleware parses the individual SyDCO functionalities/services and their
sequence/linkage as specified by this group functionality, and for those services
which are not tied to specific SyDCOs, finds a suitable set of SyDCOs which can
provide those individual services and queries them on-the-fly for their current
QoS guarantees on specific services needed of each SyDCO. Based on the
responses from the SyDCOs, a composite QoS is calculated for the entire group
38
iv.
v.
functionality using various alternatives, and top few alternatives are presented to
the user.
User chooses the desired execution alternative based on his QoS requirement.
For example, the QoS needed could be as simple as ensuring that the air ticket,
rental car and hotel room can be all be re-booked to enable travel at a newly
specified delayed time due to an emergency session or traffic condition so that a
user is able to reach his destination in time for a meeting.
SyD middleware follows the chosen transaction sequence and carries out the
group functionality by invoking constituent SyDCO services/transactions while
satisfying the intra-transaction dependencies and constraints as specified by the
underlying links. The overall QoS is also guaranteed (such as atomicity).
5. Global Query, Triggers and Constraints
In today's omnipresent computer network, whether wired or wireless, the user is constantly
interacting with data that is stored in various devices that are part of the network. Individuals
maintain their personal address books, schedules and to-do lists in PDAs while others may keep
shopping lists, personal preferences, etc. One can also envision PDAs and other such devices used
in applications such as doctor's clinic management system where patient appointments, schedules of
doctors, prescriptions etc. are constantly being accessed and updated. One common thread among
these and many other similar scenarios is that databases, owned by different entities, are interacting
with each other and there seems to be a need for "database collaboration" at the global application
level. The types of database interactivity and collaboration that these scenarios may need include
global triggering mechanisms, which allow updates in one database to trigger actions in other
autonomous databases that are part of the application. Other features that may be needed by these
application scenarios are global querying (queries that refer to objects in other autonomous
databases), global constraint specification etc.
SyD provides methods to specifiy and enforce constraints that span several independent
databases/data-stores, as well as to perform collective query and trigger changes over them. Such
constraints are referred to as global constraints. An example of a global constraint in the context of
the personal calendar application is: "In addition to John, at least one other person should
participate in the 2 March 2001 meeting". This constraint spans multiple databases (in particular
the databases that contain personal calendar information for the particular meeting in question).
SyD has the capability of enforcing such a constraint in a seamless manner using a system of links
described in the detailed description. Whenever the state of one of the databases involved changes
to a state in which this constraint is violated, SyD will automatically check for this violation and
will abort such a change of state.
5.1 A Sample SyD Application
Consider the personal databases which several individuals keep in their personal
computers/personal digital assistants (PDAs). Typical data kept in these databases are
appointments, addresses of acquaintances etc. Let us assume there are three individuals, John, Tony
39
and Aaron who maintain such data in their PCs/PDAs. John's database may have the following
schema:
Schedule (date, startTime, endTime, event)
addressBook (name, email, address, wphone, hphone, cphone, fax)
Tony's database may have the following slightly different schema:
Schedule (date, startTime, endTime, event)
addressBook (name, email)
Aaron's database may have the following schema, similar to John's except that emails of
acquaintances are not kept:
Schedule (date, startTime, endTime, event)
AddressBook (name, address, wphone, hphone, cphone, fax)
These three databases are assumed to be located on different nodes of a network and are considered
autonomous. Let us assume that these three individuals work together and hence a need for their
databases to collaborate exists.
Global Queries:
Global queries allow users in one database to extract information from their local database as well
as remote databases. Such queries will have references to remote database objects. As an example
of a global query, consider the following: John would like to set up a meeting with Tony and Aaron
and would like to query their databases for the busy times on 3 March 2001. John could then
execute the following query in his database:
SELECT s.startTime, s.endTime
FROM schedule s, tony.schedule ts, aaron.schedule as
WHERE
s.date = ts.date and
ts.date = as.date and
as.date = to_date(’03-MAR-2001’,’DD-MON-YYYY’);
Notice that in the above "global query" which executes within John's database, there are references
to tables in Tony and Aaron's databases. Here, we are assuming that the name of Tony's database is
tony and that of Aaron's database is aaron. The global names are recognizable by SyD.
As another example of a global query, consider Aaron's problem of locating email addresses of all
individuals in his addressBook. To accomplish this task, Aaron may execute the following "global
query" in his database:
40
SELECT a.email
FROM tony.addressBook a, addressBook b
WHERE a.name = b.name
Here, Aaron is joining his addressBook table with that of Tony's to obtain email addresses.
We envision the need for global querying in SyD applications. Our goal is to provide the ability to
refer to remote objects in queries. The actual implementation of global queries is discussed in the
next section.
Implementation Details:
The API for some of the basic classes and the methods provided by database-aspect of SyD
(syd.gdb).
SydDatabase
SydDatabase( )
void setXXX
void getXXX
java.sql.Connection connect( );
SydSystem
SydSystem( )
void addDatabase( )
void removeDatabase( )
void setMasterDB( )
SydConnection getConnection( )
SydMetadata getSydMetaData( )
void close( )
SydConnection
SydStatement createSydStatement( )
SydCallableStatement createSydCallableStatement( )
SydPreparedStatement createSydPreparedStatement( )
SydMetadata getSydMetadata( )
void close( )
SydStatement
java.sql.ResultSet executeQuery( )
int executeUpdate( )
SydMetadata getSydMetadata( )
void close( )
SydMetaData
String getSchema( )
String[] getTables( )
String[] getColumns( )
String[] getKeys( )
QueryEngine
String parse( )
41
The code for the sample Syd application for the Global Querying example given in the previous
section would look similar to this:
SydSystem syd1 = new SydSystem( )
syd1.addDatabase(“john”, databaseinfo )
syd1.addDatabase(“tony”,databaseinfo)
syd1.adddatabase(“aaron”,databaseinfo)
syd1.setMasterDB(“john”)
SydConnection sc1 = syd1.getConnection( )
SydStatement ss1 = sc1.createSydStatement( )
String query1 = “SELECT s.startTime, s.endTime” +
“FROM schedule s, tony.schedule ts, aaron.schedule as” +
“WHERE s.date = ts.date and ts.date = as.date and “ +
“as.date = to_date(’03-MAR-2001’,’DD-MON-YYYY’)”;
ResultSet r1 = ss1.executeQuery(query1);
syd1.setMasterDB(“aaron”)
String query2 = “SELECT a.email”+
“FROM tony.addressBook a, addressBook b”+
“WHERE a.name = b.name”;
ResultSet r2 = ss1.executeQuery(query2);
SydConnection.close( );
The resultset r1 contains the result for the first and the resultset r2 contains the result for the second
example referred in the previous section.
The global query is sent to the query engine and the remote databases and the corresponding tables
that are referred in the query are identified by the parser and they are copied onto a particular
database specified by the masterDB variable. If there are any changes to be made to the remote
databases then the action is eventually performed.
Steps involved for performing Global Querying on a system of autonomous/independent databases:
1) Parse the global query and identify the databases that needs to be accessed in the system.
2) Split the entire query into individual sub queries and send those to the corresponding
databases
3) Collect the data obtained from the execution of sub-queries on remote databases onto a
virtual local machine.
4) Modify the global query such that all the tables referred in the query are local to the virtual
local machine
5) Execute the modified (global) query gives the desired output.
42
Global Triggers:
Global triggers allow users to specify event-condition-action (ECA) rules that can be used to
propagate local changes to remote databases. For example, in the personal database example, if a
participant in a meeting changes the time of the meeting in his or her personal database, all other
participants in the meeting can be updated of the new time. Let us assume that John, Tony, and
Aaron have scheduled a meeting for 10.00 to 11.00 AM on 3rd March, 2001. A global trigger to
implement a time change in this meeting by John may be specified in John's database as follows:
create or replace
global trigger meetingChange
after update of startTime,endTime
on schedule
when event = 'John-Tony-Aaron Meeting'
begin
-- code to verify if time change is
-- OK with Tony and Aaron schedules
-- goes here
if (time change OK) then
update tony.schedule t
set t.startTime = new.startTime, t.endTime = new.endTime
where t.event = 'John-Tony-Aaron Meeting';
update aaron.schedule a
set a.startTime = new.startTime, a.endTime = new.endTime
where a.event = 'John-Tony-AaronMeeting';
endif
end;
A similar trigger should be specified in Tony as well as Aaron's database. Global triggers provide a
mechanism in SyD to express sophisticated cause-effect sequences of actions to be taken across the
various databases participating in SyD.
Global Constraints:
Global constraints are condition specifications that the System of Databases as a whole must
satisfy. In the personal database example, a constraint might be that in addition to John, at least one
other person should participate in the 2 March 2001 meeting. Such a constraint may be specified as
follows:
create or replace assertion
atLeastTwo as
exists (select *
from john.schedule j
where j.event = 'John-Tony-Aaron Meeting')
and
43
(exists (select *
from tony.schedule t
where t.event = 'John-Tony-Aaron Meeting')
or
exists (select *
from john.schedule a
where a.event = 'John-Tony-Aaron Meeting'));
This constraint must be specified in the database of each participant, since any change in any of
these three databases affects this constraint. global constraints are a powerful mechanism to specify
conditions that must be met across databases.
The global triggering and constraints can also be implemented similarly using the API from the
application program.
5.2 A SOAP-based Implementation
We propose an implementation of some of the concepts introduced in the previous section. The
Simple Object Access Protocol (SOAP) is a lightweight protocol for remote procedure calls and
exchange of data across a network. It is XML-based and is well suited as a transport mechanism for
SyD. In the proposed implementation, global queries, triggers and constraints are parsed and
translated into SOAP messages that query/update remote databases. Figure 8 shows the various
components at each of the nodes in the network. We assume that a database server resides on each
of the nodes and that both a SOAP server (SS) as well as a SOAP client (SC) is present at each
node. The SOAP client is responsible for sending out requests for remote data or sending out
remote updates. The SOAP server on each node is responsible for responding to SOAP requests.
SOAP messages are automatically generated. Underlying all this is a global access control
mechanism which ensures that only authorized users/requests are accepted by the SOAP server
module.
Global queries may be implemented as follows: The query processor parses the query for references
to remote objects, generates SOAP requests to fetch the remote objects (tables) and dispatches these
SOAP requests to the appropriate SOAP server. The query processor interacts with the SOAP
Client at its end to accomplish this. The SOAP server on the other end first verifies via the Access
Control Mechanism (possibly an Access Control List – ACL) to see if the request is from a valid
user/node and then processes the request (by contacting the Database Server at its end). It then
returns the information back to the SOAP Client that requested it. After collecting all the remote
data, the query processor then proceeds to evaluate the query.
44
Figure 8: SOAP-based implementation of SyD DB Constraints.
Global triggers are also implemented in a similar manner. The triggers that reference remote objects
are compiled into SOAP messages that send "executable code" to remote databases for execution
via SOAP clients. The SOAP servers on the other end will verify for authorization, as usual.
Enforcing global constraints are a bigger challenge. The global constraints must be defined in each
database to which references are made in the constraint. On a database state change in each of these
referenced databases, the constraint must be checked. This could again be accomplished using
SOAP for retrieving remote data necessary to verify the constraint. Global constraints need be
compiled into the database system.
In the following section, we describe SyD coordination link primitives which captures global
trigger and constraint information and provide effective methods of their execution.
6. SyD Coordination Links
We provide a method to establish dependency structure among entities with on-the-fly user-defined
coordination links. While it is convenient to think of an entity as a row, a column, a table, or a set
of tables in a data-store, the concept transcends these to any object or its component. These links
45
incorporate global constraints, triggers, query and updates across independent databases/objects.
Without loss of generality, in the following discussion, we employ the term database to denote any
object or its component.
5.1 Specification of a Coordination Link
A coordination link (also called a SyD link) is an entry in a database associated with an entity that
has the following components:
1. The link type, representing the kind of link (for example, a subscription link).
2. One or more references to other database entities.
A reference is usually static, but may also be relative (for example, a reference to a table
entry selected using a query).
3. Triggers associated with each reference.
A trigger (event condition action rule) itself may comprise the triggering event (for example,
on an update/delete), any condition to be checked after the triggering event (for example, in
a bank, IRS is informed only if an account gets a deposit of $10,000 or more), and an action
(for example, invoke a remote procedure, say, a scheduler agent and, based on its response,
update a row at a remote database). One or more triggers may be related to the expiry of the
link.
4. A priority.
5. Status: Certain/Tentative.
A tentative link may become certain if the awaited certain link is destroyed.
6. A waiting list of tentative links (a priority queue).
5.2 Operations on Links
A link should allow several kinds of group operations on a set of related databases. Let an entity A
be linked to entities B and C, which may in turn be linked to other entities. A change in A may
trigger changes in B and C, or A can change only if B and C can be successfully changed. We
define two primary types of coordination links, namely, subscription link and negotiation link.
Subscription link allows automatic flow of information from a source entity to other entities that
subscribe to it. This can be employed for synchronization as well as more complex changes.
Negotiation links enforce dependencies and constraints across entities and trigger changes based on
constraint satisfaction.
5.2.1 Classification and Semantics of Collaboration Links
The phrase "Change X" is employed to refer to an action on X; "Mark X" refers to an attempted
change, which triggers any associated link without actual change in X.
Subscription Link: Mark A; If successful Change A then Try: Change B, Change C.
A ``try" may not succeed.
46
Negotiation-and Link: Change A only if B and C can be successfully changed.
(implements atomic transaction with "and" logic).
Semantics (may not be implemented this way):
Mark A for change and Lock A
If successful
Mark B and C for change and Lock B and C
If successful
Change A
Change B and C
Unlock B and C
Unlock A
Negotiation-or Link: Change A only if at least one of B and C can be successfully changed.
(implements atomic transaction with "or" logic and can be extended to at least k out of n).
Semantics:
Mark A for change and lock A
Mark B and C for change; Obtain locks on those
entities that can be successfully changed.
If obtained at least one lock
then Change A; Change the locked entries.
Unlock entries
Negotiation-xor Link: Change A only if exactly one of B and C can be successfully changed.
(implements atomic transaction with "xor" logic and can be extended to exactly k out of n).
Semantics:
Mark A for change and lock A
Mark B and C for change. Obtain locks on those
entities that can be successfully changed.
If obtained exactly one lock
then Change A; Change the locked entries.
Unlock entries
The Figure 9 depicts a link from A to B and to C, and Figure 10 below shows the UML activity
diagrams showing execution of SyD links for three types of negotiation links (a) negotiation-and,
47
(b) negotiation-or, and (c) negotiation-xor links for three SyD objects A, B, and C where A is the
activating object.
Figure 9. UML object diagram showing links between SyD entities.
Figure 10. UML activity diagrams showing execution of SyD links for three types of negotiation links (a)
negotiation-and, (b) negotiation-or, and (c) negotiation-xor links for three SyD objects A, B, and C where A is
the activating object.
If entity X has no links, Mark X changes X. If entity X has multiple links of various kinds, all links
must be successful before Mark X is successful. The proposed logical constraints on SyD links may
be extended to arithmetic and general Boolean conditions. An implementation of these links
constraints based on a two-phase commit protocol is contained in Appendix.
48
In SyD, one cannot enforce a change to an entity with a link; otherwise inconsistent updates will
take place. For example, if A has a negotiation link to B and a subscription link to C, only if B can
be changed then A can be changed. A change in A (which in turn depends on a change in B) will
cause A to try a change in C. Thus, subscription links can be thought of as links to a descendant in a
partial order (lower priority), and a negotiation link as a link to an ancestor (higher priority). Thus,
a partial order hierarchy may implicitly be defined. Presence of a cyclic dependency could indicate
a problem in defining the linked structure (or creation of such a cycle itself can be avoided).
However, for certain applications, cyclic dependency and feedback loops may be important in
themselves, in which case, a resolution of cyclic dependency is needed. We propose a Petri Net
model of the coordination link structure and operations.
Some of the simpler links not listed are on-demand "query" and "update" links. Simple on demand
queries are carried out by the query links which are like the conventional hyper-links with
underlying queries to be executed at the remote databases and the resulting views combined
appropriately and returned to the originator. Likewise, simple on demand writes/updates are carried
out by the update links which are like the conventional hyper-links with underlying update
transactions (consisting of one or more write operations such as insert, update or delete, with
possibly a query interspersed) to be executed at the remote databases and the resulting views (or,
success/failure status) combined and returned to the originator.
A link may be tentative. For example, if an attendee cannot commit for a meeting at the time
meeting is created, but if the initiator still wants to create a tentative meeting, pending changes in
the schedule of the attendee at a later time. If this attendee is a must attendee, then there is a
tentative back link created to the initiator. Typically, the reason that an attendee cannot commit is
because of a prior commitment, and hence a non-tentative certain back negotiation link. Many
such tentative links may go out from an attendee, and therefore, these tentative links are in a
priority queue of waiting list. If and when the certain back link is destroyed, the top tentative link in
the waiting list is converted to a certain link, and the associated trigger is activated. This trigger
could allow the initiator of the meeting to resolve the conflicts for this meeting and declare it
committed.
Notations: A subscription link from A to B is denoted as a dashed directed arrow from A to B. A
negotiation link from A to B is denoted as a solid directed arrow from A to B. A negotiation-and
link from A to B and C is denoted by two solid arrows, one each to B and C, with a "*" in between
the arrows. Similarly, a negotiation-or link from A to B and C is denoted by two solid arrows, one
each to B and C, with a "+" in between the arrows. A negotiation-xor link from A to B and C is
denoted by two solid arrows, one each to B and C, with a "^" in between the arrows. A tentative
link, which is a negotiation link in a waiting list, is shown as a solid arrow with cuts.
5.2.2 Composition Operations on Links
Bi-directional Links are a combination of two links back and forth between two entities. Examples
are
49
Co-Dependency Bi-directional Link: If A has a solid arrow to B and B has a solid arrow to A then
there is a "co-dependency" bi-directional link between A and B, denoted by a solid bi-directional
arrow between A and B.
Subordinate Bi-directional Link: If A has a solid arrow to B and B has a dashed arrow to A then
there is a "subordinate" bi-directional link from A to B, denoted by a bi-directional link between A
and B with solid line on B's side and dashed line on A's side.
Informational-peer Bi-directional Link: If A and B have subscription links to each other then there
is an "informational-peer" bi-directional link between A to B, denoted by a bi-directional dashed
link between A and B.
A group of links is a combination of two or more links among several entities. Examples are:
Co-dependency Star Link: If A has solid arrows to Bi and Bi have solid arrows to A, for 1 <= i <=
k, then there is a "co-dependency" star link between A and Bi's. Semantically, this represents a
hyper-edge of co-dependency among the entities involved.
Negotiation Chain: If A1 has a solid arrow to A2, A2 has a solid arrow to A3, and likewise, Ak-1
has a solid arrow to Ak, then there is a "negotiation chain" starting at A1 and ending at Ak.
A similar subscription chain can be defined.
General chain: A general chain will consist of one or more negotiation chains with intervening
subscription chains.
A link algebra may be developed based on these link types.
5.3 Properties of Links
Creation: Based on events and actions; generally created as a result of a user or link action.
Duration: Based on events, including the timer. In the latter case, a subscription link from the timer
would be established with an associated action for expiry.
Directional Properties: Each collaboration link has an arrow with a definite action initiated from the
source, and resulting actions performed at the destination.
Criteria for validation of links are being developed.
5.4. A Meeting Application based on Calendars
A typical scenario for meeting setup is that a user enters the dates between which he wants to setup
a meeting and also the people whom he wants to call for the meeting. Out comes a list of open slots
common to all the participants, and then with a click on the desired slot, the meeting is scheduled.
Of course, there may be additional criteria, such as A and B must be attendees, but one of C, D, E
50
would suffice. After finding an empty slot, the meeting may only get tentatively scheduled, because
during the delay between the enquiry for the empty slots and the actual scheduling, the status of the
participants may have changed. Also, someone may want to voluntarily change his schedule later,
potentially causing the meeting to become tentative or getting canceled. Likewise, a higher priority
meeting may bump a previously scheduled meeting. A tentative meeting may be confirmed at a
later time due to some cancellations. Also, an executive may want to delegate the task of
scheduling a meeting to a staff, and the staff would be able to call the meeting with the transferred
authority of his boss.
We demonstrate here how an empty time slot is found, how a meeting is setup (tentative and
confirmed), and how voluntary and involuntary changes are automatically handled.
A simple scenario is as follows: A wants to call a meeting between dates d1 and d2 involving folks
B, C, D and himself. The first step is to find the empty slots in everybody's calendar. The finding
of empty slots can be carried out as follows: Assume each person has a calendar table (if not, the
raw information is translated to such a table, transparently, by style files and such) As A enters the
dates and the people for the meeting in a GUI form, following steps are carried out: From an empty
slot in A's calendar, query-and links are established to all participant's calendar tables, triggered by
the form's submit button. The `action' of this query link is to
(i) query each table for free slots which fall between dates d1 and d2
(ii) ensure that all participants respond, before the subsequent actions would be valid.
(iii) find empty slots by and-ing the views returned from calendars.
(iv) Presenting these slots to A.
A then clicks the desired empty slot. This causes a series of steps. A negotiation-and link is created
from A's slot to the specific slot in each calendar table (Figure 11). The link is triggered by any
change in A's slot. Choosing the desired slot attempts to write and reserve that slot in A's calendar,
and that triggers the negotiation-and link. The `action' of this link is to
(i) query each table for this desired slot, and ensure that it is not reserved, and reserve this slot.
(ii) if all succeed, then each corresponding slots at A, B, C and D create a negotiation link back to
A's slot.
51
B
A
*
Timer
Expires after
meeting
D
C
Trigger event: change in A’s slot
Action: 1. Query & reserve the slots
2. On success, create back
negotiation links to A’s slot
Figure 11. A scheduled meeting
For a link's expiry, a subscription link from a timer entity to A is created, to be triggered after the
meeting, which triggers the deletion of the forward and back links.
Else, for those folks who could not be reserved, a tentative back link to A is queued up at the
corresponding slots to be triggered whenever the status of the slot changes. The forward
negotiation-and link to A, B, C and D are left in place. In addition, back subscription links to A
from others are created. These subscription links inform A on subsequent changes in the other
participants and would help A decide (based on a threshold) to cancel this tentative meeting
altogether or try another time slot.
Assume that C could not be reserved. Thus, C has a tentative back link to A, and others have
subscription links to A (Figure 12). Whenever C becomes available (or its status changes for this
slot), if the tentative link back to A is of highest priority, it will get triggered, informing A of C's
availability, and will attempt to change A's slot to be
52
B
A
*
Timer
C
Commited elsewhere
Tentative link
D
Waiting
list
Figure 12. A Tentative Meeting
reserved. This would trigger the negotiation-and link from A to A, B, C and D, which in turn go
through another round of negotiation to reserve each of the four folks, and assuming that all
succeed (C already is available), all corresponding slots are reserved, and the target slots at A, B, C
and D create negotiation links back to A's slot (Fig 11). Thus, a tentative meeting has been
converted to committed.
Now suppose, D wants to change the schedule for this meeting to another slot. This attempt by D
would trigger its back link to A, which would trigger the forward negotiation-and link from A to A,
B, C and D. If all succeed, then a new duration is reserved at each calendar with all forward and
back links established. If not all can agree, then D would be unable to change the schedule of the
meeting. Similar actions would take place if D simply wanted to cancel, or if D is involuntarily
asked to bump this meeting by another entity. A higher priority request to D to commit to another
meeting would bump this meeting, and then this meeting would become tentative as in Fig. 12, with
D (instead of C) with a tentative link back to A.
Suppose B is a supervisor (a higher priority entity). Then, as a result of the meeting schedule, A
would not be able to establish a negotiation back link from B, but only a subscription back link (Fig
13). This retains B's ability to change his schedule at will. If B does change his schedule, this
change will trigger the subscription back link to A, and A will negotiate with A, C and D for the
change. If one fails, then the meeting becomes tentative, which results in conversion of all back
links to A to
subscription links and conversion of back link from B to A into a tentative link queued up at B's slot
awaiting change in B's status (like Fig 1, with B instead C with a tentative back link).
53
A
B
B is a supervisor
*
D
C
Figure 13. Another Scheduled Meeting
As a second example, suppose A wants to schedule a meeting with a quorum of 50% among the
faculty of Biology and at least two faculties from Physics and, in addition, B and C are must
attendees. This meeting can be scheduled by establishing a negotiation-and link to B and C (must
attendees), a negotiation-or link (at least k of n type) to all in Biology with n = size of biology
faculty, and k = 50% of n, and a negotiation-or link to all in Physics with k = 2. On successful
reservation of all entities, slots are reserved at the accepting entities and negotiation back links to A
are established. Fig 14 shows a scheduled meeting assuming there are four Biologists and three
Physicists.
54
A
Bio 1
+ (>= 2)
*
Bio 2
+ (>=2)
Bio 3
B
Bio 4
Phy 1
C
Phy 2
Phy 3
Figure 14. A Scheduled Meeting
From the non-accepting entities, a tentative link back to A is established, thus allowing these
faculty members to reserve their slots in future, if they become available. A cancellation by
someone in Biology will trigger the back link to A and which in turn will trigger the negotiation
links from A to all. In particular, the negotiation-or link to Biology faculty will make a
determination if 50% can still make it, and then grant the cancellation to the Biology faculty
requesting it. If the quorum falls below 50% among the Biologists, the negotiation-or links to the
remaining Biologists are triggered, and only if an additional commitment is found, that the
cancellation request is granted.
As a third example, a supervisor may want to delegate the task of scheduling a meeting to a staff
person. Suppose A is the supervisor and B is the staff person. A needs to call a meeting involving
A, C and D as well as 50% of Biologists, but wants B to schedule it. A establishes a negotiation link
from his things-to-do table to B's to-do table, with an action of setting up the aforementioned
meeting by B, and on success, establishes a negotiation back link from B to A. B in turn establishes
a negotiation-and link to calendars of A, C and D, and also a negotiation-or link (50%) to the
Biologists (Figure 15).
55
A (supervisor)
B (staff)
B’s To-Do List
A’s To –Do List
Action: setup meeting
A’s Calendar
*
+
(>=2)
Bio 1
C’s Calendar
Bio 2
Bio 3
D’s Calendar
Bio 4
Figure 15. A Scheduled Meeting
The actions taking place with respect to B are same as that with any initiator of a meeting.
5.5 Algorithms for SyD Links
5.5.1. A Recursive Algorithm
The following is a recursive algorithm for a link operation. It consists of two procedures: poll and
commit. The polling procedure checks if the requested operation can be performed. If so, the
commit operation is carried out. Otherwise, the link operation has to be delayed or aborted.
An entity is locked until either a successful operation is performed on it or a polling is unsuccessful.
Assuming a semaphore-based lock, a lock operation is similar to a wait operation. If a process
performs a lock operation on an already locked entity, it is put into a queue associated with that
entity. Once the entity is unlocked, the process will continue. The requests are put into a queue in
FIFO fashion. An unlock operation is similar to a signal operation. It wakes up the first process in
its queue.
In the following algorithm, we assume that the depth of a hierarchy is bounded, that there are no
faulty entities in the system, and that the update operations take bounded time. If these conditions
are not satisfied, we may use a timer to perform timeout to recover.
56
The update procedure updates an entity after successful condition checking. The parameter Source
indicates which entity initiates the polling procedure.
Procedure poll (Source, A)
-- Check if the operation can be done
-- Example: the entity is in green state --> ok
-- red state --> reject
-- Reservation_allowed () is a function returning True or False
-- It makes its own decision based Source and what type of
-- requests it gets.
-- Source_ID, initially Null, is the ID of the initiator
-- entity holding a lock on A
if (!Reservation_Allowed (Source)) OR ((Source_ID \= Null) AND (Source \= Source_ID)) then
return unsuccessful;
begin Atomic
-- if request from the same source, return immediately
if Source = Source_ID
then return successful;
-- lock the current entity and update Source_In_Use
lock (A);
Source_ID = Source;
end Atomic
-- Check children recursively
n = 0;
For all children I in parallel:
status_I = poll (Source, I);
n = n + status_I; -- # of successful children
end For;
-- Check condition for its children.
-- Link_Constraint ( ) is a Boolean function
-- It could be like:
-- If n=# of children (AND operation)
-- If n=1 (OR operation)
-- If n>=C (A specified count of children)
if (Link_Constraint ())
then return successful;
-- If not successful, unlock itself and all the children
else unlock(A); Source_ID = Null;
unlock descendants; return unsuccessful;
57
end poll;
Procedure commit (A)
-- Recursively update all the descendants
For all children I in parallel:
commit (I);
end for;
-- update itself;
update (A);
-- unlock itself and wake up all the waiting requests
unlock (A); Source_ID = Null; unlock descendants
end commit;
In the following example, we assume that we start a link operation from entity A. For a link
operation, we need to poll its children first, then update them. If not successful, the process waits
for S seconds, and tries again. The procedure is shown below.
Procedure Negotiate_link (A)
Source = A;
for loop
if (poll (Source,A) = successful)
then commit (A);
-- if not successful, wait S seconds and
-- then try again
else wait (S);
loop for;
end Negotiate_link;
There are two possible implementations of polling. The first is concurrent polling as shown above.
Entity A polls all the children concurrently. The second is to polls its children sequentially by
circulating a polling message. This method requires establishing a cycle among all its children and
the message must contain a list of all children to be traversed.
The advantages of the first method are that it is faster, and the message length is shorter. The
disadvantage is that the number of messages is larger than the sequential one. If the hierarchical
structure contains a lot of entities, the second method requires sequential depth-first traversal, and is
too slow.
58
5.5.2. Resolving Deadlocks in Faulty Real-time Environment
The protocols established earlier need to ensure resolution or avoidance of deadlocks caused by
faults of software, hardware or media for databases or by time-dependency. Below we classify the
types of deadlocks and suggest ways of their resolution.
Loop deadlock:. These deadlocks are caused by logical dependency. For example, entity A makes a
link request to entity B and entity B makes a link request to entity A. To ensure that such deadlock
will not occur, we may assume a hierarchical structure of requests, e.g.,
Each entity has a rank and can send link requests only to entities with lower rank (priority), or,
all entities are ordered in a total order and locks always proceed in the increasing order of entities,
or
Expiration times for each request with the request retrial after waiting for a random amount of time
for timeout.
Self-deadlocks: These occur when the same initiator triggers several links competing for the same
entity. For example, A requests AND links to B and C (e.g., a meeting) and after getting the
request, B triggers a request to C to attend. Since C by that time will be already committed to Alink, B will return a negative answer to A triggering canceling the meeting. Therefore, B should be
able to recognize that C is committed to the same meeting as B requests for. This deadlock may be
resolved by keeping "job ID" with each initiating link. Since B asks C to do the same as A requests
for, in a logical condition B can take this deadlock into account and return success if C is
committed to the same job ID. Note that self-deadlocking may be useful. For example, AND links
from A to B and C may require B to attend the meeting and C to prepare a draft of the meeting
agenda. If B needs C to prepare a report for the same meeting, then B cannot plan that the report
will be done in the same time-slot as meeting agenda. Thus, even if job ID's are the same, the
accompanying actions need to be processed in order to decide whether to abort one request or to
grant both.
Fault-induced deadlock: Since mobile devices tend to be unreachable or down quite often, the faulttolerant issues become essential in mobile environment (which may include calendars on hand-held
devices). For example, link-initiating entity A, which has already triggered locking of several
entities, is suddenly down. Then unlocking of all these entities as well as canceling commitment
links should be triggered by such an event. A timeout mechanism may be employed to detect such
events.
59
Claims
1. A methodology, namely System on Devices (SyD), to rapidly develop and deploy robust
distributed collaborative applications, wherein plurality of SyD components collaborate, consisting
of the following steps:
a. Model the new distributed application in terms of typically one but possibly more composite
objects (referred to as SyDAppOs) comprising basic objects providing core services/methods
and data sources (SyDCOs), existing SyD middleware objects (SyDMWOs) providing
specialized services, and other existing applications and their inter-relationships.
b. Search and locate the required SyDCOs, SyDMWOs, and SyDAppOs by employing the SyD
Directory Service. If all the needed SyDCOs found then skip Step (c) below. If all the needed
SyDAppOs found, then also skip Step (d) below.
c. Develop and deploy new SyDCOs by starting either with the SyD skeleton for a SyDCO,
containing predefined core SyDCO functionalities, or with a related pre-existing SyDCO and
adding the desired new functionalities by defining and implementing methods and persistent
data structure/schemas, and launch the new SyDCO, thereby registering it, along with its QoS
attributes, with the SyD Directory Service.
d. Develop and deploy new SyDAppOs by employing suitable generic or domain-specific GUIbased SyD application developer service as follows:
i. Choose the needed SyDCOs, SyDMWOs and SyDAppOs to be part of this SyDAppO.
ii. Define new group functionalities, by employing suitable SyD templates classes, in terms
of the individual functionalities of the constituent SyDCOs, SyDMWOs and SyDAppOs.
iii. Launch the SyDAppO thereby registering it with the SyD Directory Service.
e. Develop high-level application server code by employing the objects/methods of the
SyDAppOs – typically the server code simply invokes the functionalities of a single SyDAppO
in which case the application is basically the SyDAppO itself. Also, develop a separate client
code, which typically is a browser/GUI page, by extending the generic interfaces for SyD
applications/SyDAppOs, if needed.
2. [refines Claim 1]
A methodology for users to develop and deploy ad-hoc collaborative applications on-the-fly by
leveraging off the pre-existing providers of services/methods and data sources, SyDCOs,
SyDMWOs and SyDAppOs, by composing the SyDCOs and others in an application-specific
structure by linking them through SyD-links as follows:
i. Search and locate the required SyDCOs and other objects by employing the SyD Directory
Service.
ii. Develop and deploy the ad-hoc collaborative application SyDAppO by employing a suitable
domain-specific GUI-based SyD ad-hoc application developer service as follows:
a. Choose the desired SyDCOs and other objects to be part of this ad-hoc application
SyDAppO.
b. Create SyD-links among the SyDCOs and other objects and define the attributes of each
link thereby establishing the required constraints and dependencies among the constituent
objects (or their parts), and verify the intended functionality and QoS attributes by a
simulated execution.
c. Launch the ad-hoc application SyDAppO thereby registering it with the SyD Directory
Service.
60
3. [refines claims 1, 2]
Methods to specifiy and enforce constraints that span several independent databases/data-stores, as
well as to perform collective query and trigger changes over them.
3. [supports claim 1, 2(ii)(b), and 3]
A method to establish dependency structure among entities (objects or their components), by
linking underlying data and specifying constraints using SyD coordination links.
4. An approach to deploy and execute collaborative applications as follows:
i.
To deploy and run an application, the application is launched on a home SyDMW (each
application may have a home SyDMW providing specialized SyDMWOs), and registered
with the home and other SyDMWs. A typical user may run this application by joining the
group of users executing on the home SyDMW. Another option is that client’s SyDMW
downloads the application and launches it. The third scenario is that the client’s SyDMW
runs the application locally, but employs the home SyDMW for its special services.
ii.
Once a collaborative application comprising one or more SyDAPPOs is launched on the
SyD middleware, the group functionalities of SyDAppOs may be invoked. Such an
invocation is decomposed into appropriate invocations on the constituent objects, the
SyDCOs and other objects.
iii.
The SyDCOs carry out individual methods invoked, possibly by employing their proxies to
account for mobility or QoS guarantees. A change in one SyDCO may be linked to changes
in other SyDCOs resulting in a cascade of method invocations and changes.
iv.
The individual results from SyDCOs are combined according to the SyDAPPO group
functionality specification.
5. [extends claim 5]
An approach to deploy and execute collaborative applications on heterogeneous platforms by
executing the individual SyDCO methods by the SyD clientware middleware, SyDCW,
independent of device and data characteristics, and by adminitering the groups of SyDCOs
comprising a SyDAPPO seamlessly by the SyD group middleware, SyDMW, across
heterogeneous networks as follows:
a. SyD presents a uniform and persistent object view of the device data and methods through
SyDCO encapsulation
i. The uniform object view and its persistence are enabled by the SyD clientware on each
device
ii. The unified object view generator is the device dependent layer of SyDCW that
transforms the local data or files into the common SyD object view.
iii. The client objects export the data that the client devices hold along with
methods/operations that allow access as well as manipulation of this data in a controlled
manner; proxies are employed to account for resource constraints of devices and their
mobility.
61
b. Groups of SyD devices are managed by the SyDMW that brokers all inter-device activities,
and presents a uniform world-view to the SyD application
i.
The SyDMW maintains a directory service to allow a SyD user to find a list of all
SyD objects/devices/groups/applications
ii.
The primitive SyDMW object, the coordination link, is used to enforce
interdependencies, constraints and automatic updates among groups of SyD entities
iii.
The decomposition of group functionality to invocations of individual SyDCO
methods and combining of the results of the SyDCO responses across
heterogeneous networks is taken care of by the SyD group middleware.
6. [supports 1,2,5,6]
Methods to instantiate new SyD core objects (SyDCOs) and composite objects (SyDAppOs) by
employing the SyD middleware class hierarchy and methods to invoke SyD group and
clientware middleware functionalities through various application programming interfaces
comprising four classes of service including Directory and Ad-Hoc Group Management
services, Communication Services, SyD Quality of Service management, and SyD Data
Services.
8. [supports claim 5,6]
i.
A method to provide support for resource constraints and unavailability of
mobile SyDCOs/entities by employing proxies as follows:
a. Clients can predefine a client proxy so that the SyDMW
communication object can redirect all communication
protocols to this point
b. As a mobile device does not have service or is switched
off, a trigger is automatically sent to the proxy for it to
take over and the name server is notified of this
substitution as well.
c. Mobile devices that do not have the capacity to perform
functions locally can register with a proxy so that all
execution steps take place at the proxy and the mobile
device acts as a pure client (browser) only.
d. When the device is capable again, then a synchronization
takes place with the local data and the data held by the
proxy.
ii.
An approach to employ proxies with 2-way communication, one serving a client
device and another interacting with other devices and the middleware, as
follows: When a proxy is offering a replacement service, it can accept new
information and update its client data and also send out requests and change data
in other databases, i.e. it can behave as an active proxy.
9. [ supports claim 5 and extends 4]:
A method to execute an invoked SyD link by interpreting the semantics of the SyD links according
to its type, and actuating the associated triggers.
62
10. [extends 4,5,6]
A method to execute a series of related transactions atomically involving autonomous entities.
11. [extends claim 1,2, 5, 6]
A method to specify and dynamically enforce QoS in a distributed environment, integrating QoS at
user/application level, by executing a group functionality of a collaborative application with userdefined QoS attributes by calculating the available QoS on-the-fly and invoking the constituent
services on dynamically selected SyDCOs.
12. [supports claims 1, 2, 5, 6]
A specification of a middleware architecture for creation, maintenance, and execution of distributed
objects and of collaborative group applications among those objects, residing in multiple
subsystems and devices connected through network infrastructure comprising:
i.
Ordered stores of data, be they formal databases or ASCII lists, stored on PDAs or
on mainframes, are supported by SyD client middleware (SyDCW) that allows the
construction, naming, and publication of SyD Client Objects (SyDCO) that operate
on these data stores through methods.
ii.
SyD middleware (SyDMW) is responsible for making software applications
(anywhere) aware of the named objects and their methods/services, executing these
methods on behalf of applications, allowing the construction of SyD Application
Objects (SyDAppO) that are built on SyDCOs, and providing the communications
infrastructure between SyD Applications (SyDApps), in addition to providing QoS
support services for SyDApps.
iii.
SyDApps are applications written by and for the end users (human or machine) that
operate on the SyDAppOs alone and are able to define their own services that utilize
the SyDAppsOs, without directly depending on either the location or the type of
database or type of device (PDA or mainframe) where a certain information field is
stored. The SyD middleware (SyDMW) provides only a named SyDCO for use by
the SyDApps, without revealing the physical address, type or location of the
information store.
63
Abstract
We disclose a novel programming methodology and framework, called System on Devices (SyD),
for developing collaborative applications executing over a collection of independent mobile (in
space and time) data-stores, leveraging off the best in object-oriented design and middleware
technologies. SyD provides an open and unified software environment to develop platformindependent applications for a collection of heterogeneous devices, such as cell phones, handhelds,
PCs and servers. SyD uses a powerful paradigm of separating device management from the
management of groups of devices, and separates operations on data stores from the dependence of
being aware of where these data stores are located and how they are changing or what they
contain. Each device is managed by a SyD clientware that encapsulates it to present a uniform and
persistent object view of the device data and methods. Groups of SyD devices are managed by the
SyD middleware that brokers all inter-device activities, and presents a uniform world-view to the
SyD application to be developed and executed on. The proposed architecture is superior to the
existing middleware and database technologies such as the conventional client-server, federated
and multi-database architectures, and its middleware allows query processing and updates
originating from any client and involving an arbitrary set of participating databases. The
dynamicity of creating groups of clients that collaborate, as well as the peer-to-peer database
processing capability are novel features of SyD and are illustrated through the calendar, fleet and
airport applications.
Drawings
64