Augmenting OMG traders to handle service composition

Venu Vasudevan
Object Services and Consulting Inc.
 
September 15, 1998

Problem description

Much the same way as the WWW  enabled an explosion of globally available documents, it is now enabling an explosion of globally distributed, widely available services.  The ability to access these services via object frameworks such as CORBA and Java, makes it possible to build worldwide distributed object systems that are configured from globally distributed service objects.  The ability to use any object on the internet offers the possibility of reduced engineering effort as well as increased resilience in developing internet-based OSA applications. Such a worldwide OSA architecture also poses a number of scaling problems, a significant one being that of service discovery.  Given the large population of internet-accessible service objects, a large number of service instances will be available that perform equivalent functions. However, these service instances  may differ in significant ways, such as geographic location, content pedigree, mirroring and replication, QoS and other gurantees, data quality, protocols and delivery mechanisms, and payment schemes, to name a few.  From the point of view of any object that is part of an OSA application, the service discovery problem is one of finding the service instances that will provide it the appropriate gurantees, and choosing the best instance for its needs. From an overall application perspective, it is desirable to optimize each binding in this way, ensure that the bindings stay optimized under changing network and traffic conditions, and being able to trigger a rediscovery process when the environmental changes are significant.
 
OSA (as well as internet and agent) architectures have proposed trading services (and traders as objects that support the trading facility) that begin to address service discovery. Server objects (or other objects acting on their behalf) advertise or export their service offers to traders in terms of the  invocation interface and instance-specific properties of the service instance. Client objects invoke traders to discover or import service offers matching a given service interface, as well as the desired instance properties. This model of trading is quite similar to the use of  search engines in information retrieval, in that the matchmaking is done against static attributes of the entity being searched for.

The search engine model of document discovery offers a good starting point for a trading architecture for service discovery, but is not without drawbacks. The drawbacks of current trader architectures come from the fact that they are impoverished search engines, and more importantly from the differences between the goals of document discovery and service discovery.   In service discovery, we are trying to establish a satisfactory end-to-end, persistent and long-lived interaction client and service objects. Furthermore, unlike document objects, both client and service objects (and the bindind in between) are active, exhibit time-variant behavior, and are potentially configurable. An example of configuring service properties directly and indirectly is that of changing the bandwidth property of a video service by choosing a particular protocol, or by changing the making the transmitted video monochromatic. For a trader to explore the different indirect ways to configure a particular service property,  it must understand the service configuration space and be able take configured service behavior into account in matchmaking. This might involve reformulating a trader query  to other semantically equivalent queries in the configurable property space . Another variable that the trader needs to take into account in matchmaking is the commitment a service makes to delivering the advertised properties. The commitment a service can make to whether a particular property (e.g reduced jitter in delivered video) is delivered to the end-user, is dependent on both the service and mediating entities (e.g  the network). Increased commitment can be achieved by either configuring the service, or composing the service with monitoring, translation and other function which change the properties (and commitment) of the delivered function. Furthermore, guranteeing an end-to-end property may require hooking into the client object to assemble a feedback loop (e.g multimedia feedback loops [Cowa96]) , something that is not modelled in current traders that view the client as a black-box.

This paper explores bacwkard compatible augmentations that can be made to the  OMG trading model to build a smarter trader. Specifically desirable qualities include being able to  reformulate queries to more easily solvable ones, awareness of the configurability of service objects and its effect on service properties, the ability to  compose services with other behaviors to reconcile interoperability problems, and the ability to provide continuous and end-to-end gurantees.  Since we are attempting to enrich the OMG trading framework in a backward compatible fashion, a brief description of the current OMG trading framework is included. More detail of OMG and OMG-like traders can be obtained in a companion report [Venu98]

OMG Trading Model Augmentations

The OMG Trading Framework in Brief

In describing the model of compositional trading, we conform to the framework in which the OMG/ODP traders are described. In the OMG/ODP case, the trading model consists of :  service type model, service offers, and service requests. The service type model specifies what a trader needs to know about a service type to be able to trade with instances of this type. The OMG trader models a   service type is as offering an interface and a collection of properties. The schema for these properties (i.e the property name and the domain or its values) is part of the service type specification. Auxillary aspects of service properties such as whether they are editable and whether they are mandatory to specify in all advertisements, are also part of the trading service type model. Individual service offers  conform to the service type specification, and define property values specific to a service instance. Examples of service instance properties include attributes  such as the bit-rate of a video service, and  the languages supported by a document service. Service requests are client queries to the trader, stated as the property predicates the client would desire in a service of a certain interface type. The OMG service request model also allows the specification of policies (that control query propogation) and preferences (that control rank ordering, query result cardinality etc.). This description of the OMG trading model is not complete, and is provided because we reuse the type model, offer model and request model framework that is used by the OMG trader. In the description below, we discuss why the OMG model is not adequate for compositional trading, and additions to it that would facilitate such trading.

