0% found this document useful (0 votes)
27 views

A Web Lab For Mobile Robotics Education

This document presents an architecture for building remote access laboratories (or Web Labs) following a service-oriented computing approach. Key points: - Lab resources (physical or logical) are modeled and implemented as services, allowing experiments to be assembled by composing these services. - The architecture uses composition and federation of services, allowing Web Labs to share resources and experiments across administrative domains. - An implementation of this architecture is presented using Web services technology. As an example, a Web Lab for mobile robotics education is described.

Uploaded by

mmrselenozturk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
27 views

A Web Lab For Mobile Robotics Education

This document presents an architecture for building remote access laboratories (or Web Labs) following a service-oriented computing approach. Key points: - Lab resources (physical or logical) are modeled and implemented as services, allowing experiments to be assembled by composing these services. - The architecture uses composition and federation of services, allowing Web Labs to share resources and experiments across administrative domains. - An implementation of this architecture is presented using Web services technology. As an example, a Web Lab for mobile robotics education is described.

Uploaded by

mmrselenozturk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

2007 IEEE International Conference on WeE2.

1
Robotics and Automation
Roma, Italy, 10-14 April 2007

A Web Lab for Mobile Robotics Education


Paulo R.S.L. Coelho1 , Rodrigo F. Sassi1,2 ,
Eleri Cardozo1, Eliane G. Guimarães2, Luis F.
Faina3, Alex Z. Lima1 , Rossano P. Pinto1

Abstract— This paper presents an architecture for the Web services technology and a Web Lab in mobile
building remote access laboratories (or Web Labs) robotics built according to the architecture are presented
following the service-oriented computing approach. In as well. The paper is organized as follows. Section II
this architecture the application’s building blocks are
services that can be recursively composed resulting in presents some related work; Section III presents a service-
more comprehensive services. Remote access labora- oriented architecture for Web Labs; Section IV provides
tories can benefit of this approach. Every lab resource an implementation of this architecture; Section V de-
(physical or logical) is modeled and implemented as a scribes a Web Lab in mobile robotics developed according
service (in our case, a Web service) and lab exper- to the implemented architecture; and Section VI closes
iments are assembled by composing these services.
A Web Lab built according to this architecture is the paper with conclusions and future work.
presented with examples of remote experiments in the
field of mobile robotics. II. Related Work
I. Introduction Web Labs were initially developed with well known
Remote Access Laboratories or Web Labs have been Web technologies, such as Java applets on the client
proposed as powerful tools for the sharing of expen- side [3] and server-side extensions based on CGI (Com-
sive equipment and for bringing experimentation into mon Gateway Interface), ASP (Active Server Pages),
distance learning. The challenge regarding Web Labs or JSP (Java Server Pages) [4][5]. Distributed objects
implementations is to provide an infrastructure where approaches based on Java RMI (Remote Method Invo-
remote experiments are easily assembled and modified. cation) and CORBA (Common Object Request Broker
Architecture) were proposed as well [6]. Other implemen-
This paper proposes a service-oriented computing ap-
tations require platform dependent software in the client
proach for building Web Labs. Considered as an evo-
terminal [7]. All of these approaches have in common
lution of distributed computing, service-oriented com-
the limited software reuse, customization, and interoper-
puting is defined as ”the approach that uses services as
ability. These limitations are due to the low granularity
fundamental elements in application development” [1].
of software artifacts and the adoption of interaction
Using composition mechanisms (or orchestration), more
protocols that are usually blocked by network firewalls.
comprehensive services can be built from existing ones.
Since the composed service is itself a service, it can take More recently, Web Lab architectures based on soft-
part in further compositions [2]. ware components were proposed [8]. Although com-
Implementing Web Labs according to service-oriented ponents increase software reuse and customization,
computing brings some remarkable benefits. Firstly, lab component-based architectures still lack interoperability
resources (physical and logical) are modeled and im- among different platforms and administrative domains.
plemented as services, for instance, a robot exports a Architectures based on Web services are an attempt to
set of services, each one performing an specific function build Web Labs that fulfill the requirements of software
(sensing, navigation, and so on). Secondly, experiments reuse, customization, and interoperability [9][10].
can be synthesized as a composition of services. In this The related work closer to the described in this pa-
way, new experiments may use existing ones as units per is the iLAB project [11]. iLAB identifies a set of
of composition, and the updating of an experiment is administrative functionalities such as user subscription,
restricted to its composition’s logic. Finally, the concept authorization and authentication, group management,
of federation of services allows Web Labs to use resources and access control. Such tasks are common to all Web
maintained by other Web Labs located in different ad- Labs and are decoupled from the domain specific func-
ministrative domains. tionalities the Web Labs support. The administrative
This paper describes an architecture based on compo- tasks are managed by a Service Broker that mediates the
sition and federation of services for building Web Labs. access to the associated Web Labs. The Service Broker
A complete implementation of this architecture using supports in some way the federated operation of Web
Labs. The architecture proposed in this paper shares
1 State University of Campinas, Campinas-SP, Brazil; some similarities with iLAB, for instance:
2 Renato Archer Research Center, Campinas-SP, Brazil;
3 Federal University of Uberlândia, Uberlândia-MG, Brazil • decoupling between use and management of Web
[email protected] Labs;

