State of the art

Le Duc Bao

February 29, 2008

This document presents the research and development state of the subject mon-
itoring composition of services.

1 Introduction:
In recent years, the rising of Service Oriented Computing brings researchers
to new challenges diversity from message exchange format to composition of
services, from infrastructure to quality of services. This emerging approach
addresses the requirements of loosely coupled, standards-based, and protocol-
independent distributed computing. It requires functional as well as non-functional
characteristics. Functional characteristics include operational characteristics
that dene the overall behavior of the service while non-functional character-
istics include service availability, reliability, scalability, security, authorization,
authentication, integrity, performance characteristics.
In the SOA paradigm, being the atomic unit, the service is self-contained soft-
ware module that performs a single business task. It is described in terms
of a service description language, e.g., WSDL. The composition of services is
integration of heterogeneous services to conduct the business processes. It is
orchestrated in a business process language which focuses in the functional as-
pect of business requirements. The lack of non-functional description in the
language is the separation of concerns which keeps its simplicity. A runtime
monitoring, being used to observe system healthy, to serve a automated process
or to evaluate business contract between partners, is required to ll this gap[8].

Monitoring problem
In high-level architecture of monitoring composition of services (gure 1), the
composed services is dened in business process modeling language (BPML),
e.g., BPEL, which allows one to tailor the distributed services. It is executed
by the process execution engine (PEE), e.g., ActiveBPEL[12], which invokes the
distributed services specied in the description of composition and follows the
dened business process. The monitoring service, concentrates in the control
aspect of SOA, consists of the monitoring requirement and monitoring engine.
The monitoring language allows one to represent the monitoring requirement
which is a part of the business contract. Monitoring requirements, such as QoS

1
 Figure 1: High level architecture

behaviors (maximum response time, average response, quality of the result,...),

recovery strategies (how the system reacts whenever a requirement is violated),
are specied in individual service, or group of composed services, or the whole
composition dened in BPML. It might provide facilities to manipulate data
from various sources (internal, external data, historical data from previous pro-
cess instances) in dierent levels (message level, process level, system level).
The monitoring engine, takes the monitoring requirement dened in monitoring
language as input, is capable to observe the process execution engine, to collect
runtime and quantitative data, to evaluate the monitoring requirements, and
to store historical/statistical data. It might interact with the process execution
engine to apply reactions in the case of violation of monitoring requirement.
The above elements divide the monitoring problem into dierent aspects. In this
study, we rst discuss about the monitoring language and monitoring engine.
We dene the criteria in order to evaluate a monitoring system dedicated to
composition of services.

Criteria
1. Separation of concerns and non-intrusiveness : the monitoring language
should be well separated from functional (what composition does) and
non-functional (how composition works) aspects (separation of concerns).
Further, the monitoring engine should be independent from the BPM ex-
ecution engines (levels of abstraction), from the contract denitions.
2. Expressiveness : it allows to monitor the business contract in dierent
levels[1]. It also has sensors to capture dierent events and characteris-
tics (functional/non-functional/temporal) for any need of the monitoring
requirements.
3. Autonomic capacity : it should provide a (intelligent) mechanism, a strat-
egy to feedback/react the process execution engine or negotiate with other
participants in runtime. It works in the way self-conguration, self-adaptation
and self-healing, self-monitoring and self-tuning, and so on, often under
the ag of self-*.

2
 Figure 2: The activity diagram of TBS

Additionally, the following describes other low-priority criteria:

1. Extensibility : in the heterogeneous environment, the monitoring should be
capable to adapt dierent aspects of monitoring requirement such as multi-
participant, message types (sync, async), message-level/process level.
2. Eectivity : an enterprise service retrieves usually data from dierent
sources, manipulates by thousands customers in the same time with dier-
ent contracts. Therefore, the monitoring should less eect the performance
of enterprise system as much as possible, e.g a mechanism to optimize run-
time observation.
In this study, those criteria are used to evaluate and compare various solutions
recently proposed by both academical and industrial researches. The section 2
describes a case study of composition of services. The next sections introduce
the runtime monitoring by P. Traverso et al [2], Dynamo by L. Baresi et al[3, 4],
A Framework for Requirements Monitoring by K. Mahbub[?], policy attachment
to BPEL by A. Char[?]. The last section analyzes and summarizes those work.