Service Type Model

The passive catalog model supported by the OMG trading service models neither the configurability nor the composability of service objects. This is adequate for the exact  matching clients to single, perfectly matching service instances, but insufficient to actively compose multiple service objects to satisfy a client request. To support composition, we therefore  augment the OMG service type model with  configuration and composition models.

The default behavior of service instances may be captured by a property vector with discrete values, but services can frequently be configured to support a range of property values. The service configuration model captures the extent to which services can be configured and the mechanisms for configuring them. In the simple case, there might be a set of operations that directly manipulate a certain property of the service. Realistically however, the property space is not orthogonal, and changing a particular property affects others. Thus, the configuration model needs to capture side-effects and dependencies between different configuration actions. Manipulating the properties of service composites (i.e. services that use other services) requires capturing the relationship between the properties of a used service, and that of the service that uses it.

The composition model specifies  services as adaptors of other services (or data objects produced by other services). While the OMG trading model captures services  characteristics, but not as adapters (wrappers) of services that modify the properties of the wrapped service. This  allows the trader to assemble service composites with desired aggregate properties.   The behavioral specification of services as adaptors is dependent on both the behavior a  service is providing and the manner in which it is implemented.  Two document distillers may both reduce the bandwidth needed to trasmit a document, but one that does so by reducing the images in the document will have different auxillary properties than one that removes irrelevant textual information. The composition model is therefore split between the type model and the service offer model,with implementation specific properties of the adaptor specified in the latter. In both cases, the composition model is further partitioned into specifications for behavior and docking. The former specifies what an adaptor does, while the latter helps the trader determine where it can be placed in a binding.

Configuration Model

The OMG/ODP trading model represents properties of a service type as static and non-configurable. This can lead to false matches where the commitment of a service to providing a particular property value is misinterpreted,  and false mismatches where one ignores the fact that a service can be configured to match a client's request even if it does not do so with the default parameters advertised in a service offer.  Metaproperties are used as a general mechanism in the compositional trader, to describe these second order aspects of the service advertisement. While some metaproperties may be domain or application specific, we discuss a few that seem to be broadly useful, and therefore treated as a core part of the trader vocabulary.

Commitment, negotiability and influences  appear to be broadly useful metaproperties for almost any property on a service instance. The comitment metaproperty (also called level of service in QoS literature [Chat97a], [Yead96]) indicates the commitment made by a service instance to a specific property value. A video server may gurantee to a constant bit-rate output. In this case, the commitment meta-property for this service advertisement (or a subset thereof) has a value guranteed. Clients that bind to this service instance then know that the bit-rate is guranteed by the service.  A metaproperty such as commitment is equally useful outside the multimedia QoS domain. A web annotation service (i.e one that serves annotations made by third parties to web documents) may choose to make a best-effort commitment to the language in which the annotations are recorded. This would mean that the document reader may occasionally  be confronted with german annotations on an english document. In a number of situations, a service instance provides a default property value for some property, but the property is directly configurable or negotiable. In such cases,  the negotiability metaproperty records that a property is negotiable, perhaps upper and lower bounds of negotiation and details of the negotiation protocol. The property space is not an orthogonal one, and modifying the value of one property can have side-effects on another. Reducing the color in an image or a video, for example, reduces the bandwidth required to transmit it. Looked at in reverse, reducing the color depth in an image indirectly configures the bandwidth property of an image or video.   The influences metaproperty is used to capture dependencies between properties within a service schema.Traders can use property influence information to reformulate service requests (e.g ones with predicates that involve non-configurable properties), or to compare direct and indirect configuration approaches to satisfy a service request.
 