1-4244-0602-1/07/$20.00 ©2007 IEEE. 1381


Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1

• use of Web services for management and access to Notice that credentials and sessions refer to a specific
Web Labs; participant accessing a specific Web Lab. Examples of
• federated operation of Web Labs. credentials include the user’s identification, roles (e.g.,
iLAB makes no restriction about the implementation student, instructor), permissions (e.g., usage, manage-
of the Web Labs, except the interfaces for attaching to ment), and privileges (e.g., group leader).
the Service Broker. Sessions are responsible for managing the interaction
The architecture proposed in this paper differs from between a participant and a Web Lab. Sessions maintain
iLAB in three important aspects: state information related to the interaction such as the
1) the scope of the federation of Web Labs is enlarged identification of the participant, the remaining access
by allowing Web Labs to share resources (not only time, and the actions the participant has performed.
subscribed users); Web Labs publish the services they offer. Services are
2) instead of rely on a centralized access control (Ser- units of composition on interaction with the Web Lab
vice Broker), each federated Web Lab sets its own employed for purposes such as access, interaction, com-
access policies; munication, and management. Experiments offered by
3) the federation imposes that each federated Web Web Labs are modeled as a composition of services. For
Lab must implement a minimum security infras- instance, an experiment in environmental mapping can
tructure. compose a service of locomotion (e.g., random walk) with
Composition plays a key role in this proposed archi- a service of telemetry (e.g., sonar readings). A Web Lab
tecture for Web Labs. Intra-domain composition allows maintains a set of Resources, both physical such as robots
a Web Lab to combine its resources within experiments. and cameras, and logical such as robot simulators and
Inter-domain composition allows a Web Lab to combine navigation maps. Resources are manipulated remotely
its own resources with resources offered by other Web through services. A Web Lab has a self-relationship
Labs. Inter-domain composition enlarges the range of that models a federation of Web Labs. The model does
experiments a Web Lab can offer and constitutes the not impose a particular mechanism for building such a
truly motivation for a federated operation of Web Labs. federation.
The architecture also gives each Web Lab the freedom
Resource Service
to set its owns access rules. Policies is a flexible way to manipulates

set the condition upon which users can access the Web composes
Lab. For instance, a policy must require that foreign publish
maintains
users be authenticated, present credentials issued by the Web Lab Experiment
offers
Web Lab he/she was subscribed, and has a time slot
already reserved to perform experiments. The flexibility federates

of policies allows a Web Lab to take part of multiple uses


Credential
federations by defining a policy set for each federation it Session
takes part.
Finally, the federation imposes a minimum set of secu-
rity constraints to its federated Web Labs. For instance, Group Participant User
each Web Lab must support an infrastructure for authen-
ticating users and services. This infrastructure is domain-
independent and can be supplied by the federation and Fig. 1. A reference model for Web Labs.
integrated into existing Web Labs.
III. A Service-oriented Architecture for Web Looking at the reference model presented in Fig. 1 it
Labs is possible to aggregate the concepts around the partic-
The service-oriented architecture for building Web ipant (user, group, credential), the Web Lab (resource,
Labs defines a reference model for Web Labs and a family experiment), and the usage of the Web Lab by a given
of services for supporting the model elements. participant (session). This suggests a need for services
The reference model for Web Labs is shown in Fig. 1. for managing participants, Web Labs, and sessions.
The UML concept diagram shows the main elements of The service in charge for managing participants offers
the model as well as the relationships among them. The functionalities for the management of users and groups.
two central elements are Participant and Web Lab. A User management functions include subscription and un-
participant can be an individual (User ) or a Group. A subscription, and assignment of credentials with proper
group is a collection of participants formed by users or roles, permissions, and privileges. Group management
(sub)groups. The line connecting participants to Web functions include the creation, updating, and removing
Labs represents the usage relationship. To use a Web Lab of groups.
a participant must have assigned the proper Credentials The service in charge for managing Web Labs offers
and establish one or more Sessions with the Web Lab. functionalities for the management of resources and ex-

