45mm
M. B\"{o}ge
J. Chrin
Paul Scherrer Institut
5232 Villigen PSI
Switzerland
\phantom{Paul Scherrer Institut, 5232 Villigen PSI, Switzerland}
Beam dynamics applications at the Swiss Light Source (SLS) have benefitted from a distributed computing environment in which the Common Object Request Broker Architecture (CORBA) forms the middleware layer and access point to several different software components. A suite of remote CORBA server objects provides the client with a convenient and uniform interface to the CDEV (Common DEVice) controls library, the TRACY accelerator physics package, the Oracle database, and an event-logging facility. %message and alarm logging facility. Use is made of methods provided by the CORBA Portable Object Adaptor for accessing ORB functions, such as object activation and object persistence, the Implementation Repository for the automatic reactivation of servers, and the CORBA Event Service for the propagation of controls and physics data. %The multi-language software and system components %of the client-server model are described. An account of the CORBA framework, as used by applications in the commissioning and first operation of the SLS, %and the experience gained, is presented.
THAT002.tex
\documentclass[acus]{JAC2000}

%%
%%  Use \documentclass[boxit]{JAC2000}
%%  To draw a frame with the correct margins on the output.
%%
%%  Use \documentclass[acus]{JAC2000}
%%  For US letter paper layout
%%

\usepackage{graphicx}


%%
%%   VARIABLE HEIGHT FOR THE TITLE BOX (default 35mm)
%%

\setlength{\titleblockheight}{45mm}

\begin{document}
\title{\flushright{THAT002}\\[15pt] \centering ON THE USE OF CORBA IN \\ HIGH LEVEL SOFTWARE 
APPLICATIONS AT THE SLS
}

\author{M. B\"{o}ge, J. Chrin \\
Paul Scherrer Institut, 5232 Villigen PSI, Switzerland \\ 
\phantom{Paul Scherrer Institut, 5232 Villigen PSI, Switzerland}\\ 
\phantom{Paul Scherrer Institut, 5232 Villigen PSI, Switzerland}  
}

\maketitle

\hyphenation{suite Event access Broker applications servers server consumers internals 
persistent App-lications ABS Subjects Template Library object CORBA client DSI SII call
BD stubs Interface activations levels hosts}

\begin{abstract}
Beam dynamics applications at the Swiss Light Source (SLS)
have benefitted from a distributed computing environment
in which the Common Object Request Broker Architecture 
(CORBA) forms the middleware layer and access point to
several different software components.
A suite of remote CORBA server objects provides the 
client with a convenient and uniform interface to
the CDEV (Common DEVice) controls library,  
the TRACY accelerator physics package, 
the Oracle database, and
an event-logging facility. 
%message and alarm logging facility.
Use is made of methods provided by the CORBA Portable 
Object Adaptor for accessing ORB functions, such as object 
activation and object persistence, the Implementation Repository 
for the automatic reactivation of servers, and the CORBA 
Event Service for the propagation of controls and physics data.
%The multi-language software and system components 
%of the client-server model are described. 
An account of the CORBA framework, as used by applications 
in the commissioning and first operation of the SLS, 
%and the experience gained, 
is presented. 
\end{abstract}


