Robert M. Arlein

The Ode active database: trigger semantics and implementation

Ode is an active database system and environment based on the object paradigm. Triggers are the basic ingredient of active databases. Ode triggers are event-action pairs. An event can be a composite event (i.e. an event composed from other events). Composite events are detected by translating the event specifications into finite state machines. In this paper, we describe the integration and implementation of composite event-based triggers into the Ode object database. We focus on implementation details such as the basic trigger events supported, the efficient posting of these events, the handling of transaction-related events and the integration of triggers into a real database. We also describe the run-time facilities used to support trigger processing and describe some experiences we gained while implementing triggers. We illustrate Ode trigger facilities with a credit card example.

Privacy-preserving global customization

We present an architecture for global customization of web content, by which a web site can customize content for each visitor based on the activities undertaken by the same user on other, unrelated sites. Our architecture distinguishes itself in the privacy mechanisms it provides: each user controls what information a merchant can learn about her activities at other merchants, and each merchant controls to what other merchants the information it contributes is revealed. To achieve this we introduce novel data protection mechanisms for merchants and users. We further describe aspects of a prototype implementation of our architecture.

MetaComm: a meta-directory for telecommunications

A great deal of corporate data is buried in network devices-such as PBX messaging/email platforms, and data networking equipment-where it is difficult to access and modify. Typically, the data is only available to the device itself for its internal purposes and it must be administered using either a proprietary interface or a standard protocol against a proprietary schema. This leads to many problems, most notably: the need for data replication and difficult interoperation with other devices and applications. MetaComm addresses these problems by providing a framework to integrate data from multiple devices into a meta-directory. The system allows user information to be modified through a directory using the LDAP protocol as well as directly through two legacy devices: a Definity(R) PBX and a voice messaging system. In order to prevent data inconsistencies, updates to any system must be reflected appropriately in all systems. This paper describes how MetaComm maintains consistency when data integration is performed across several systems with no triggers and with extremely weak typing and transactional support. We also discuss implementation details and experiences.

The LTAP trigger gateway for LDAP directories

LDAP (Lightweight Directory Access Protocol) directories are being rapidly deployed on the web. They are currently used to store data like white pages information, user profiles, and network device descriptions. LDAP directories offer scalability advantages over current database technologies, as well as being more flexible. However, as users begin to use them for Directory Enabled Networking tasks such as provisioning network services, allocating resources, reporting, managing end‐to‐end security, and offering mobile users customized features that follow them, LDAPs limited functionality becomes a significant barrier to progress. For example, LDAP directories do not have active database functionality (i.e., triggers). However, triggers are necessary for monitoring changes to directories and taking appropriate actions, just as they are for databases. Such functionality is crucial to take full advantage of proposals such as the Directory Enabled Network (DEN) initiative. Currently, trigger functionality is non‐standardized for LDAP and each vendors solution is non‐portable. We built the Lightweight Trigger Access Process (LTAP) gateway to provide a portable way to add triggers to a LDAP directory. We describe the trigger language, the gateways implementation, as well as our experiences gained both during implementation and from our users. LTAP is currently being used in several projects. LTAP can be downloaded at http://ltap.bell‐labs.com. Copyright

An extensible framework for constructing SIP user agents

A Session Initiation Protocol (SIP) user agent is an endpoint in a signaling network that can send or receive SIP messages. One can build a functional user agent in a few hundred lines of Java∗ code that sets up a call between two SIP phones. However, such a user agent will not fully comply with the protocol. Writing a compliant user agent is a complex undertaking involving thousands of lines of code. The iSURF framework greatly reduces the effort of this undertaking. iSURF uses a SIP transaction library called siptrans as its transaction processing layer. However, iSURF can use a different transaction library, and siptrans can be used in a different framework or even in a SIP proxy. In this paper, we describe the protocol requirements for a SIP user agent and how our framework facilitates building such an agent. We also describe the design and architecture of both iSURF and siptrans.

Making LDAP Active with the LTAP Gateway

LDAP (Lightweight Directory Access Protocol) directories are being rapidly deployed on the Web. They are currently used to store data like white pages information, user profiles, and network device descriptions. These directories offer a number of advantages over current database technology in that they provide better support for heterogeneity and scalability. However, they lack some basic database functionality (e.g., triggers, transactions) that is crucial for Directory Enabled Networking (DEN) tasks like provisioning network services, allocating resources, reporting, managing end-to-end security, and offering mobile users customized features that follow them. In order to address these limitations while keeping the simplicity and performance features of LDAP directories, unbundled and portable solutions are needed.

Developing applications for EBIF and tru2way

The ongoing convergence of Computers, Telephony and Television, along with an increasing interest by Cable MSOs in interactive applications, has created opportunities for developers to create interactive rich applications on a new set of platforms. The MSOs are basing their foray into interactive applications on industry standard platforms and environments. This paper provides an overview of the two main platforms (EBIF and tru2way) and discusses the implementation of an interactive application that will execute on both platforms. Implementing the same app on each platform will allow us to compare and contrast the differences between and limitations of the two standards. It is hoped that application developers will be interested in exploring these new platforms.

Adapting SIP for application server requirements in 3G networks

The IP Multimedia Subsystem Service Control (ISC) protocol has been adopted by the 3rd Generation Partnership Project (3GPP) in Revision 5 for all signaling in a 3G IP Multimedia Subsystem (IMS) network. While the core protocol is essentially the Session Initiation Protocol (SIP) with extensions, 3GPP has adapted many of the functional elements in slightly different ways. The distinction of the roles (the user agent client [UAC], user agent server [UAS], proxy, redirect, and registrar), as defined in RFC 3261, blurs in the 3G architecture, giving way to more generalized SIP entities such as the proxy, interrogating, and serving call session control functions (P-CSCF, I-CSCF, and S-CSCF) and the SIP application server (AS). In this paper, we suggest that neither of the standard SIP entities, back-to-back user agent (B2BUA) nor proxy, meets the IMS needs of having the SIP AS maintain complete control over the session. Rather, a blend of these two functions is required for a certain class of applications. Using a new abstraction called the pseudo∗∗∗dialog, we show how to augment a B2BUA to provide both the proxy and B2BUA modes of service on a per-call basis.