2 Case study
This case study is extracted from[9] with some minor modication. Consider
a Web-based travel booking system (TBS) that acts as a broker oering its
customers the ability to book all aspects of a trip. The workow of TBS in-
cludes credit validation, ight/hotel/car reservation, and communication with
the client. Customers can submit data about their desired travel plans and re-
ceive either a conrmation number or a failure message depending on whether
the travel arrangements have been made successfully.
The activity diagram in gure 2 shows high-level steps that are executed during
the travel booking process. To fulll its business goal, TBS needs to interact
with several partners: FlightReservationService, which books a ight, Hotel-
ReservationService, which reserves a hotel room, CarReservationService, which

3
makes a car reservation, CreditCardCheckingService, which validates the cus-
tomer's credit card data, and the CustomerService which enables to get travel
data, inform and conrm booking status to customer. In a typical scenario, an
Internet customer begins an interaction with TBS by entering data for his/her
travel arrangements. The system then invokes recursively three reservations,
for the car, hotel and ight for each vacation stage. If all of the reservations
are completed successfully, it invokes the CreditCardCheckingService. If the
credit card is valid, then a conrmation number is generated and returned to
the customer.
The table 1 shows requirements for TBS

Id Requirement
R1 If the execution time from getTravelData to the success of Credit
Card Checking Service (CCCS) is greater than 40 seconds then
alert to admin.
R2 If average execution time from getTravelData to the success of
CCCS is greater than 30 seconds then stop the TBS process and
call the reporting service.
R3 The credit service starts if and only if there is at least one reser-
vation service (ight, hotel or car) successfully complete.

Table 1: Monitoring requirements for TBS.

Noted that the R1 & R2 are non-functional requirements while R3 is a functional

requirement.

3 P. Traverso et al
This approach[2, 14] proposes a solution to monitor web services implemented in
BPEL. The monitoring language is the Runtime Monitor specication Language
(RTML) solidly based on Past Linear Temporal Logics (LTL). The architecture
supports message-level monitoring.

Monitoring language: The RTML allows to describe monitoring require-

ments in three steps: specify the events that are relevant for the evolution of
monitors, describe instance monitors on top of events, and describe process mon-
itors on top of instance monitors. The events include start, end, and the input,
output of messages related to each process instance. The facilities such as build-
in functions (count, time, avg, sum, cause, msg ), logic/relational/mathematical
operators, and time-related properties (old value, status of previous events...)
allow to express exible monitoring expressions. The language supports also to
use variables.
The example below shows how to describe monitoring constraints for the re-
quirements in the table 1 in the case study:

4
 ˆ R1:time(cause(check_credit.state = SUCC) S msg(get_travel_data.input
= startBooking)) > 40
ˆ R2:avrg (time(cause(check_credit.state = SUCC) S msg(get_travel_data.input
= startBooking))) > 30
msg (check_credit.input = startPayment) implies O (cause(ight_reservation.state
ˆ R3:
= SUCC)) | O (cause(hotel_reservation.state = SUCC)) | O (cause(car_reservation.state
= SUCC))
Denoted that the "cause(link.var = val)" means all events that cause variable
var of BPEL process link to assume value val. This language does not allow to
express the reaction (then clause) when the monitoring expression is reached.

Monitoring engine: The architecture (gure 3) consists of several compo-

nents: the monitor inventory contains all the monitors deployed in the engine;
the monitor instances is the set of instances of there monitors that are currently
in execution; the Runtime monitor (RTM) is responsible to support life-cycle
of monitor instances by the monitor handlers; the mediator allows RTM to
interact with process execution engine; and the admin console allows to con-
trol monitor requirements and expose monitor results. The RTM supports the
message-level monitoring which observe the execution of single instance of a
BPEL process and the process-level monitoring which aggregates information
on all instances of a given process and provides historical/statistical data. The
monitoring expressions are automatically translated into code, which can be
deployed at runtime, for the monitor inventory. The monitor engine can issue
an alert when a monitoring condition is reached/violated.

Discussion: This approach allows for a clear separation of the service business
logic from the monitoring functionalities. The mediator separate the monitoring
architecture and process execution engine. Further, it provides monitoring in
message-level with a set of events, runtime properties and statistical properties.
This approach also presents some drawbacks such as the small set of build-in
functions is not extensible and can be dicult to express all situations of real
business requirements. It lacks the autonomic capacity and the extensibility.

