1

End-User Programming Language for ServiceOriented Integration

Ivan Gavran
Faculty of Electrical Engineering and Computing, University of Zagreb, Croatia
ivan.gavran@fer.hr

AbstractThe paper presents a new approach to End User

Development of large-scale distributed applications based on
the Service Oriented Computing. We have designed Simple
Service Composition Language (SSCL), a simple programming
language for Web Service composition. SSCL is a statementbased language designed for process-oriented Web Service
composition based on Service Oriented Programming Model
(SOPM). SSCL language has been developed as part of
Programmable Internet Environment1 (PIE), an end-user
framework for design, development, and execution of
distributed applications in Internet environment. In addition,
we have designed and implemented distributed translator for
translating the SSCL language into CL language, which is an
extension of Business Process Execution Language For Web
Services (BPEL4WS). The process logic description of the
generated CL code is ready for execution in any BPEL4WS
compliant environment.
Keywords:
service-oriented
programming, service composition

computing,

end-user

I. INTRODUCTION
Large-scale Internet-based distributed systems are one of
the most popular forms of computing systems adopted by
end-users. However, there are no available tools that can be
used by end-users in order to tailor the systems to their own
personal requirements and expectations. End-users need the
support to build new systems easily by incorporating
functionalities of available systems and services. The End
User Development (EUD) is one of the fields in computing
that researches new techniques in software development that
will promote end-users from software users to software
developers. One of research aspects of EUD is development
of new end-user programming languages. End-user
languages should be easy to adopt and give prominence to
design with reusable computing.
Service-Oriented Computing (SOC) is the paradigm for
distributed computing that utilizes services as fundamental
elements for application development. It represents a new
approach in application development moving away from
tightly coupled monolithic systems towards systems of

1
The Service-Oriented Programming Model, Coopetition Distributed
Architecture, Simple Service Composition Language, and Programmable
Internet Environment are developed at the School of Electrical Engineering
and Computing at the University of Zagreb, Croatia, in cooperation with
Ericsson Nikola Tesla d.d., Zagreb, Croatia, and cosponsored by Ministry
of Science, Education, and Sports through the national Cro-Grid project.
More
information
is
available
at:
http://www.ris.fer.hr/,
http://www.pie.fer.hr/ and http://www.cro-grid.hr/.

loosely coupled, dynamically bound components. Systems

built using SOC are expected to dominate the next
generation of enterprise business systems, grid systems,
sensor and actuator networks, and other ubiquitous
computing systems. In addition, we believe that SOC
paradigm is well-suited for end-user programming. SOC is
based on Web Services, which are autonomous, selfdescribing, and platform-independent computational
elements. For the purpose of developing massively
distributed interoperable applications, Web Services are
described, published, discovered, composed, and
programmed using a standard set of programming languages
and protocols.
In Service-Oriented Computing, a distributed application
is built as an interconnected collection of existing Web
Services. In order to describe the service collections and
their interconnections, a wide range of Web Service
composition languages have been developed [3]. The goal
of the service composition languages is to glue Web
Services together and describe coordination logic of service
invocations.
Service-Oriented Programming Model (SOPM) [18] is a
new methodology for design, development, and execution
of large-scale service-oriented applications. SOPM
introduces three-tiered coordination architecture that
enables integration of distributed applications through
cooperation and competition without the use of centralized
control mechanisms. In order to support design,
development, and execution of distributed applications in
Internet environment we have developed the end-user
development framework called Programmable Internet
Environment (PIE). The execution of distributed
applications in the PIE framework is based on the platform
independent language CL (Coopetition Language) [16]. CL
is an extension of BPEL4WS [5,7] language that integrates
the BPEL4WS process description and WSDL descriptions
of invoked services within a single compact document.
Since the CL language is derived from BPEL4WS and
WSDL languages that are based on XML, programs
developed using the CL language have complex and
extensively large structure. Thus, the CL language is not
suitable for use by end-users.
In this paper, we present SSCL (Simple Service
Composition Language) programming language that is also
a part of PIE framework. SSCL is an end-user programming
language for service composition based on SOPM. In
addition to developing the language, we have also designed
and implemented distributed SSCL Program Translator.