1382
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1

periments available in the Web Lab. Resource manage-


Interaction Communication
ment functions include resource registration and usage Management Management
restrictions such as periods of availability. Experiment
management functions include activation of experiments
and assignment of restrictions to experiments such as
reservation restrictions (e.g., maximum reservation time) Participant <<uses>> Access <<uses>> Web Lab
and accessing restrictions (e.g., minimum set of creden- Management Management Management
tials).
The participant and lab management services hold
long-term information and provide both programatic and Fig. 2. Major components of a service-oriented architecture for
managing Web Labs.
human-operated interfaces. The use of services provided
by these interfaces are subject to authentication and
authorization.
Interaction Management Services are domain dependent
The services in charge for managing sessions expose
services and will be detailed in Section V.
interfaces for the management of interactions between a
participant and the Web Lab. The architecture identifies A. Access Management Service
three basic session types: access, interaction, and commu-
nication sessions. Access sessions manage the access of a The access management service implements policy-
participant to the Web Lab according to its credentials. based access control according to the Extensible Ac-
Interaction sessions manage the remote execution of ex- cess Control Markup Language (XACML) [12]. XACML
periments maintained by the Web Lab. Communication allows a Web Lab to define access policies for each
sessions manage the exchange of information between the experiment it supports. When a user attempts to access
users and the Web Lab. an experiment, the access management service is invoked.
The service requests user authentication and invoke the
Access management functions include authentication
participant and Web Lab management services in order
and authorization. Authentication establishes the iden-
to get the user’s credentials and experiment restrictions
tity and credentials of the user while authorization de-
such as credentials necessary for execution and current
cides if the credentials suffice for granting access to the
reservation data (reserving user, reserved time slot, etc.).
Web Lab resources. A set of usage policies define the rules
User and experiment information is then submitted to
for accessing the Web Lab resources and experiments as
the XACML engine for evaluation. XACML policies
a function of the user’s credentials.
typically check if the credentials suffice for accessing the
Interaction sessions provide the correct flow of service
experiment, and if the user holds a valid reservation for
invocation demanded by an experiment. This flow is
executing it. If the checking succeeds, the user is allowed
specified as a composition of services supported by the
to execute the experiment.
Web Lab. Interaction management functions include the
SunXACML, a public domain implementation of
initiation and termination of communication sessions,
XACML from Sun Microsystems was employed as
and logging functions. Interaction sessions are subjected
XACML engine [13].
to the existence of a previously established and valid
access session. B. Communication Management Services
Communication management functions include config-
uration and connection of producers and consumers of The Communication Management Service is imple-
information, management of quality of service for mul- mented as a information diffusion service according to the
timedia communication, support for person-to-person publish/subscribe model. The service propagates XML
communication, and logging of information. documents generated by producers to the subscribed
Figure 2 illustrates the major components of the ar- consumers. The service offers a Web service management
chitecture in a UML package diagram. The five packages interface for subscribing and unsubscribing producers
represent the general components for supporting Web and consumers, and for submitting XML documents for
Labs and offer a hint for aggregation of services according diffusion.
to the reference model described above. During the subscription, a consumer may supply a
XPath expression that is evaluated when documents are
IV. Architecture Implementation submitted. The result of this evaluation is propagated
to the consumers if it results in a valid document (the
The five service classes shown in Fig. 2 were im- submitted one or part of it). If a consumer supplies a
plemented using the Web services technology. Partici- notification interface, the service invokes the operation
pant and Web Lab Management Services are traditional push in this interface in order to transfer the document
database-centric services and will not be detailed. Access as soon as it was processed (push style). Alternatively,
Management and Communication Services are domain the consumer may inquire the service for new submitted
independent services and are detailed in the sequence. documents (pull style).

1383
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1