\section{MOTIVATION}
The Swiss Light Source (SLS) is a synchrotron
light source located at the Paul Scherrer
Institute (PSI) in Switzerland. Its most
major component, a 2.4 GeV electron storage
ring, was recently commissioned and is now
delivering light of high brilliance to
experimenters from multiple disciplines.
Several high-level beam dynamics (BD) applications
%graphical users interfaces (GUI's) 
have been developed for the operation
and monitoring of the SLS accelerator 
facilities. 
%They allow the operator and scientist
%to interpret the state and performance
%of the accelerators and to apply  
%beam orbit correction and optimization
%procedures.
Fig.~\ref{fig_1} captures typical
components required by BD applications.
Their number and demand on 
computer resources motivated, in part, 
a desire for a distribued computing environment. 
To this end, the Common Object Request Broker (CORBA),
an emerging standard for distributed
object computing (DOC), has been employed. 
Its use at the SLS has allowed us to realize
%has not only served to realize
the potential benefits of distributed computing 
and to simultaneously exploit features inherent
to CORBA, such as the interoperability between objects 
of different race (language) and creed (platform).
%object interoperability irrespective of
%language implementation and operating system.
%as the operating system hosts a CORBA
%ORB implementation, and language independence,
%as ensured through the use of the Interface
%Definition Language (IDL), whose compiler
%translates an object interface to any
%language for which a mapping exists.
Complex tasks, such as the modeling
of the SLS accelerators, can thus be handled
by dedicated computers, and developed
into reusable components that 
can be accessed 
through remote method invocations.
Perservering with the notion of DOC 
and developing the entire suite
%the development of all
of BD components as  
CORBA objects, further elevates the level
\begin{figure}[htb]
\vskip 0.05cm
\centering
\includegraphics*[width=82.0mm]{fig1.eps}
\caption{DOC components serving BD applications}
\label{fig_1}
%\vskip 0.04cm
\end{figure}
at which applications are designed and implemented.
%The platforms which host the high-level applications
%are intrinsically integrated in a particluar
Platforms hosting high-level software applications
%is intrinsically limited to a
%single computing language, and 
%in a non-distributed environment 
are no longer limited to the libraries and 
extensions available to the host operating system
as the introduction of a CORBA middleware layer
%that hides the complexity of communication
%and data transfer,
serves to {\it extend} the developers chosen 
programming language. 
%while 
%hiding the complexity of communication
%and data transfer.
BD application 
developers are, henceforth, able to focus on the 
specifics of the application at hand, such as
determining user-friendly graphical
interfaces, rather than struggle with
the intricate internals of numerous application
program interfaces (APIs) and low-level 
communication protocols.
%Tcl/Tk based client applications typically profit from
%specialized GUI widgets provided by the
%Tk/BLT extension, while Java based clients use
%classes constructed from Java Swing components. 
%Specialized tool kits.
%Corba is not a solution to a problem.
%Rather Corba provides the tools
%for developing a DOC system, complete
%with handles for a robust, flexible
%and modular system.
%This paper concentrates on the implementation
%details of the servers. The server contents
%themselves are described in previous work.
%Indeed it is perhaps this capability 
%that has proved a vast attraction.
%High-Level platforms are intrinsically
%tightly integrated in a particular
%programming environment and limited
%to one programming language.
%The idea is to extend an existing
%programming language by introducing
%a new layer in the middle, between
%the network, that hides the complexity
%of communication and data transfer.
%iddleware allows to use
%distribution while sticking
%to the programming environment
%which the developer is used to.
%simply development of distributed applications,
%elevate the level at which applications are
%designed and implemented.
%DOC - advantages
%greater spped by spreading complex
%tasks over many computers working
%in parallel, fault-tolerance by
%using redudant servers, or delegation
%GUI features such as Tcl/Tk and Java
%Clients run on less powerful machines..
%Middleware approach.. introducing a new layer
%into a program that keeps the complexity
%from the developer by hiding as many details
%of distributing programming as necessary.
%To the developer, the middleware presents seemingly
%local objects, and invocations on the local proxy
%cause the necessary data to be transparantly sent to
%the recipient.
%CORBA aspects.. UNIX based,
%however multilanguage component
%is a vast attraction.
%GUI widgets, Tcl/Tk very powerful.
%On the other hand, server components
%in C++
%Middleware allows to use
%distribution while sticking
%to the programming environment
%which the developer is used to.
\section{The CORBA Architecture}
The most fundamental component of CORBA is the 
Object Request Broker (ORB) whose task is
to facilitate communication between objects.
Given an Interoperable Object Reference (IOR), 
the ORB is able to locate target objects and transmit 
data to and fro
%parameters and return values to and from
remote method invocations.
The interface to a CORBA object is 
specified using the CORBA Interface
Definition Language (IDL). 
An IDL compiler translates the IDL definition
into an application programming language,
such as C++ or Java, 
generating IDL stubs and skeletons
that respectively provide the framework
for client-side and server-side proxy code.
Compilation of applications incorporating IDL 
stubs provides a strongly-typed 
Static Invocation Interface (SII).
Conversely,
a more flexible communication mechanism
can be established through the use of
the Dynamic Invocation Interface (DII)
and the Dynamic Skeleton Interface (DSI)
allowing objects to be created without
{\it prior} knowledge of the IDL interface.
In such cases, a description of the interface
is retrieved at runtime from an Interface Repository (IFR),
a database containing the pertinent meta-data. 
Requests and responses between objects
are delivered in a standard format defined 
by the Internet Inter-ORB Protocol (IIOP),
a communications protocol which 
adheres to the CORBA General Inter-ORB Protocol
(GIOP) specification and, as such, 
acts as the base for CORBA interoperability on 
the internet.
Requests are marshaled in a platform
independent format,
%i.e.~converted into a serialized byte stream, 
by the client stub (or in the DII),
and unmarshaled on the server-side 
into a platform specific format by the
IDL skeleton (or in the DSI) and the
object adaptor, which serves as a mediator 
between an object's implementation, 
the servant, and its ORB, 
thereby decoupling user code 
from ORB processing.
In its mandatory version, the 
Portable Object Adaptor (POA)
provides CORBA objects with a common set
of methods for accessing ORB functions,  
ranging from user authentication to object 
activation and object persistence.
It's most basic task, however,
is to create object references and to
dispatch ORB requests aimed at target objects 
to their respective servants. 
The characteristics of the POA
%, other than that of the root POA, 
are defined at creation 
time by a set of POA policies.
A server can host any number of
POAs, each with its own set of policies
to govern the processing of requests.
Among the more advanced features of the
POA is the servant manager 
which assumes the role of reactivating
server objects (servants) as they are required.
It also provides a mechanism to save and restore 
an object's state.
This, coupled with the use of the
Implementation Repository (IMR), 
that handles
the automated start and restart of servers,
realizes object persistency.
%The Active Object Map (AOP) maintains the
%associations between servants and the objects
%they implement.
%Alternatively, 
Requests for server reactivation can,
alternatively, be 
delegated to a single default servant 
which provides implementations for many objects, 
thereby increasing the
%Designed to provide increased
scalability for CORBA servers.
\begin{figure}[htb]
\vskip 0.05cm
\centering
\includegraphics*[width=82.0mm]{fig2.eps}
\caption{The CORBA client-server architecture}
\label{fig_orb}
\vskip 0.04cm
\end{figure}

Fig.~\ref{fig_orb} shows the components
of the CORBA architectural model.
The ORB core is implemented as a runtime
library linked into client-server applications. 

\subsection{Client and Server Perspectives}
Despite the plethora of new terms and concepts
introduced,
% by CORBA may, at first, appear
%disconcerting. {\it Nevertheless}, CORBA
CORBA, nevertheless,
remains true to 
the DOC objective of providing
%DOC in that it provides
developers with familiar object-oriented
techniques with which to program 
distributed applications. 
Indeed, from the client perspective, 
once an IOR 
%a CORBA object reference 
is obtained (typically from a Naming Service
which maps names to object references)
a remote method invocation 
essentially takes on the welcoming
appearance of a local function call:
\texttt{\small object-$>$operation(arguments);}
%object-\>operation(arguments);
%as illustrated in Fig.~\ref{fig_op}.
%\begin{figure}[htb]
%\vskip 0.05cm
%\centering
%\includegraphics*[width=82.0mm]{operation1.eps}
%\caption{The CORBA two-way communication model.}
%\label{fig_op}
%\vskip 0.04cm
%\end{figure}
%The standard format for an object reference 
%is the Interoperable Object Reference (IOR)
%and that for the communnications protocol
%between ORBs is the Internet Inter-ORB Protocol
%(IIOP).
% the IOR holds information ..
%
% Event Service
%
%Persistent objects
%
%Implementation Repository
%
%whose
%task is to associate an object 
%with a particular servant,
%Of particluar interest, is the ability to
%develop servers with multiple object
%adaptors each with its own set of 
%request processing as determined through
%use of POA policies. 
%Among the variety of options
%whose task is to direct requests to the servant,
%the CORBA component that implements the
%operations defined by the IDL interface.
%Return values are returned along the same path.
%The ORB core is implemented as a runtime
%library linked into client-server applications.
%Corba applications and components are thus
%independent of the language used to implement 
%them.
%Platform and language independence a rarity
%in the software realm. 
%Parameters are converted upon transmission into
%a platform independent format and converted
%into a platform-specific format upon receipt.
%\subsection{Client and Server Perspectives}
whilst the communication details of 
client-server programming 
are essentially hidden from the client,
a more intimate involvement with the ORB
is required when developing servers.
In particular appropriate POA policies need 
to be chosen to configure object adaptors
that best fufill the requirements of the
server.
%for the their intended task.
\subsection{Power to the POA}
Transient and persistent objects
are two categories of objects that relate to the
%the TRANSIENT and PESISTENT 
lifespan policies of the POA.
%as is required to realize persistency.
%Persistent objects are those that outlive
%The Persient objects,
%advantage over transient objects:
%- shut down a server to save resources when
%server is not needed
%- update an implementation transparantly by
%restarting a server
%- recover from a system crash
A transient object is short-lived with a lifetime
that is bounded by the POA in which it was created.
A persistent object, on the other hand, is long-lived 
with a lifetime that is unbounded. It can consequently
outlive the very server process wherein it was created.
%The server 
%in which a persistent object is created can be started
%stopped and restarted multiple times.
%Server objects created at the SLS are typically
%of the persistent type. 
This has several advantages.
A server may be shutdown whenever it is not
needed to save resources. Server updates can be
implemented transparantly by restarting the server.
In developing a DOC environment, the command to start 
a server may be replaced with a remote shell invocation
and the next server instance run remotely, without
the client being aware. Persistent objects also
maintain their identify after a server crash.
%If the command to start the server
%is replaced with a remote shell invocation, the next
%instance of the server will be run remotely and the client
%will not notice.
Whilst the POA supports and implements persistent objects,
it does not handle the administrative aspects of server 
activations.
%the servers in which these objects are first created
%must be started manually or by the adminstrative .
This is managed by the IMR which
%Here the IMR is put into good effect.
%\subsection{Implementation Repository}
%Implementation Repository allows for coarse-grained
%mobility of servers. 
%bootstrapping problem. In order to create object references
%and to export them, for example by entering them in the
%Naming Service, the first instance of the server has to be
%started manually.
%The IMR stores details about each server process.
%At its most basic level, 
%The IMR is effectively 
stores an activation 
record for each server process; it is consulted 
automatically whenever a (re-)launch of a server is mandated.
%This is precisely the info needed by the ORB daemon, 
%the IMR is effectively a
%database used by the ORB deamon.
\begin{figure}[htb]
\vskip 0.05cm
\centering
\includegraphics*[width=82.0mm]{fig3.eps}
\caption{Server activation through the IMR}
\label{fig_imr}
\vskip 0.04cm
\end{figure}
%The purpose of 

Fig.~\ref{fig_imr} illustrates the role of the IMR
in the (re-)activation of servers. 
The first instance of the server is started by an
administrative procedure (imr activate) and object 
references, 
pointing to the POA Mediator within the ORB daemon process, 
%which point to the ORB daemon process (IOR ORBd), 
are exported to the Naming 
Service \mbox{(step~1)}.
The ORB daemon listens
%is to listen
for CORBA client connection attempts and
assists the client in connecting to its destined server.
This is done through the POA Mediator whose task is
to intercept initial client requests, 
% whenever the server is off-line, 
to (re-)activate the server if so required, and to
forward the actual server location 
to the client for all subsequent operations  
(step 2).
Thus, by virtue of the capabilities of the POA,
and the activation techniques of the IMR,
BD applications are never starved of the
servers they require.
 
\subsection{The Event Service}
%Fig.~\ref{fig_1} illustrates 
%In addition to the standard CORBA synchronous 
%request/response communication model,
A reactive, event-based, form of programming is 
also supported by the CORBA Event Service 
%using the event channel abstraction.
%The Event Service 
which provides services for the creation 
and management of CORBA event channels.  
These may be used by CORBA
supplier/consumer clients to propagate events asynchronously on a
push or pull basis. Event channels are created and registered with
the CORBA Naming Service allowing clients to obtain object
references in the usual manner. Communication is anonymous in that
the supplier does not require knowledge of the receiving consumers.
Publicized inadequacies of the Event Service are a lack of
explicit quality of service (QoS) control, the necessity of
propagating event data with type {\it CORBA::any}, and the absence of
event filtering. Nevertheless, by applying 
a few simple design techniques, 
these limitations can be largely circumvented and
the CORBA Event Service has been usefully employed in the monitoring
of hardware devices and in the distribution of recalibrated data 
to client consumers.
The CORBA Event Service is ultimately to be replaced by
the CORBA Notification Service which systematically 
addresses the shortcomings of the Event Service.
% and is to eventually replace it. 
%A significant difference is the introduction of the
%structured event type, making it possible to distinguish
%between different event types.


%This scenario shows a client connecting to a
%server, On the server machine (Unix host)
%there is an ORB daemon process running in the
%background. The CORBA server is dormant
%but the information need to actiavte it is
%stored in the IMR.
%Client opens a network connection to the
%remote ORB daemon and asks it for the server
%location details.
%This step presupposes that the client is able
%to find the ORB daemon in the first place.
%[Many ORBS perform this step using
%a proprietry approach]. For example
%the client might assume that the ORB d is
%listening in a standard IP port number.
%If the server is dormant, the ORB d retrieves the
%servers activation record from the IM and uses
%thss info to activate the server.
%Using the location info retrieved in step 1 the 
%client can now open a network connection to
%the server and begin sending invocation requests.
%The server has already been activated (manually started
%by an administaror).
%ORB daemon has some way of tracking the CORBA server process
%activated 
%Use of the IMR,
%coupled with the Persistent Object Policy and
%servant manger results in true Object persistency.
%Never Say Never Gain.
%SLS Servers are there when needed and
%dormant when not.
%Servant: a Servant class is a class that
%provides the implemntation of an IDL
%interface-
%AOM is a lookup table that is built into a POA.
%It associates object IDs to a servant.
%POA POlicies provide a generic mechanism for
%configuring an ORB
%servant managers - incarnation and etherealization
%helps manage and activate the lifecycle and
%activation of servant objects, declaring
%incar and ether operations..
%Servers can choose an object adaptor that
%best fullfills its requirement.
%C++ abstract base classes,
%- shutdown, syslog, debug, host information
%virtual inheritance Exception handling,
%Java is a viable alternative, 
%garbage collecttion..
%\subsection{The Administrators Perspective}
%bootstrapping, 
%imr activate
%Shell scripts
%\section{The SLS CORBA Servers}
\section{Server Synopsis}

%The server objects developed each provide an 
%interface to a specific third party software
%package. 
Server objects, typically of persistent type, 
have been developed using the CORBA product
MICO~\cite{ref_mico01}, a fully compliant 
implementation of the CORBA 2.3 standard.
The services these objects provide are briefly 
reported here. An expanded description,  
together with the specifications of the hardware
and system components of the server hosts,
appears elsewhere~\cite{ref_pcapac00}.
%The present status of the servers is briefly reported here.

%Nevertheless, despite
%their difference in tasks, they
%inherit from a base class,
%share similar diagnostics -
%ability to turn on/off the debugger
%message logger - debug level -
%hostname - shutdown method;

\subsection{The Accelerator Model}
A dedicated host runs the servers
that perform the computer intensive 
modeling of the SLS accelerators.
Procedures utilise the complete 
TRACY accelerator physics library, 
enabling clients to employ 
accelerator optimization
procedures {\it online}.

\subsection{Device Controls}
The CDEV C++ class controls library 
provides the API to the EPICS-based 
accelerator device control system. 
The CDEV server supplies 
functionality for both synchronous and 
asynchronous interactions with the control system.
Monitored devices and recalibrated data 
are propagated to clients through CORBA event channels.
%The CORBA Event Service has been usefully employed in the monitoring
%of hardware devices and in the distribution of recalibrated data 
%to client consumers.
%\subsection{Serving Clients through Events}

\subsection{Making a Statement with CORBA}
A database server provides access to
Oracle instances through the Oracle Template
Library (OTL) and the Oracle Call Interface (OCI).
Methods executing  
SQL statements that perform database retrieval and 
modification operations have been provided.
%The storage of online data is mediated through 
%OTL datatypes that map into Orable BLOBs 
%(Binary Large Objects.) 
Interestingly, database access through the 
CORBA interface ({\it with} data marshaling)
takes half the time than that 
through the JDBC API.


%subsection{Fault Tolerance}
\subsection{Monitoring Servers and Applications}
%Each component of an application, from the
%user interface program to the server,
%requires access to an event-logging
%facility in order to report messages
%and alarms that are generated at run-time. 
A CORBA message server has been developed
using the the UNIX syslog
logging facility, profiting directly
from the reliability of standard
UNIX services. 
Run-time messages are sent to the logger with
various priority levels, the threshold
for which can be adjusted dynamically
for any given servant.
This is particularly useful
during the development stage, where 
for instance, debugging
%This has proved particularly useful
%in the development stage, 
can be activated  
without the need to recompile.
%Syslog entries are also inserted
%into the Oracle database. 
%Messages dispatched follow a standard format
%that reveal a minimal amount of
%information about a remote event.
%This includes the exact location of the event 
%source, the event priority and an error code 
%accompanied with text message.
%They can be viewed either through
%a Tcl/Tk browser that polls the log
%files or the native database browser
%which retrieves data from the 
%corresponding database table.

%A debugger - without complilation -
%logging and displaying, throughout the
%various stages of the project; design,
%development and deployment.
%Clients can vary the level of error messages
%for debugging.
%An event logging facility that can be used
%in the various stages of a project 
%Dynamic.. Error Message Reporting
%and debugging


\section{SLS STORAGE RING OPERATION}
Several applications, written mainly in
Tcl/Tk or Java, 
have been successfully introduced 
for the commissioning
and operation of the SLS booster and
storage rings \cite{ref_pac01},
making ample use of the CORBA
%client-server
framework provided. Server objects were
extensively tested through 
invocations initiated by a variety of
client processes. Operator intervention was 
minimal with clients able to interact 
spontaneously with the many servers and to 
  display their event data.
This is exemplified 
%The latter is well demonstrated
%is the 
%A pleasing demonstration of the justification
%of the framework
%One of the most major successes has been the
%Of particularly appeal is the 
%Continual usage of server objects
%is well demonstrated by the
%demonstration of
%server objects in continual use by the
%is the implementation of a 
by the slow global orbit feedback system
(3 Hz sampling rate),
which is both a consumer to event generated data 
and a party to remote methods invocations on a 
variety of servers. 
%A fast version is planned (for 
%which dedicated
%low-level hardware providing an orbit sampling rate of \~ 4 kHz 
%is to be installed) that
%will challenge the reaches of our model
A fast version, for which dedicated
low-level hardware is to be installed
(4 kHz sampling rate),
will challenge the reaches of our model \cite{ref_abs01}.

%First Experience. Very good.
%event daemon, notification service.
%Developing Interfaces - fat operations - 
%interfaces that serve the server
%or client..
%general purpose interfaces; inefficient
%but convenient - nightmare..
%\section{WHAT NEXT?}
%Notification Server
%Corba 3.
%POA, default server...
%hashing
%An interesting feature is the integration of the
%fast Orbit FB (4 kHz) \cite{ref_abs01}

\section{CONCLUSION}
The CORBA middleware has
served to extend the capabilities
of the programming languages used 
by BD application developers,
thereby elevating the level
at which high-level software 
applications are designed and 
implemented.
The power and flexibility of the POA,
coupled with the server activation records
stored within the IMR, has been exploited to
provide a robust and modular 
CORBA based client-server framework.
The model has been proved to be both
reliable and stable by the 
many applications deployed
%that have made 
%ample use of the server objects
in the commissioning
and first operation of the SLS.



\begin{thebibliography}{9}

\bibitem{ref_mico01}
MICO, http://www.mico.org/ 

\bibitem{ref_pcapac00}
%M.~B\"{o}ge, J.~Chrin,  
%``CORBA Objects for SLS Subjects'', 
%Proc. 3rd Int. Work. on Personal Computers
%and Particle Accelerator Controls~(PCaPAC 2000), 
%Oct.~9-12,~2000, DESY, Hamburg, Germany;
PCaPAC 2000 (ID:054), http://desyntwww.desy.de/pcapac/
%//desyntwww.desy.de/pcapac/Proceedings/default.htm
%and references therein.


\bibitem{ref_pac01}
%M.~B\"{o}ge, J.~Chrin, M.~Mu\~{n}oz, A.~Streun, 
%\\
PAC~2001~(ID:TOPB012), 
http://pac2001.aps.anl.gov/


\bibitem{ref_abs01}
M.~B\"{o}ge,  J.~Chrin, M.~Mu\~{n}oz, A.~Streun,
%``CORBA Based ABS Applications at the SLS'',
%Automated Beam Steering and Shaping Workshop (ABS~2001),
%Dec.~3-4,~2001, San Jose, California, USA;
ABS~2001, 
\\
http://www-project.slac.stanford.edu/abs2001/



\end{thebibliography}


\end{document}




physics0111005.extracted_bib
\begin{thebibliography}{9}

\bibitem{ref_mico01}
MICO, http://www.mico.org/ 

\bibitem{ref_pcapac00}
%M.~B\"{o}ge, J.~Chrin,  
%``CORBA Objects for SLS Subjects'', 
%Proc. 3rd Int. Work. on Personal Computers
%and Particle Accelerator Controls~(PCaPAC 2000), 
%Oct.~9-12,~2000, DESY, Hamburg, Germany;
PCaPAC 2000 (ID:054), http://desyntwww.desy.de/pcapac/
%//desyntwww.desy.de/pcapac/Proceedings/default.htm
%and references therein.


\bibitem{ref_pac01}
%M.~B\"{o}ge, J.~Chrin, M.~Mu\~{n}oz, A.~Streun, 
%\\
PAC~2001~(ID:TOPB012), 
http://pac2001.aps.anl.gov/


\bibitem{ref_abs01}
M.~B\"{o}ge,  J.~Chrin, M.~Mu\~{n}oz, A.~Streun,
%``CORBA Based ABS Applications at the SLS'',
%Automated Beam Steering and Shaping Workshop (ABS~2001),
%Dec.~3-4,~2001, San Jose, California, USA;
ABS~2001, 
\\
http://www-project.slac.stanford.edu/abs2001/



\end{thebibliography}