2
SSCL Program Translator translates SSCL program code
into the CL code.
Following the overview of service composition languages
presented in Section II, the Section III presents the SSCL
language and its features. Section IV describes the SSCL
Program Translator. Finally, Section V concludes the paper
and outlines the main directions of future work.
II. BACKGROUND
Composition of services is described in terms of service
orchestration and service choreography. Orchestration
defines composite application logic by describing services
message level interaction and execution order of the
interactions within a single application process.
Choreography tracks the sequence of messages that may
involve multiple parties and multiple sources, including
customers, suppliers, and partners. Compared to the
orchestration, choreography is concerned with the public
message exchanges that occur between multiple services,
rather than a specific application process that is executed by
a single party. As SOC developed, a number of languages
for service orchestration and choreography have been
introduced: BPEL4WS, BPML, WSFL, XLANG, BPSS,
WSCI, and WSCL [4].
One of the wider accepted languages for service
choreography is Web Services Choreography Interface
(WSCI). The WSCI is an extension of Web Service
Description Language (WSDL) [6]. It defines the message
exchange between Web Services, but does not describe the
controlling process that manages their interaction. The
WSCI specification defines message correlation, sequencing
rules, exception handling, transactions, and dynamic
collaboration.
BPEL4WS is a widely adopted and standardized
language for service orchestration. It is a process description
language suitable for defining workflows consisting of Web
Service invocations. Professional programmers use
BPEL4WS to define a collection of Web Services and to
describe the coordination of their activities. BPEL4WS is
built as a layer on top of the WSDL. WSDL is used to
define the specific operations that are allowed, while
BPEL4WS defines how the operations are sequenced.
Language CL [16] is a lightweight process description
language used for development of distributed applications
based on SOPM. It is a compact combination of BPEL4WS
and WSDL. The program written in CL language is
structured as an XML document consisting of three separate
sections. The first section of CL language includes the
description of program's process logic. The description is
written using a subset of the BPEL4WS language. The
second section of CL program is the WSDL description of
its interface. The third section of a CL program consists of a
set of WSDL documents that describe the interfaces of
external services invoked by the distributed program.
In order to make programming with the service
composition languages easier, a number of graphical
programming environments have been developed, including
WebSphere Studio [10], Oracle BPEL Process Manager
[11], WebMantra [12], and Triana [13]. However, these
tools do not successfully hide all complexity of underlying

Web Services technologies from end-users. In order to

create composite services using the graphical tools, the endusers still need to be familiar with standard Web Services
technologies like BPEL4WS, SOAP [14], and WSDL.
III. SERVICE ORIENTED PROGRAMMING MODEL
Service-Oriented Programming Model (SOPM) is a new
methodology for development of SOA applications.
Services comprising a distributed application perform local
actions without the use of centralized control and mutually
cooperate and compete in order to reach the global goals of
the application. Distributed applications based on SOPM
principles are implemented using the tree-tiered distributed
coordination architecture that consists of Application
services, Coopetition services and Distributed programs.
Example of a distributed application built using the threetiered coordination architecture is presented in Figure 1. The
example in Figure 1 consists of three distributed programs
that invoke five application services and use two coopetition
services.

Figure 1 Example of three-tiered distributed coordination architecture

Application services implement coarse fragments of

computational logic. The application services are usually
delivered on-demand through globally accessible network.
Alternatively, Application services can be custom developed
for specific application in order to provide necessary
functionalities. Coopetition services [17] are pre-built
services of the SOPM environment that are used for
coordination and communication of the Application
services. The developed coopetition services consist of
Semaphore, MailBox and EventChannel. For instance,
MailBox provides the mechanism for persistent
asynchronous communication between services using the
message-oriented communication model.
Distributed
programs [16] handle cooperation and competition between
Application services. They use Coopetition services in order
to bind individual activities performed by Application
services into a distributed application. Distributed programs
are specified in a process description language CL
(Coopetition Language) [16].
The Programmable Internet Environment (PIE) is an enduser development framework for building and running
SOPM applications over Internet infrastructure. PIE
provides facilities that enable installation and uninstallation

3
of Application and Coopetition services, as well as
interpretation of Distributed programs in the Internet
environment. PIE offers simple Web-based tools for
creation and deployment of SOPM applications. The
composition of services is based on the end-user language
SSCL (Simple Service Composition Language).

conditional expression, the control-flow primitives reference

the decision service name and a set of program variables.

IV. SIMPLE SERVICE COMPOSITION LANGUAGE