If a producer states a lifetime for a submitted XML dual-Xeon processors running the GNU/Linux operat-
document, the document persists on the service during ing system. The infrastructure is complemented by the
this lifetime, otherwise, the service discards the docu- robots’ application programming interface (API).
ment after it was delivered. The kind of information Figure 3 illustrates the infrastructure components and
present in these documents can serve several purposes, the interaction protocols on the server side. The compo-
for instance, notification (e.g., alarms); configuration nents on the client side consist of common Web browsers,
(e.g., formats and sizes of audio and video); user gener- Java clients (Java processes that run on the client
ated information (e.g., chat messages); synchronization desktop) loaded from the Java Web Start application
messages (e.g., whiteboard updates); and logging infor- launcher, and MPEG-4 media players such as MPlayer
mation (e.g., session-related data). or Windows Media Player. Java clients discover Web
A media streaming service was implemented above the services by querying the UDDI service and invoke them
diffusion service. Media producers publish their capa- through the SOAP (Simple Object Access Protocol)
bilities, media ports, and negotiation interfaces. Media protocol.
consumers access these informations and, if the case, Client Side
negotiate a proper media quality and format through the HTTP JSP/Servlet
producer’s negotiation interface. The media flow is not Web Browser Container Framegrabber
(Tomcat)
transferred through the diffusion service.
SOAP JPEG
Other Web Lab implementations may choose different
SOAP
approaches for supporting communication. Both com- Java Client
Web Services Robot API
Container
mercial and open source products supporting media (Axis)
(Java)

streaming, conferencing, and messaging are available


from many sources and can serve as a basis for the HTTP
Panoramic Camera
(Axis 213 PTZ)
Communication Management Service. In this case, a MPEG−4
Web service wrapper to control these products must be Media Player

implemented.
Fig. 3. GigaBOT Web Lab Infrastructure.
V. GigaBOT Web Lab
GigaBOT is a Web Lab for mobile robotics education B. Interaction Services
implemented following the architecture described above.
Interaction services are services supporting the inter-
Being domain independent, access and communication
action with the Web Lab domain-specific resources. The
services don’t need any adaptation to the mobile robotics
GigaBOT Web Lab provides six interaction services: lo-
domain. The interaction services, otherwise, have been
comotion, telemetry, vision, panoramic camera, actions,
developed for this specific domain and will be described
and code submission services.
next.
The locomotion service exports operations for moving
and turning the robot to a relative or absolute position
A. Lab Infrastructure
and for adjusting and limiting the speed and acceleration
The GigaBOT Web Lab operates two ActivMedia’s of the robot. Operations supporting robot locomotion
Pioneer P3-DX robots with sixteen sonars and protection can be synchronous (blocking while the movement com-
bumpers. One robot is fitted with on-board processor, pletes) or asynchronous.
wireless network interface (802.11g), and a Canon VC- The telemetry service allows the obtaining of telemetry
C4 on-board camera with PTZ (pan/tilt/zoom) and con- data such as current robot position, sonars readings,
nected to framegrabber. The second robot does not have robot physical dimensions, and voltage supplied by the
on-board processor, being controlled via serial port by an battery.
HP IPaq H5555 handheld with 802.11b wireless network. The vision service allows to control the robot’s on-
The handheld runs the Familiar Linux v0.8.1 operating board camera. The control parameters includes the ab-
system. This robot is fitted with an Axis 206W wireless solute and relative values of pan (horizontal movement),
network camera. An Axis 213 PTZ network camera is tilt (vertical movement), zoom, and focus. The service
available to allow a panoramic view of the execution of also allows the capture of a static image in JPEG format.
experiments. The panoramic camera service provides access to the
The software infrastructure at the lab’s side is com- Axis 213 PTZ resource. The service supports the same
posed of a Web service container (Apache Axis Java), operations as the vision service plus operations for video
a JSP/Servlet container (Apache Tomcat), a UDDI recording.
(Universal Description Discovery Integration) server The action service wraps some of the built-in robot
(jUDDI), and a relational database (MySQL). Axis, actions into Web services. An action establishes a set of
Tomcat, and jUDDI are supplied by the Apache Software basic operations which, together, perform a specific task.
Foundation [14]. Containers and databases execute on a Each action added to the robot is inserted into a queue

1384
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1