Complex services that depend on other service instances can be configured both directly (as above) and transitively.  Transitive configuration means that a service is configured by configuring the services it directly or indirectly uses. A system state monitoring service that provides high-level state information about nodes in a system, uses one of a number of telemetry services to receive low-level, continuous measurement information about these devices. The properties of a state monitoring service instances are then a function of the telemetry service instance (and implementation) that it uses.  A state monitoring service can be transitively configured by using a telemetry service with differing QoS or other properties (more accurate, more reliable, more timely for certain kinds of information etc.).  The property aggregation model specifies the service dependency graph specifying the transitive dependency between the service type we are interested in, and the services it uses.  This structural model is augmented with property expressions that relate property values of the service in terms of properties of the services it depends on.

Composition Model

Adaptors may modify service behavior along three dimensions : interface, properties and metaproperties.  Interface reconcilers [Nimble,Matz96, Seni96] adapt a service to provide a different interface than what it natively provides. [Katz] describes some uses for interface adaptation in mobile computing, and [Senigvonse] in software versioning.  Instances of interface adaptors specialize in the source interface they can adapt from, and the destination interface they can adapt to.  Property adaptors adjust the property values of a delivered service without changing its interface. Format translators, protocol gateways [McCanne] , information distillers [Bick97], text-to-speech transformers[Ye96] are some examples of property adaptors that adapt particular properties of the delivered service by transforming the content. However, property adaptors are not necessarily content transformers. An availability adaptor may transparently allow access to two different instances of the same service, giving the end client the illusion of a single service instance with higher availability.  Property adapters specialize in terms of the property they adapt, and the service interfaces they apply to. The side-effects of a property adaptor are typically a property of its implementation, and are therefore specified in the service offer model. Metaproperty adaptors  don't change the property value of a particular property, but can increase the certainty that the property value will be maintained. A feedback component may act as a property stabilizer, damping the range within which the property may vary and therefore increasing the chances that it will stay within bounds. [Cowa95] provides a number of examples of software feedback components that specialize to stabilize particular properties of a multimedia service. Property cross-checkers will examine the results of a service, and may discard parts of the result that do not posess a certain property. An english  language filter increases the probability that the  document produced by a service is in english only, by removing non-english phrases from it.

Given that we know the adaptor behaviors of services, the placement of adaptors in the binding is driven by soft matchmaking. Given that a perfect match is absent, the soft matchmaking algorithm points out which properties are the most mismatched, and what are the closest matching service instances.  The main cause of the mismatch determines which adaptors are inserted into the binding.  A common  approach is to specify distance functions that measure the distance between the properties of a service advertisement and those specified by a client request. In QoS where properties are continuous, both provided and required properties are more naturally specified as regions with upper and lower bounds.  Individual property-specific distance functions are aggregated to a distance metric between the service instance and the client request. The compositional matchmaker picks certain service instances that are fairly close in aggregate, and uses property and metaproperty adaptors that reduce the distance measure further. If no services of a matching interface can be made to match, the matchmaker resorts to using interface adaptors on other types of service instances and then performs the above step.

To support composition, the OMG trading model has first to support soft matchmaking. That means support for property ranges (and potentially other probabilistic and statistical techniques for specifying property values), the ability for matchmakers to support different aggregate and per property distance functions, and the ability for clients to choose the distance function and the weighting on a per request basis, and a matchmaking function that returns inexact matches based on some distance constraints. Some of this has been pointed out in [Popi96].  To additionally support composition, the matchmaker must not only return the best matches, but also some metrics of the major cause of mismatch. This information determines the kind of  property adaptation that should take place. Finally, adaptors themselves need to be specified in terms of preconditions to their operation, their adaptation behavior and side-effects.
 
The docking specification of a service type determines both ordering (where the service instance is placed), containment (whether the adaptor is free standing or hosted) and binding (how the adaptor is bound into the adaptor chain). Adaptors may be placed in-line or in the feedback portion of a binding. In some cases, the kind of property being adapted places implicitly specifies placement constraints. For example,  adaptors for end-to-end properties like encryption need to be embedded in the data source (and compensated by a decryptor at the client side). Client-side properties such as the format in which information is recieved can be placed anywhere in-line. An ordering of  in-line adaptors can be inferred based on data flow constraints. If an adaptor needs its inputs to have property P, then it is placed after the adaptor that gurantees the property P.  Pluggable (or extensible) adaptors are frequently architected as container-blade architectures, where the blades collectively provide the  'bag of tricks'   Containers may support a common intermediate format for a particular class of blades, generic administrative functions for extending behavior (e.g adding, removing blades),  control strategies for the selection, invocation and composition of blades, and reassembly of transformed information into an outgoing object. Pythia and Digestor  provide some examples of container-blade adaptors for web services implmented using proxy servers. Video transcoders [Amir96] that can be extended to translate between various delivery protocols are architected as containers that accept encode and decode blades for each added protocol.  Along the containment dimensions, adaptors are classified as containers or blades, and explicit compatability relationships are specified between blade and container types. The placement of a blade is then determined by where a  compatible, in-line container is placed in the binding.

