Suggestion: Linked data representation of USDL

• by Carlos Pedrinaci (OU) and Torsten Leidig (SAP)
• More info: USDL - Linked Data

Suggestion: Inclusion of Service Offers

• by Maciej Zaremba (DERI)

In our opinion, the notion of service offer is not currently sufficiently addressed in the USDL. An offer (and likewise service offer) has a well-defined business meaning and it should include at least the following four conditions (G.H. Treitel, “The Law of Contract", Sweet & Maxwell, 2003): delivery date, price, terms of payment and fair description of an item or service. Service consumer can accept an offer and once service provider approves service consumer's decision then legally binding contract is formed.

Assumption that concrete values of service parameters like price, availability and delivery date are statically described in a service descriptions is unrealistic for certain use-cases (e.g., parcel shipping, car insurance, bank loan, etc.). On the other hand, it is an obligation of the service provider to make service offer information available to the service consumer before committing any real world effects (e.g., charging customer's credit card).

From the service consumer perspective, it is much more valuable to operate on concrete, consumable service offers (e.g., FedEx Express, 100 EUR, 5kg package, 10x20x40cm, from Germany to Ireland, delivery within one day) rather than to operate on abstract service descriptions (e.g., FedEx shipping service, ships packages up to 500 kg, between various source and target destinations, there is a price and there is a delivery date). Currently, available service descriptions require substantial manual work in order to move to the service offer level and do not sufficiently acknowledge distinction between different concreteness levels of service descriptions including special treatment of service offers.

Service offers are often request dependent and dynamic. Information such as service availability, price and delivery date are request dependent and are often generated in service provider's back-end system. They become part of the service offer description in the course of service matchmaking/configuration process what may require interaction with service safe operations (i.e., operation with no real world consequences) using service interface. Service offers are quantifiable artifacts suitable for objective ranking and making services truly comparable and tradable (what is the goal of USDL) in contrast to the abstract service descriptions. Service properties that make services comparable (e.g., price, delivery date, detailed properties of the service) are often not available in the abstract service descriptions.

Available service descriptions are often abstract due to: (1) large number of possible service offers, (2) privacy concerns - providers might not want to disclose details of their business (e.g., how is the service price calculated), and (3) maintaining business advantage - providers may use marketing terms in their service descriptions to entice service consumers (e.g., by describing a service as the cheapest service).

In our opinion USDL should support seamless transition between different concreteness levels of service descriptions. Currently, there is a number of relevant service description elements captured by the USDL, but some of the service properties cannot be easily modelled. In our opinion adding explicit ServiceOffer element to USDL Service Module and introducing different granularity levels in USDL Functional Module would make USDL applicable for describing highly configurable services. Herewith, we propose new USDL elements that will facilitate service offer modelling.

Service Module

---

In our opinion, it is important view service descriptions in terms of the service lifecycle. Service descriptions will have a varying level of concreteness depending on the stage of matchmaking/configuration. Initially, service descriptions will be more like a blueprint (class in OOP) of how to derive concrete service offers (objects in OOP). However, they will become much more concrete as service required parameters (e.g., customer address, age, driving experience in car insurance scenario) become available.

We propose to add the following attributes to the ServiceVariant:

- isConsumable indicates that complete information about the service has been provided and service can be directly consumed. For example, service description of FedEx overnight shipping for packages up to 50 kg is not directly consumable. Additional steps has to be performed in order to get to the consumable level of this service. FedEx overnight shipping from Dublin, Ireland to Berlin, Germany of the 5kg 10x20x30cm package for 120 EUR is an example of consumable service variant. At this level of concreteness, there is no more information that FedEx company can possibly provide and the service is ready to be consumed.

- hasParameters specifies all parameters that are used to describe given service. These parameters might have to be provided by the service consumer (input parameters) or by the service provider (output parameters). In the beginning, input and output parameters are typed (e.g., package weight is specified in kg) and they become concretised (e.g., package weight is 5kg) as service configuration process proceeds.

Pricing Module

---

Currently, in our opinion Pricing Module is particularly tailored towards static pricing plans that can be enumerated in service description. However, it does not support: (1) arbitrary pricing formulas and (2) price on demand. For example, we cannot say in the USDL that the price is calculated as: 0.2 * weight / dimensionalWeight. Regardless, of how realistic is this example, it should be possible to model it with the USDL. Currently, there is only ProportionalPriceLevel which is a multiplier for variables. Price provided on demand is another very important scenario that currently is not supported by the USDL. There is a number of reasons why service providers might not publish their prices statically or disclose formulas that allow to calculate their prices. These reasons include: (1) business sensitive character of service price, (2) high volatility of service price and (3) highly complex price calculation procedure (e.g., car insurance price is a subject of multi-level constraints dependent on statistical models).

In order to support these two important scenarios we propose the following new elements to the Pricing Module:

- PriceFormula allows to model price as an arbitrary expression. It contains requiredParameters that specify what parameters are used in order to calculate providedParameters (primarily the price, but possibly other parameters can be calculated along with the price). Expression defines an arbitrary formula that is used to calculate the price.

- PriceOnDemand is used to specify how the price can be fetched on-the-fly. Similarly to PriceFormula, it contains requiredParameters that specify what parameters are used in order to obtain providedParameters (primarily the price, but possibly other parameters can be calculated along with the price). InteractionProtocol is a reference to the interaction protocol from the Interaction Module. InteractionProtocol is used to dynamically obtain provided providedParameters (e.g., the price).

SLA Module

---

We propose similar extensions in SLA Module as in the Pricing Module. SLA attributes can be: (1) interdependent and (2) fetched on demand. We propose to use to introduce:

- AttributeFormula is used to derive/calculate the attribute by utilising required parameters. Expression specifies arbitrary formula used to calculate value of the attribute.

- AttributeOnDemand is used to dynamically obtain value of the attribute. InteractionProtocol is a reference to the interaction protocol from the Interaction Module. InteractionProtocol is used to dynamically obtain provided providedParameters (e.g., the price).

Suggestion: Identity and Privacy Management

• by Rubén Trapero and Yod Samuel Martín (UPM)

Service composition is a promising paradigm that allows non expert users to create and share their own services and content from the aggregation of existing ones. Service personalization is probably one of the most important features for consumers of composed services. However, customization implies accessing personal information (or identity information). This information may include personal data or user preferences (our favourite colour, our name or native language); however, more valuable personal attributes are dynamic and must be retrieved by analysing consumers’ behaviour (positioning or presence, etc.)

Furthermore, service compositions are inherently distributed, and thus some identity attributes must be shared with service providers. Something similar happens in the other way around, since some providers will offer resources for composition that include identity attributes, such as payment information. Identity resources provided by third party providers are out of the administrative domain of the platform provider. Furthermore, the laws of most countries with regard to privacy protection, state that users must be aware and give their consent about the usage of their personal information when this information is shared between different companies.

For the future it would also be quite interesting to refer identity and privacy concerns in order to support techniques of identity and privacy management that may be applied in service delivery platforms. These aspects might be included in what is currently called legal module, although we see that this module is more related to rights and obligations mainly referred to licensing issues; another option would be including an identity management module. In any case, we expect they would provide higher level identity and privacy management attributes, and refer for the details to different identity management and privacy policy documents described in the usual languages for these domains.

In these sense, different types of languages and tools exist to manage privacy policies. In 1997, the W3C created P3P (Platform for Privacy Preferences Project) to represent privacy policies of a Web Site by using XML. W3C did also develope a language to exchange P3P preferences (APPEL - A P3P Preference Exchange Language), in order to be able to represent user’s privacy preferences. Another W3C specification is WS-Policy that allows defining security policies, quality of service, etc. In 2000 CPExchange was created in order to make business relationships between enterprises easier in what privacy policies is concerned. Companies also created their own languages to define internal policies. For instance, IBM designed EPAL (Enterprise Privacy Authorization Languages) in 2003. More recently, XACML was created by an organization consortium to express both security and privacy.

Review: Overall Review by Attensity

Overall, the specification is of a remarkable quality. Minor questions and quibbles follow. All comments are based on M5.

General remarks

• All class diagrams are of a low graphical quality, some of them partially unreadable. Please re-export them as vector graphics.

Overview

Probably out of scope at least for the initial version: Specification of services that use (sub-)services from a different vendor. It might make sense to have service "templates" that can be instantiated by different providers so that you as the consumer can pick and choose. (note to self: check if this is covered elsewhere)

3.2.2.2 Cognitive Sufficiency

This section appears to address two separate areas: human interpretation (first paragraph) and the granularity of the service descriptions (second and third paragraph). I don't see how the latter is related to cognizance, maybe this should be clarified.

[34] states that "A technique should provide a sufficient cognition of a model such that the need for fundamentel business process execution assumptions is eliminated." It might make sense to stress that the aim is to reduce the need for assumptions.

Functional Module

3.1 Function

names is a set of names. Why isn't one name sufficient? (same in 3.2 and other specifications) Is it for supporting several languages, or are there other aspects?

Technical Module

General: Is it possible to have different SLAs for different implementations? For example, a simple REST interface might guarantee higher throughput than a SOAP Web Service.

3.1 Interface

According to the specification, an interface need not have any accessProfiles, implementationSpecifications, or descriptions. Thus, you can have interfaces you don't know anything about. Is that intentional?

3.4 OperationBasedInterfaceElementType

What is the purpose of InFault? When should it be used?

Service Level (SLA) Module

4.9 TimePerformanceType

What is the meaning and purpose of UptimeAbsolute?

4.12 SecurityGoal/4.13 SecurityRequirementLevel

This concept is so vague that it is essentially useless. What does it mean for a security requirement to be of level medium? It is probably impossible to specify these things generally (i.e., without resorting to free text), so it might make sense to use the given structure as a general hint, but demand a mandatory explanation field that goes into more detail.

Foundation Module

Figure 2: There's a relation pointing to ContactProfile that comes from nowhere.

3.1.14 Expression/3.1.15 Condition

The use of expressions and conditions is not really clear. Both expressions and conditions must have means of accessing information from the outside, but it isn't clear how that can be achieved. Are they meant to be evaluated automatically, or are they just a semi-formal specification for human consumption?

3.2.15 ElectronicAddressRegion

addressTemplate: How are ranges to be intepreted? What IP addresses are included in the range 192.168.2.15-192.168.3.35? In any event, the CIDR notation should probably be supported (e.g., 192.168.2.0/25).

Participants Module

2.1 Introduction to the Participants Module

I do not understand the role of the Service Channel Maker. Is it the consumer's ISP? If not, what else?

Feedback: Functional Module

• by Torsten Leidig (SAP)

• we do not necessarily need the functional module. Why can DHL Express with 3 actions (airfreight, seafreight, trucking) not also be modelled as composition with three services

• the technial module could link operations directly to services then

• this would make the meta-model of USDL simpler and would leave less modeling options for the modeler

Feedback: Pricing Module

• Tom Kiemes (SAP): the reference "multiplier" from PriceComponent to VariableDeclaration must have the cardinality 1..*. Otherwise multi-dimensional price metrics which are actually foreseen in USDL, are not completely representable. Currently we cannot refer to several variable which determine the price of a price component. Example: if the price of a shipment depends on weight and distance, then two metrics can be used. However, the variables which have to be multiplied with the price of the corresponding prive levels, cannot be specified correctly and completely in the model. Human interpretation is required to read that out of the model

• Lukas Barton (HP): the spec should contain examples of how to use pricing module, e.g. "create a PriceComponent for dynamic option with AbsolutePriceLevel with absoluteAmount = 5 and a PriceMetric „GB” with factor = 1, You can link the PriceComponent to a Function which represents the number of GBs"

Feedback: Foundation

• Thorsten Sandfuchs (SAP): why does a person not contain gender information? ==> should be added to next version