with a given priority. Actions are performed in a sequence from the robot, and the already detected obstacles; and
given by their priorities. Nine actions are available: six a tabbed panel for navigation (bottom right).
related to prevention and recover from collisions (e.g.,
moving with frontal and lateral obstacle avoidance), and
three actions related to locomotion (e.g., moving the
robot to a giving point).
Finally, the code submission service allows users to
submit and execute C++, Java, or Python code on a
server connected to the robot. The submitted code must
control the robot by calling the methods supplied in the
robot’s application programming interface (API). This
service also provides methods for controlling the execu-
tion of the submitted program, for instance, retrieving its
process identifier (pid) and standard output printouts,
and controlling its state of execution (suspend, resume,
kill).
C. Lab Experiments
The experiments provided by the GigaBOT Web Lab
are programmed using the composition of the interaction,
access, and communication services. The level of diffi-
Fig. 4. Interface for the basic telemetry experiments.
culty of a proposed experiment can vary from the entire
coding of a robot navigation algorithm to the adjusting of Experiments are built by composing the six interactive
parameters of a supplied algorithm. Intermediate levels services. The composition logic can be coded in general
include the coding of a new action. An experiment can purpose programming languages such as Java or C++,
be executed on the user’s computer or on a server located or expressed in specialized composition languages such
at the Web Lab and connected to the robot. as BPEL (Business Process Execution Language) [15].
Six experiment classes were developed for the Web BPEL allows the specification of workflows of service
Lab: calls in XML. The advantage of BPEL is the availability
1) Basic Telemetry: experiments that allow to control of sophisticated engines supporting graphical edition as
the robot as well as to inspect the sonar readings. well as execution and debugging of BPEL scripts.
Control can be performed As an example of composition with BPEL consider an
• by issuing basic commands (move and turn) via experiment in the Vision-based Navigation class where
a graphical user interface; the robot must follow a colored strip on the floor using
• by drawing a route with the mouse on a navi- solely its on-board camera. This experiment composes
gation map; the vision, motion, and communication services with
• by combining a set of pre-programmed actions a image processing algorithm written using the Java
(e.g., random walking with obstacle avoid- Advanced Imaging (JAI) system [16]. Figure 5 illustrates
ance). the interface of this experiment. The image on the left
2) Navigation on Structured Environments: experi- shows the image captured from the on-board camera
ments that allow the mapping of the robot’s en- (highlighted in black). The image on the center shows
vironment and navigation based on environmental the detected borders of the strip, and the image on
maps. the right shows the trajectory computed from the other
3) Navigation on Non Structured Environments: ex- two images. The interface allows the user to adjust the
periments that allow navigation and environmental maximum speed in which the robot follows the strip
mapping simultaneously. as well as some parameters of the image processing
4) Vision-based Navigation: experiments that allow algorithm. A movie of the experiment is recorded from
navigation using the robot’s vision system. the panoramic camera.
5) Code Submission: allows the user to write naviga- The composition logic employs a cycle with the follow-
tion code and submit it directly to the robot. ing steps:
6) Cooperative Robotics: experiments employing two 1) invoke the communication service to start the
robots developing cooperative tasks. movie recording from the panoramic camera;
Figure 4 shows the interface for the Basic Telemetry 2) invoke the vision service to acquire an image from
experiments. The interface consists of two panels with the robot’s on-board camera;
images from the on-board and panoramic cameras (left); 3) invoke the image processing algorithm to identify
a navigation map (top right) with the actual robot po- the strip. If no strip is identified do: (i) invoke the
sition, the sonar readings represented as lines emanating locomotion service to stop the robot; (ii) invoke the

1385
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.
WeE2.1

of XML-based standards for identity control (SAML) and