Service Offer Model

 In the OMG service offer model, service advertisements specify the supported interface and provide values for properties that are mandated by the service type model for instances of this type. For services that are adaptors, this service offer model needs to be augmented to specify the specifics of an adaptor implementation. In many ways, the service type model for adaptors describes the qualitative effect of the adaptor, but the precise adaptor  behavior is a function of the implementation and is therefore part of the service offer. For example, the adaptor specification for all document distiller  objects might specify that they reduce the size (and therfore the required bandwidth) of the input object. The extent of size reduction depends on the distillation algorithm (e.g does the distiller remove images or text, or does it summarize each paragraph to a fixed size etc.). The service offer adaptor specification refines its service type specification while conforming to it. Conformance means that the refines the adaptor behavior specified as part of the type without violating it. If the type specification of distiller objects says that they reduce bandwidth, the offer specification must not increase the bandwidth instead.

Qualitative models of efficiency and information loss are useful to traders in optimizing the composition. Efficiency metrics  indicate the time overhead added by composition, while information loss metrics provide an indication of how much information is lost by the adaptors in the process of composition. Adaptor efficiency is frequently a function of whether the adaptor needs to translate the object into an intermediate form to operate on it.  Information loss is a function of whether the adaptor elides or transforms the input object. Elision (e.g removal of images from a document) is irreversible, while transformation (e.g reducing image size) is potentially reversible. Both approaches may offer bandwidth reduction, but the image reduction implementation loses less information. Translation type, intermediate format and translation operation are three properties that provide a domain-neutral specification of efficiency and information loss which can be refined to particular domains. Translation type can be either syntactic or semantic depending on whether the adaptor understands the semantics of the content it adapts, or just the structure. Structure-based adaptors tend to be faster but with greater information loss.  Greater distance between the required intermediate format and the format of the incoming object makes it likely that the adaptation is going to take longer. The translation operation may be universal or selective. In the first case, the operation is applied to all parts of the input object, and therefore likely to be less efficient. In the latter case, it is applied to selected subobjects within the composite input object (e.g an image transformer operates only on the GIF images in the document, not the text).

Client Object Model

In the OMG trading model, the relationship between the trading client and the trader is a memoryless client-server relationship. The client is an opaque object that invokes a query on the trader. Other than the query, the trader has no ability to query or manipulate the client in a peer-to-peer fashion. Additionally, the trader is memoryless in that no history of queries from a single client is maintained at the trader. Both these assumptions need to be relaxed for applications that require iterative composition.

QoS applications use composition to make end-to-end property gurantees. Making such a gurantee requires composing configuring the two ends (client and server) as well as composing the core service with auxillary services. The use of software feedback loops for bandwidth adaption [Cowa95], for example, requires the feedback component to hook-in to the client object, and potentially (re)configure it at runtime. The object model underlying the OMG audio-video service proposal [AVSS97] also presumes knowledge and access to the client device API (via a controller object).

Iterative construction of a composite binding (by binding and subsequently rebinding) requires the trader to not only manipulate the client object, but to have a model of stateful interactions with the client (even if it doesn't maintain the state internally). A trader's choice of a new matching service instance may depend on the kinds of failures encountered by the client in the previous binding set up by the trader. Additionally, setting up a semantically correct binding might involve recovering some or all of the state information from a previous binding. Again, while the trader does not need to perform the binding recovery operation, it needs to understand what binding recovery operations need to be performed, so that clients do not need to understand the intricacies of binding management.

Augmentations required to the trading model to provide end-to-end gurantees are not drastic. The notion of a peer-to-peer architecture where the client object API is also exposed is already part of other OMG service proposals [AVSS97]. However, adding stateful binding management capabilities to the trading model is a significant step, although one that has been taken by the RM-ODP archiecture, which is closely related to the OMA architecture.

Related Work

Work related to augmented tradng  falls into one of several categories:

References


This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies.
Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this document.