Since the BPEL4WS is a comprehensive XML-based
language with a complex syntax rules, developing
distributed systems using CL is a time-consuming and errorprone process. Therefore, we have designed a new
programming language for service composition, called
Simple Service Composition Language (SSCL). As SSCL is
primarily intended for end-users, its syntax is simple but
expressive enough to enable process modeling through Web
Service composition. In contrast to majority of WS
orchestration and choreography languages that are XML
based, the SSCL is a statement-based textual language with
simple syntax rules. Each SSCL primitive abstracts multiple
BPEL4WS instruction blocks. Thus, SSCL programs hide
all complexity of XML data handling, partner link
definitions and initialization, SOAP message initialization,
and other BPEL4WS programming constructs barely
understandable to the end-user programmers. An SSCL
program consists of a simple sequence of SSCL primitives.
Three types of primitives are supported: service invocation,
control-flow, and inter-service synchronization and
communication
A. Service Invocation and Control-Flow Primitives
Since the purpose of SSCL is to describe the service
composition as a set of service invocations, its basic
primitive is invoke. Figure 2 presents the format of an
invoke primitive and the equivalent code written in
BPEL4WS. Parameters of the invoke primitive include
service identifier and its IP address, operation identifier,
input variable, and output variable. The equivalent
BPEL4WS code consists of three parts. First part is used to
initialize the partner link that corresponds to the invoked
service. Second part is used to construct the SOAP request
message by using a set of assignment blocks. Finally, third
part is used to invoke the service and store the returned
value. As shown in this example, SSCL significantly
reduces the complexity and size of service composition
programs, and improves their expressiveness and
readability.
Although BPEL4WS supports advanced data handling
and variable manipulation by use of special instruction
blocks and XPath expressions [15], the SSCL does not
provide the equivalent support. All data handling and
variable manipulations are out of scope of SSCL and need
to be implemented as specialized Web Services. Example of
specialized Web Services are decision services invoked as
part of a control-flow construct in order to calculate the
value of a conditional expression. SSCL provides two
control-flow constructs: if-then-else conditional branching
and while conditional looping. As a substitution for the

Figure 2 Comparison of Service Invocation in SSCL and WS-BPEL

Described approach simplifies the adoption of SSCL,

because the end-user does not need to learn and use the
XPath language. Simplified data handling in SSCL is based
on two variable types, textual and Boolean variables. The
textual variables contain any textual data including XML.
They are primarily used to store constants and the output of
a service and provide the input to another service. The
Boolean variables store the values that are calculated by a
decision service and are used in control-flow primitives.
B. Synchronization and Communication Primitives
In addition to the basic subset of BPEL4WS
functionalities, SSCL contains an additional set of
primitives for describing the decoupled inter-service
communication and synchronization.
Communication and synchronization primitives include
the primitives for handling semaphores, mailboxes, and
event-channels. Semaphore, mailbox, and event-channel are
implemented as part of PIE framework [17]. Semaphore is
used for service synchronization and resource protection.
Mailbox is used for decoupled, asynchronous messageoriented communication between services. Finally, eventchannel is an advanced communication mechanism that
supports event-driven inter-service communication based on
publish-subscribe model. Since their implementation is
based on the standard Web Services protocol stack, they can
be easily integrated in other service-oriented systems.
TABLE 1INTER-SERVICE SYNCHRONIZATION AND COMMUNICATION
PRIMITIVES

Table I presents the set of implemented SSCL primitives.

All primitives include at least two parameters, which specify

4
the service IP address and service instance identifier. For
each synchronization and communication service there are
two primitives used to create and destroy individual
instances of the related service.
Two primitives are used for interaction with semaphore.
ObtainSemaphore is a blocking primitive that suspends
the SSCL program execution until the semaphore is
obtained. ReleaseSemaphore is a non-blocking
primitive that releases the semaphore without suspending
the SSCL program execution.
Mailbox communication is based on two primitives,
PutMessage
and
GetMessage.
Parameter
message_body of the PutMessage primitive defines a
SSCL variable that contains the body of the message.
Similarly, parameter in_var of the GetMessage
primitive defines the SSCL variable that stores the received
message. All messages are text-based and enable exchange
of any XML-based data.
Event-channel is accessed using three primitives for
handling events and two primitives for handling
subscriptions. Publish, RePublish, and UnPublish
primitives are used to publish, update, and remove events
respectively. These primitives include parameter event
that references the variable containing the text-based
description of an event. Subscribe and UnSubscribe
primitives are used to subscribe and unsubscribe to and
from a specific set of events. These primitives include two
parameters that reference the resource ID and IP address of
external event interpreter that performs advanced contentbased analysis of events.
Figure 3 presents an example of inter-service
communication and coordination. The example consists of
three SSCL programs that use mailbox and semaphore
services for communication and synchronization. Three
SSCL programs, A, B, and C, are executed in parallel on
nodes 1, 3, and 5. Mailbox service is hosted by Node 2,
while semaphore service is hosted by Node 4. Web Services
X and Y, which implement custom application logic, are
hosted by nodes 6 and 7. SSCL programs A, B, and C
describe the way in which Web Services X and Y are
invoked in order to achieve the overall goal of the
distributed application.
SSCL program A executed on Node 1 and SSCL program
B executed on Node 3 communicate through the mailbox
hosted by Node 2. SSCL program A uses the PutMessage
primitive to send messages to the mailbox at Node 2. Node
3 reads the messages by using the GetMessage primitive.