4 L. Baresi et al
The approach[3] proposes two Domain Specic Languages (DSL) for the de-
nition of constraints (WSCol) and recovery strategies (WSRel) to express the
monitoring requirement and a monitoring engine which is an AOP-based imple-
mented, a part of Dynamo project[6], as an extension for ActiveBPEL[12].

Monitoring language: The constraint language WSCol, dedicated to dene

constraints on the process activities, allows to specify pre-, post-conditions and

5
Figure 3: Traverso's Active BPEL engine extended with the runtime monitor
environment

invariant, which introduces in the Design by Contract concept[13], over individ-

ual activity like invoke, receive and pick of a service. WSCol consists of language
specic constructs for data collection and data analysis. Data collection obtains
properties that belong to persistent state of executing processes (internal vari-
ables), data from embedded probes (external variables), and historical data
from previous execution cycles. Data analysis supplies boolean operators, rela-
tional operators; mathematical operator and several predened functions such
as forall, exists, max, min, avg, sum, product. It also provides programmable
constructs like let and if statements. WSCol allows to specify process locations,
where we want a certain properties to be veried, by XPath. Further, the mon-
itoring parameters, such as priority, validity, and trusted providers, attached in
each monitoring expression permit runtime reconguration.
The recovery language WSRel, dedicated to recovery strategies that might be
executed when constraints are violated, allows to dene the reaction to anoma-
lies by supplementing the process with self-healing capacities. WSRel provides a
set of command to interact with the process execution engine such as ignore, no-
tify, halt, call, callback, retry, rebind, changMonitorRules, changProcessParams.
WSRel scope is the process instances that belong to process denition for which
they supervision rules are created. It adapts the ECA rule paradigm to express
the recovery when certain rules are violated.
The example below shows how to describe monitoring constraints for the re-
quirements in the table 1 in the case study. The language does not directly
support to express monitoring expression for a group of service, it should use
the historical data and variable denition to accomplish those requirements.
Assumption that transition time between two services of a composition is zero,

6
we dene:

ˆ R1: post-condition :
let $t_get_tra_da = retrieve (processID, userID, instanceID, 0, get_travel_data/location,
$response_time, 1);
let $t_i_res = retrieve (processID, userID, instanceID, 0, ight_reservation/location,
$response_time, 1);
let $t_hol_res = retrieve (processID, userID, instanceID, 0, hotel_reservation/location,
$response_time, 1);
let $t_car_res = retrieve (processID, userID, instanceID, 0, car_reservation/location,
$response_time, 1);
let $t_chk_crd = retrieve (processID, userID, instanceID, 0, check_credit/location,
$response_time, 1);
$t_get_tra_da + max($t_i_res, $t_hol_res, $t_car_res) + $t_chk_crd
> 40;
recovery strategy : notify (notify_message, email);
ˆ R2: post condition : By the same way, replacing the last parameter of
retrieve function by a number of recent invoking of services and using the
avg function (e.g. avg ($rt in retrieve(processID, userID, instanceID, 0,
check_credit/location, $response_time, 20); $rt)).
recovery strategy : halt() & call (reporting_service_XSDL);
ˆ R3: This requirement can be done by using the dynamic invoker to retrieve
internal variable of BPEL process.

Where retrieve is the build-in function of data collection, $response_time is the

internal variable. In R1, the rst ve lines set retrieved data into a variable
while the last line presents observation condition. In R2, in avg function, 20
indicates the number of recent service invokings.

Monitoring engine: The monitoring engine[4] consists of: the AOP module
which is injected in process execution engine (e.g. ActiveBPEL) allows to dene
certain point-cuts which can capture runtime data and interfere the process
execution engine; external services collect external information; the translator
which translates monitoring rules and recovery strategies to JBoss Rule Engine
and monitoring objects; the recovery manager manages recovery tasks; the rule
storage contains the rule knowledge bases; and the monitor manager which
connects previous elements.

Discussion: This work proposes a exible and programmable framework for

monitoring the composition of services by extending the design by contract
concept to work with the AOP module. It allows to observe wide-range runtime
characteristics due to the injection into process execution engine and extensible