policy-based access control (XACML).
Finally, the next step in Web Lab design and operation
is to devise novel federation mechanisms. The proposed
architecture is an step towards this goal. Currently we are
building a federation of Web Labs in the field of Control
Systems and Robotics.
Fig. 5. Navigation using the robot vision.
Acknowledgments
This project is supported by the Brazilian National
communication service to stop recording; (iii) end Teaching and Research Network (RNP) through the Giga
of experiment. Project. The authors thank the undergraduate students
4) invoke an heuristic to compute a movement that Victor Perticarrari, Danielle Santos, and Ewerton Bar-
will position the strip in the center of the image; bosa for helping in software development.
5) invoke the locomotion service to perform the move-
ment synchronously; References
6) go to step 2. [1] M.P. Papazoglou and D. Georgakopoulos. Service-oriented
Since this experiment runs on the client side, the computing: Introductions. Communication of the ACM,
10(46):24–28, Oct 2003.
network bandwidth and delay strongly impacts on the [2] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, and S. Weerawarana.
performance of the experiment. In order to assess the The Next Step in Web Services. Communication of the ACM,
bandwidth and delay demanded by the Web Lab, the 10(46), Oct 2003.
[3] J. Hua and A. Ganz. Web Enabled Laboratory (R-LAB)
vision-based navigation experiment was performed from Framework. In ASEE/IEEE Frontiers in Education Confer-
four different access networks: local area, campus, res- ence, Boulder, USA, Nov 2003.
idential ADSL (Asymmetric Digital Subscriber Line), [4] A. Khamis, D. M. Rivero, F. Rodrı́guez, and M. Salichs.
Pattern-based Architecture for Building Mobile Robotics Re-
and virtual private networks. Local area and campus mote Laboratories. In IEEE International Conference on
networks are Ethernet-based networks; ADSL service is Robotics and Automation, Taiwan, Sept 2003.
limited to 2 Mbit/s; and virtual private network (VPN) is [5] J. A. del Alamo, L. Brooks, C. McLean, J. Hardison,
G. Mishuris, V. Chang, and L. Hui. The MIT Microelectronics
a dedicated network with Gigabit Ethernet links. Table I WebLab: a Web-Enabled Remote Laboratory for Microelec-
shows the maximum speed the robot is still able to follow tronic Device Characterization. In World Congress on Net-
the strip and the network bandwidth consumed by the worked Learning in a Global Environment, Berlim, Germany,
May 2002.
experiment for these four networks. [6] E.G Guimarães, A.T. Maffeis, J.L. Pereira, B.G. Russo,
E. Cardozo, M. Bergerman, and M. Magalhães. REAL: A
Access Network Max. Speed (mm/s) Bandwidth (Kbps) Virtual Laboratory for Mobile Robots Experiments. IEEE
Local Ethernet 170 23,500.00 Transactions on Education, 46(1), Feb 2003.
Campus Ethernet 90 1,250.00 [7] D.Z. Denis, A. Bulancak, and G. Ozcan. A Novel Approach to
ADSL 30 970.00 Remote Laboratories. In ASE/IEEE Frontiers in Education
VPN 200 23,700.00 Conference, Boulder, USA, Nov 2003.
[8] E.G. Guimaraes, A.T. Maffeis, R.P. Pinto, C.A. Miglinski,
TABLE I E. Cardozo, M. Bergerman, and M. Magalhaes. REAL: A Vir-
Experiment performance in different access networks. tual Laboratory Built from Software Components. Proceedings
of the IEEE, 91(3), March 2003.
[9] M. Casini, D. Prattichizzo, and A. Vicino. The Automatic
Control Lab. IEEE Control Systems Magazine, 25(1), June
VI. Conclusions 2004.
[10] A. Rasche, B. Rabe, M. von Lowis, J. Moller, and A. Polze.
A reference model for Web Labs was introduced in this Real-time robotics and process control experiments in the
paper with the objective of identifying the major compo- Distributed Control Lab. IEE Proceedings - Software, 152(4),
Oct 2005.
nents a Web Lab must implement. A domain independent [11] MIT. iCampus/iLAB Project, 2007. http://icampus.mit.
service-oriented architecture adhering to this model was edu/ilabs.
also detailed. In this architecture, lab experiments are [12] OASIS. eXtensible Access Control Markup Language
(XACML), May 2006. Available at http://www.oasis-open.
designed as a composition of services offered by the org.
Web Lab. This approach favors coarse-grained reusability [13] Sourceforge. Sun’s XACML Implementation, 2007. http://
when building new experiments or adapting existing ones sunxacml.sourceforge.net.
[14] Apache Software Foundation. Apache Project, 2007. http:
to new contexts. The sophisticated composition engines //www.apache.org.
available today reduce drastically the effort for deploying [15] OASIS. Web Services Business Process Execution Language
remote accessible experiments. Version 2.0, May 2006. Available at http://www.oasis-open.
org.
The architecture also supports the federated operation [16] Sun Microsystems. Java Advanced Imaging (JAI) API, Jan-
of Web Labs. The federation relies on inter-domain au- uary 2007. Available at https://jai.dev.java.net/.
thentication for both users and service calls. A policy-
based authorization scheme provides flexibility on the ac-
cess control of Web Labs. These schemes take advantage

1386
Authorized licensed use limited to: ULAKBIM UASL - Erciyes Universitesi. Downloaded on January 04,2023 at 14:44:19 UTC from IEEE Xplore. Restrictions apply.

You might also like