Service X, SSCL programs A and C need to obtain the

semaphore by using the ObtainSemaphore primitive.
After the service X is invoked, the semaphore is released by
using the ReleaseSemaphore primitive.
V. SSCL PROGRAM TRANSLATOR
In order to leverage the wide adoption of BPEL4WS
language and ensure the open-ended integration, we have
built the distributed program translator that translates SSCL
code to CL code. SSCL Program Translator has been
designed and implemented as a distributed service-oriented
application in order to provide the scalable and fault-tolerant
environment for SSCL translation. The translated programs
generated by SSCL Program Translator are scheduled for
execution on the distributed CL Interpreter that is part of
PIE framework. Distributed CL Interpreter is implemented
as a loosely coupled collection of Web Services that
translate and execute programs written in Coopetition
Language, which is derived from BPEL4WS language.
A. SSCL Program Translator Architecture
SSCL Program Translator architecture consists of two
main components, Program Queue and Translator Pool.
Program Queue is used to buffer SSCL programs, while the
Translator Pool consists of a set of SSCL translators.
Program Queue is the entry point to Program Translator
implemented as a system-wide queue that stores SSCL
programs. SSCL programs are scheduled for compilation by
simple insertion into the Program Queue. SSCL translators
register with the Program Queue, acquire the SSCL
programs, and translate them to CL programs. Thus, the
Program Queue provides a simple FIFO scheduling
mechanism that schedules SSCL programs to the first
available SSCL translator.

Figure 4 Distributed Program Translator

Figure 3 Inter-service Communication and Synchronization Example

Semaphore hosted by Node 4 ensures synchronized

access to Web Service X. In order to invoke the Web

SSCL Translator Pool consists of a set of loosely coupled

instances of SSCL translators. Figure 4 presents an example
of a Translator Pool consisting of three SSCL translators

5
that are installed on distinct nodes. SSCL translators
continuously execute the three-step process in which an
SSCL Program is read from the Program Queue, translated
to CL program, and scheduled for execution on distributed
CL Interpreter.
SSCL Program Translator provides the scalable and loadbalanced environment for translation of SSCL programs.
Scalability and load balancing are achieved by use of the
Translator Pool, which enables dynamical changes to the
number of translators. Scalability is achieved by adding new
translators to the Translator Pool. Translators automatically
achieve load balancing by competing to fetch programs
stored in Program Queue. Furthermore, Translator Pool
provides basic fault-tolerance. If a fault occurs on one of the
translators, the other translators continue the program
translation process.
SSCL Translator and Program Queue are implemented
using the Web Services set of standards. Therefore, they can
be used in interaction with any distributed system based on
SOC.
B. SSCL Translation Process
The SSCL translation process is presented in Figure 5. It
consists of source SSCL program analysis and generation of
target CL program. SSCL code analysis verifies the lexical,
syntax, and semantic correctness of the program. While
performing semantic analysis, WSDL descriptions of all
invoked Web Services are fetched from service registry.
WSDL descriptions are necessary for semantic analysis and
verification of source program. Furthermore, fetched WSDL
documents are used during CL program generation.

program interface contains callback methods necessary for

asynchronous invocation of Web Services operations.
Finally, generated BPEL4WS process description, CL
program interface description, and collected Web Services
interface descriptions are stored in XML document
structured by CL language rules.
The generated CL program can be directly executed by
the distributed CL Interpreter that is part of PIE framework.
Moreover, the BPEL4WS process description of generated
CL program can be executed by any other BPEL4WS
execution environment.
VI. CONCLUSION
In this paper, we present a new end-user service
composition language named Simple Service Composition
Language. SSCL is used as a foundation of PIE that
provides tools for fast and simple design and
implementation of SOPM applications. SSCL is a statementbased language with simple lexical and syntax rules, which
ensure higher readability than XML based service
composition languages. SSCL provides a small set of
primitives used to invoke services, define the process
workflow, and describe the decoupled inter-service
communication and synchronization.
We have designed, developed, and tested SSCL Program
Translator that translates the SSCL code into CL code.
Program Translator is implemented as a distributed and
loosely coupled system that supports scalability and faulttolerance.
In addition to improving SSCL programming language
and SSCL Program Translator, our future work will focus
on design and development of a browser-centric
programming environment that will provide the
comprehensive support for service-oriented end-user
programming.
REFERENCES
[1]