7
data collector. The DSL is strength to express dierent monitoring aspects. The
recovery mechanism presents the rst step to autonomic system. Moreover, the
declarative language WSCol is transformable to XML based language which is
compliant the standard WS-Policy framework[5].
Beside that, there are several disadvantages. The recovery language is limited
to certain pre-dened functions which can not satisfy the self-adaptation due to
runtime faults or violation of monitoring expression[7]. Further, the AOE-based
module presents a higher inter-module dependency with the PEE.

5 ORQOS
TODO

6 ConFract
ConFract[16, 17] aims to specify and to verify properties between Fractal soft-
ware components through several types of contract. The system divides contrac-
tual process in three phases. In the specication phase, a contract specication
is incrementally dened in Component Constraint Language for Java (CCL-J)
based on component composition specication. In the static verication phase,
the system dynamically builds contracts from specications and updates them
according to the dynamic reconguration. The cloture of contracts occurs when
all participants of contract are assembled. Then the system turns to dynamic
verication phase where contracts are observed by a contracting mecanisme
which takes in charge of monitoring and evaluation them. Therefore, these con-
tracts are rst classes entities during assembly and execution time. In the case
if a contract is violated, the system allows to (re)negotiate, or to dynamically
recongure, or to deal with particular strategies.
CCL-J, inspired by OCL[18] and enhanced to adapt Fractal component model, is
a executable assertion language. A design by contract-like[13] language, it sup-
ports pre-condition, post-condition, invariant. It also supports both functional
and non-functional properties in a contract. Contracts are divided into three
types which correspond to Fractal model: interface contracts are established on
the connection between two components, internal and external composition con-
tracts are respectively served to internal and external behaviour of components.
Participants of contracts take dierent roles, such as guarantor, contributor,
beneciary.
Implementation of ConFract replies on Fractal implementation and has inte-
grated at Julia - a Fractal implementation. It employes mixins technology to
intervene Fractal controller and certain intercepters to capture runtime data
which need for contract evaluation.
The framework clearly separates between composition aspects and contract as-
pects of a component system, and between contract specication and contract
execution. Beside that, it has some shortcoming: it does not support historical

8
data; it does support component instance, but "component class"; and it does
not support inheritance and less reusable contract.

7 Service Level Agreements (SLAs)

SLAs is not a new concept. It is largely used in traditional telecommunication
domain as part of a contract between parties (service providers, service con-
sumers), where service levels are formally dened. Inspiring to SOA domain,
SLAs takes in account domain specic parameters to dynamically accomplish a
contract (or in demand contract).
Assumption that a service provider has a set of services which need apply a SLAs
for their customer, a SLA-enabled system should generally contains following
requirements to conduct a SLA between parties:

ˆ Expressivity: it requires a SLAs specication language to dene an agree-

ment between parties. An agreement contains information, measurable
and quantitive parameters of targeted services.

ˆ Negotiation: including protocols and algorithms to dynamically compose

an agreement.

ˆ Compilation: A SLAs relies generally to a service or a set of services. This

requirement aims to check consistency with dedicated services.

ˆ Execution: including contract monitoring and evaluation at execution

time.

There are many eort inspiring SLAs to SOA application in dierent levels:

ˆ WSOL

ˆ SWLA

ˆ SLAng

ˆ WS-Agreement

ˆ WS-Negotiation

8 Summary
Several researches have focused in the supervision of composed services while
concentrating in the separation of the functional and non-functional aspects.
The need of monitoring system, which adds non-functional services, is evident.
In both above studies, specic monitoring languages are dened to facilitate
the denition of non-functional business contract as well as to keep the BPML

9
clearly dedicated to process denition. Monitoring engines manage monitor-
ing requirements dened in monitoring language and cooperate with PEE to
accomplish its goals.
This two works do not attack elements of business process language such as
scopes and partners. The scope, provides a way to organize the activities within
the business process, is studied in [10]. The partner can be used to group certain
participants with the same policy. The Baresi's study provides a bit facilities
to work with such as priorities and trusted providers.
The monitoring language should be capable to work with runtime information
and to express business contracts. Runtime data varies from runtime process
events, runtime process properties, system properties that are required by the
business contract. The language should be exible to facilitate contract deni-
tions in dierent levels of complexity.
The monitoring engine should be well separated from the PEE. Architecturally,
it requires cooperation with the PEE in dierent levels in order to probe events,
non-functional data and to interfere business processes. Its coupling levels de-
pend on supports of the PEE. Moreover, the other concerns of the monitoring
engine, such as monitoring knowledge management, contract evaluation, and
external sensors, should be completely separated from PEE.