[2]

[3]

Figure 5 SSCL Translation Process

[4]
[5]

Three stages of CL program generation are BPEL4WS

process description generation, generation of CL program
interface description, and integration of WSDL descriptions
of all Web Services invoked in source program. BPEL4WS
process description is generated from analyzed SSCL code.
All additional information necessary for BPEL4WS process
definitions are available in WSDL documents collected
during the source code analysis. Description of CL program
interface is generated as a WSDL document. The CL

[6]

[7]

B.W. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and

R. Selby: "Cost models for future software life cycle processes:
COCOMO 2.0.", Annals of Software Engineering, Special Volume on
Software Process and Product Measurement, Volume 1, Number 1,
J.C. Baltzer AG Science Publishers, Amsterdam, Netherlands, 1995,
pp. 57-94.
"Web Services architecture overview the next stage of evaluation
for e-business", IBM Research 2000, http://www106.ibm.com/developerworks/webservices/library/w-ovr/?dwzone
=webservices
W.M.P. van der Aalst, M. Dumas i A.H.M. ter Hofstede: "Web
Service Composition Languages: Old Wine in New Bottles?",
Proceeding of the 29th EUROMICRO Conference, Belek near
Antalya, Turkey, September 2003, pp. 298-305.
C. Peltz: "Web Services Orchestration and Choreography", Computer,
Vol. 36, No. 10, October 2003, pp. 46-52.
T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F.
Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic i S.
Weerawarana. "Business Process Execution Language for Web
Services (BEPL4WS) 1.1", May 2003, (http://www106.ibm.com/developerworks/webservices/library/ws-bpel).
E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: "Web
Services Decription Language (WSDL) 1.1", World Wide Web
Consortium (W3C) Note, February 2001,
(http://www.w3.org/TR/wsdl).
A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, C.
K. Liu, S. Thatte, P. Yendluri, and A. Yiu: "Web Services Business
Process Execution Language Version 2.0", Working Draft, December
2004, http://www.oasis-

[8]

[9]

[10]
[11]
[12]
[13]
[14]
[15]
[16]

[17]

[18]

[19]

open.org/committees/download.php/10347/wsbpel-specificationdraft-120204.htm
G. Fischer, E. Giaccardi, Y. Ye, A. G. Sutcliffe, and N. Mehandijev:
"Meta-design: A Manifesto for End-User Development",
Communications of ACM, Vol. 47, No. 9, September 2004, pp. 3337.
I. Morch, G. Stevens, M. Won, M. Klann, Y. Dittrich, and V. Wulf:
"Component-based Technologies for End-User Development",
Communications of ACM, Vol. 47, No. 9, September 2004, pp. 5962.
W. Butt: "Programmatic control of a long-running BPEL process
with WebSphere Studio", http://www-128.ibm.com/developerworks/
websphere/library/techarticles/0410_butt/0410_butt.html
Oracle BPEL Process Manager, http://www.oracle.com/appserver/
bpel_home.html
WebMantra, http://www.panaceasoftware.com/products/
webmantra.html
S. Majithia, M. Shields, I. Taylor and I. Wang: "Triana: A Graphical
Web Service Composition and Execution Toolkit", Proceedings of
ICWS'04, San Diego, California, June 2004, pp. 514-521.
D. Box and others: "SOAP 1.1", World Wide Web Consortium
(W3C) Note, February 2000., (http://www.w3.org/TR/SOAP)
J.Clark and S. DeRosso: "XML Path Language (XPath) Version
1.0", World Wide Web Consortium (W3C) Recommendation,
November 1999, http://www.w3.org/TR/xpath
D. Skrobo, A. Milanovi, and S. Srblji: "Distributed Program
Interpretation in Service-Oriented Architectures", Proceedings of the
9th World Multi-Conference on Systemics, Cybernetics and
Informatics (WMSCI'05), Orlando, Florida, USA, 2005, Vol. 4, pp.
193-197.
A. Milanovi, S. Srblji, D. Skrobo, D. apalija, and S. Rekovi:
Coopetition Mechanisms for Service-Oriented Distributed Systems,
Proceedings of the CCCT 2005 (The 3rd International Conference on
Computing, Communications and Control Technologies), Austin,
Texas, USA, July 2005, Vol. 1, pp. 118-123.
A. Milanovi: "Service-Oriented Programming Model", Ph.D. thesis
in Croatian, Original title "Programski model zasnovan na uslugama",
School of Electrical Engineering and Computing, University of
Zagreb, Croatia, 2005.
Programmable Internet Environment, http://www.pie.fer.hr