9 Annex 1 - Astro Project

Astro project([14], section 3) aims at supporting both the design time, i.e.,
on the o-line phase of the denition and specication of business processes,
and the run time, i.e., the execution of a business process, e.g., by monitoring
processes against business requirements. It implements a toolkit that extend
existing platforms (Eclipse, ActiveBPEL) for web service design, web service
execution with automated composition (ws-gen, ws-animator ), verication of
service composition (NuSMV ), and execution monitoring functionalities (ws-
mon, ws-console ).
1. ws-gen addresses to automatically compose concrete BPEL. It consists of
a back-end and a front-end. The back-end (gure 1) takes as input four
elements: BPELs abstract which dene composition scenario in BPEL;
WSDLs which dene basic services using in service composition; and the
choreographic le describing the connections between the composition's
partners, and a goal le dening the composition requirement. It rst
translates those elements into a form of state transition systems (.smv).
Then it applies "planning via model checking" to fulll the BPEL concrete.
The front-end, an Eclipse plugin, allows to manipulate the choreography
le.
2. ws-mon is responsible for generating Java code implements the monitors
and deploying them to the monitoring framework (see section 3). Like
ws-gen, it consists of a back-end and a front-end. The back-end (gure 2)
takes as input BPELs abstract, WSDLs, choreographic le and replace the

10
 Figure 4: ws-gen architecture

Figure 5: ws-mon architecture

goal le by the property le dening monitoring requirements to generates

the problem domain le .smv. Then it generates a set of Java classes that
would be deployed to monitoring framework (see section 3). The listing
1 shows property le for monitoring requirement of the case study. The
front-end, an Eclipse plugin, controls the monitor generation process.

3. ws-console is an extension of ActiveBPEL to present the status of the

monitors associated with each process instance.

4. ws-animator, an Eclipse plugin, plays the role actors to interact with the
composite process. It is useful at developing phase.

5. NuSMV1 is a verication tools using the model checking.

Listing 1: ws-mon properties corresponding to R1 and R2 of the case study

<monitor>
<p r o c e s s _ r e f d i r e c t i o n=" u s e s " p r o c e s s _ i d=" S t o r e " />
<property_type>i n s t a n c e</ property_type>
<property_name>R1</ property_name>
<p r o p e r t y _ s p e c>
time ( c a u s e ( c h e c k _ c r e d i t . s t a t e = SUCC) S
msg ( g e t _ t r a v e l _ d a t a . i n p u t=s t a r t B o o k i n g ) ) > 40
</ p r o p e r t y _ s p e c>
<p r o p e r t y _ d e s c r i p t i o n>s e e R1</ p r o p e r t y _ d e s c r i p t i o n>
<process_name>TBS</ process_name>
1 Astro released toolkit includes this tool, but no document introduces it in detail.

11
Figure 6: Example scenario of Composite Probes monitoring a clustered system.

</ p r o p e r t y>

<p r o p e r t y>
<property_type> c l a s s</ property_type>
<property_name>R2</ property_name>
<p r o p e r t y _ s p e c>
avg ( time ( c a u s e ( c h e c k _ c r e d i t . s t a t e = SUCC) S
msg ( g e t _ t r a v e l _ d a t a . i n p u t=s t a r t B o o k i n g ) ) ) > 30
</ p r o p e r t y _ s p e c>
<p r o p e r t y _ d e s c r i p t i o n>s e e R2</ p r o p e r t y _ d e s c r i p t i o n>
<process_name>TBS</ process_name>
</ p r o p e r t y>
</ monitor>

10 Annex 2 - Composite Probes

Composite Probes[11] (CPs) is a generic monitoring framework for large-scale,
distributed system. It allow one to build a hierarchical probe which is a com-
pleted, independent component. A probe, regarding as a tree, can contains
other sub-probes which are divided into basic probe and composite probe. A ba-
sic probe, being the a of the tree, is responsible for monitoring one or many
managed resources (e.g. CPU, memory, JVM, application, system, cluster,
workload...). A composite probe is responsible for managing basic probes or
other composite probes.
A probe has three main functions: aggregation, ltering and scheduling. Moni-
toring data, which is aggregated from one or many data sources by basic probes,
is transparently propagated upward to the higher-level probes. The control ow,

12
which is provided through external interfaces of a probe, is propagated down-
ward from to lower probes. A lter, being a sub-component of a probe, species
how the local data is processing for probe's outgoing data. It is useful for shar-
ing a sub-probe among its parents. A scheduler, being another sub-component
of a probe, triggers a process when a criterion, e.g. an interval, and threshold,
is reached.
Furthermore, CPs supports dierent communication protocols and management
protocols such as JMX, RMI.
CPs is implemented solidly based on Fractal model and CLIF moni-
toring framework.
CPs, an alternative solution behind at monitoring framework, facilitates col-
lecting and managing of probed data. It leaves the data manipulation due to
its exibility and extensibility.

References
[1] A. Beugnard, J.M. Jézéquel, N. Plouzeau, D. Watkins. Making Components
Contract Aware, Computer, July 1999

[2] F. Barbon, P. Traverso, M. Pistore, M. Trainotti. Run-Time Monitoring

of Instances and Classes of Web Service Compositions, Proceedings of
the IEEE International Conference on Web Services (ICWS'06), p.63-71,
September 18-22, 2006

[3] L. Baresi and S. Guinea. Dynamo, Self-healing BPEL processes with Dy-
namo and the JBoss rule engine, International workshop on Engineering of
software services for pervasive environments, p.11-20, 2007

[4] L. Baresi and S. Guinea. Towards Dynamic Monitoring of WS-BPEL Pro-

cesses. In 5th International Conference on Service Oriented Computing,
pages 269282, 2005.

[5] L. Baresi, S. Guinea, and P. Plebani. WS-Policy for service monitoring. In

C. Bussler and M.-C. Shan, editors, 6th VLDB Int'l Workshop on Tech-
nologies for E-Services, volume 3811 of LNCS, p.72-83. Springer, 2006.

[6] L. Baresi, S. Guinea. Dynamo and Self-Healing BPEL Compositions. Soft-

ware Engineering - Companion, 2007. ICSE 2007 Companion. 29th Inter-
national Conference on , vol., no., pp.69-70, 20-26 May 2007

[7] O. Moser, F. Rosenberg and S. Dustdar. Non-Intrusive Monitoring and

Service Adaption for WS-BPEL, WWW2008, April 2125, 2008, Beijing.

[8] N. Delgado, A. Q. Gates, S. Roach. A Taxonomy and Catalog of Runtime

Software-Fault Monitoring Tools, IEEE Transactions on Software Engineer-
ing, vol. 30, no. 12, pp. 859-872, Dec., 2004

13
 [9] Y. Gan, M. Chechik, S. Nejati, J. Bennett, B. O'Farrell, J. Waterhouse.
Runtime monitoring of web service conversations, IBM Centre for Advanced
Studies Conference archive, p.42 - 57, 2007

[10] F. Baligand, N. Rivierre, T. Ledoux. A Declarative Approach for QoS-

Aware Web Service Compositions, Service-Oriented Computing  ICSOC
2007, p.422-428, 2007

[11] A. Diaconescu. Composite Probes, a Monitoring Framework for Organising

Data into Congurable Hierarchies, Technical report

[12] ActiveBPEL - http://www.active-endpoints.com/active-bpel-engine-

overview.htm

[13] Design by Contract - http://en.wikipedia.org/wiki/Design_by_contract

[14] ASTRO project - http://www.astroproject.org/

[15] FAROS project,Etat de l'art sur la contractualisation et la composition,

Technical report, 2006

[16] P. Collet, R. Rousseau. ConFract : un systeme pour contractualiser des

composants logiciels hierarchiques, Proceedings of the Langages et Modeles
a objets (LMO'2005), RSTI L'objet, vol. 11/2005, pages 223-238, Hermes
science, Berne, Suisse, 9-11 mar 2005

[17] H. Chang, P. Collet. Fine-grained Contract Negotiation for Hierarchical

Software Components, Proceedings of the 31th EUROMICRO-SEAA Con-
ference 2005 - CBSE Track, pages 28-35, IEEE Computer Society Press,
Porto, Portugal, 30 aug - 3 sep 2005

[18] Object Constraint Language - OMG Specication, 2006

14