%% Mpodif; FO %ADASS_PROCEEDINGS_FORM%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % SAMPLE1.TEX -- ADASS XII (2002) ASP Conference Proceedings sample % paper with minimal markup. Based on the sample from ADASS XI (01). % % This is a simple example. If you want to see a more comprehensive % sample paper, take a look at sample2.tex. % % Much of the input will be enclosed by braces (i.e., { }). The % percent sign, "%", denotes the start of a comment; text after it % will be ignored by LaTeX. You might also notice in some of the % examples below the use of "\ " after a period; this prevents LaTeX % from interpreting the period as the end of a sentence and putting % extra space after it. % % You should check your paper by processing it with LaTeX. For % details about how to run LaTeX as well as how to print out the User % Guide, consult the README file. % % If you do not have access to the LaTeX software or a laser printer % at your site, you can still prepare your paper following the % instructions in the User Guide. In such cases, the editors will % process the file and make any necessary editorial adjustments. % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % \documentclass[11pt,twoside]{article} % Leave intact \usepackage{adassconf} \begin{document} % Leave intact %----------------------------------------------------------------------- % Paper ID Code %----------------------------------------------------------------------- % Enter the proper paper identification code. The ID code for your % paper is the session number associated with your presentation as % published in the official ADASS 2000 conference proceedings. You can % find this number locating your abstract in the printed proceedings % that you received at the meeting or on-line via % http://adass2002.stsci.edu; the ID code is the letter/number sequence % proceeding the title of your presentation. % % This will not appear in your paper; however, it allows different % papers in the proceedings to cross-reference each other. Note that % you should only have one \paperID, and it should not include a % trailing period. \paperID{P1-23} %%%% ID=P1-23 %----------------------------------------------------------------------- % Paper Title %----------------------------------------------------------------------- % Enter the title of the paper. \title{Transparent XML Binding using the ALMA Common Software (ACS) Container/Component Framework} \titlemark{Transparent XML Binding using ACS} %----------------------------------------------------------------------- % Authors of Paper %----------------------------------------------------------------------- % Enter the authors followed by their affiliations. The \author and % \affil commands may appear multiple times as necessary. List each % author by giving the first name or initials first followed by the % last name. Authors with the same affiliations should grouped % together. % % Try to limit the front matter to no more than three \author % commands. Group authors with the same affiliations. Too many % \author commands fills the first page of the paper with little % actual text. \author{Heiko Sommer and Gianluca Chiozzi} \affil{European Southern Observatory, Karl-Schwarzschild-Stra{\ss}e 2, D-85748 Garching b.~M\"unchen, Germany, Email:~hsommer@eso.org} \author{David Fugate} \affil{National Radio Astronomy Observatory, 1003 Lopezville Rd., NM~87801, USA} \author{Matej Sekoranja} \affil{Cosylab Ltd, Teslova 30, SI-1000 Ljubljana, Slovenia} %\altaffiltext{1}{Physics Department, The Duck Institute} %----------------------------------------------------------------------- % Contact Information %----------------------------------------------------------------------- % This information will not appear in the paper but will be used by % the editors in case you need to be contacted concerning your % submission. Enter your name as the contact along with your email % address. \contact{Heiko Sommer} \email{hsommer@eso.org } %----------------------------------------------------------------------- % Author Index Specification %----------------------------------------------------------------------- % Specify how each author name should appear in the author index. The % \paindex{ } should be used to indicate the primary author, and the % \aindex for all other co-authors. You MUST use the following % syntax: % % SYNTAX: \aindex{LASTNAME, F. M.} % % where F is the first initial and M is the second initial (if % used). This guarantees that authors that appear in multiple papers % will appear only once in the author index. \paindex{Sommer, H.} \aindex{Chiozzi, G.} \aindex{Fugate, D.} \aindex{Sekoranja, M.} %----------------------------------------------------------------------- % Subject Index keywords %----------------------------------------------------------------------- % Enter up to 6 keywords describing your paper. These will NOT be % printed as part of your paper; however, they will be used to % generate the subject index for the proceedings. There is no % standard list; however, you can consult the indices for past ADASS % proceedings (http://iraf.noao.edu/ADASS/adass.html). \keywords{software: architecture, XML: binding, Java, component, container, ACS, CORBA} %----------------------------------------------------------------------- % Abstract %----------------------------------------------------------------------- % Type abstract in the space below. Consult the User Guide and Latex % Information file for a list of supported macros (e.g. for typesetting % special symbols). Do not leave a blank line between \begin{abstract} % and the start of your text. \begin{abstract} % Leave intact ALMA software, from high-level data flow applications down to instrument control, is built using the ACS framework. The common architecture and infrastructure used for the whole ALMA software is presented at this conference in (Schwarz, Farris, \& Sommer 2004). ACS offers a CORBA-based container/component model and supports the exchange and persistence of XML data. For the Java programming language, the container integrates transparently the use of type-safe Java binding classes to let applications conveniently work with XML transfer objects without having to parse or serialize them. This paper will show how the ACS container/component architecture serves to pass complex data structures, such as observation meta-data, between heterogeneous applications. \end{abstract} %----------------------------------------------------------------------- % Main Body %----------------------------------------------------------------------- % Place the text for the main body of the paper here. You should use % the \section command to label the various sections; use of % \subsection is optional. Significant words in section titles should % be capitalized. Sections and subsections will be numbered % automatically. % The reference system to be followed is the standard ApJ system: author name(s) % followed by the year in parentheses, as in Abt (1990), or author and year both in % parentheses (Abt 1990). Multiple authors would be cited as (Groth & Pebbles % 1971) or (Kron, Hewitt, & Wasserman 1984). For more that three authors use %ôet al.,ö e.g., (Press et al. 1994). % too bad, but with the 4 page limit, I have to take this out... %\section{Introduction} % XML is a well-established format for transporting hierarchical data by value, e.g.~using web service technologies. % Significant parts of ALMA (meta-) data will be exchanged and archived as XML transfer objects. % A common drawback of applications processing XML data is that parsing and data access rely on runtime string matching; % this circumvents compile time type checking, resulting in fragile software. % XML binding frameworks generate custom Java classes whose instances form a tree that represents an XML document in memory. % All element and attribute data is then accessed through type-safe methods. % Application code will be coerced by the compiler to follow any changes in the data model that is defined in XML schemas. % With framework support for binding classes as described so far, application code would still encounter serialized XML at the upper interface level; % for example, Java web service implementations receive XML data as generic strings, even if they subsequently turn these strings into a tree of XML binding objects. % As we will see, ACS removes this top-level type ambiguity and allows Java components to solely work with binding classes, without ever having to parse or serialize XML. The component developer does not even need to know that XML is the underlying interchange data format. \section{XML Data by Value} \label{P1-23-SecXMLByValue} In any distributed software system, it is vital to reduce the number of fine-grained calls accessing remote data. The usual strategy is to pack together some cohesive set of data items and transmit them over the network at once. This has been described in the \htmladdnormallinkfoot{J2EE Transfer Object Pattern} {http://java.sun.com/blueprints/corej2eepatterns/\linebreak[1]Patterns/\linebreak[1]TransferObject.html}% , or in (Fowler 2002). The gained performance has to be traded in for a somewhat compromised OO design though. Transporting groups of data by value not only helps avoid network congestions and improve overall system performance; migrating such data from one machine to another also decouples the two computers, which adds to the robustness of the system. If the computer which originally supplied the data goes down, the other machine will not be affected if it has retrieved all required data by value before. Since ALMA software will be implemented in various languages (currently C++, Java, Python), CORBA was chosen as the middleware the ACS framework is built upon. There are several possibilities to transport data by value using CORBA. In the past, for the sake of language independence, CORBA architecture focused on remote service invocations or by-value transport of {\em simple} data types (primitive data or structs of primitive data); recently it has started to offer a means for transporting more complex data structures by-value, using \htmladdnormallinkfoot{CORBA value types}{http://www.omg.org/cgi-bin/doc?formal/02-06-41}. For several reasons we decided to use XML as the format for ALMA transfer objects: \begin{itemize} \item XML avoids difficulties with CORBA's built-in types described in (Schmidt \& Vinoski 2001); \item XML as a serialization format can be used not only to send data by value between applications, but also to store that data persistently in a file or a database; \item XML schema allows for data declaration (constraints etc.) more powerful than those available using CORBA value types; \item XML data can be logged directly, and can easily be injected manually into the software system, for example for running unit tests, or to mimic an application that has not yet been built. \end{itemize} \noindent %%FO ALMA subsystems specify their interfaces in CORBA IDL. To send simple data by value, the built-in data types of CORBA can be used. For more complex, usually hierarchical data, the data definition can be provided outside of the IDL in an XML schema file, and has to be referenced in the IDL. Thus the architecture lets ALMA developers choose between sending data through efficient binary CORBA transport, or using somewhat slower, but more powerful XML plain-text transport. The latter option is expected to be chosen for nested structures such as an observing project and its scheduling blocks, where the size is less than 100 kB. XML transport is realized in IDL with a CORBA {\tt struct} containing a {\tt string} for the serialized XML, plus complementary administration meta data, e.g.\ a unique ID. Very large data structures should be broken up into smaller groups, each described by its own XML schema. For example, the observing project, the proposal, and the scheduling blocks are each modeled separately. A balance must be found between quickly accessing large parts of the data tree in one call, and not transporting too much data at a time when only a part of it is needed. The resulting separate pieces of XML data reference each other using their unique IDs. %\section{ALMA Container/Component Model} %ALMA application software is considerably freed from technical concerns like remote communication or multi-language %interoperability, which are handled by the ACS framework. %A key concept to achieve the separation of technical and functional concerns is the container/component model, which is %described in \paperref{O8-1}. %ACS offers containers for the languages Java, Python, and C++. %Application software is written and deployed as components. A component %\begin{itemize} % \item has a \emph{Lifecycle interface} through which the container controls the component's initialization and termination, in collaboration with a central deployment manager (see XXX) % \item has a \emph{functional interface} derived from CORBA IDL; clients (e.g.~other components) invoke methods independently of the respective programming languages % \item can use services offered by the container in the form of a library, and % \item can have primitive or composite IDL types as method parameters, as well as %\end{itemize} \section{XML-Java Binding Classes} XML binding frameworks generate native language binding classes from XML schemas as part of the build process. The binding class instances form in-memory representations of XML documents that belong to the schemas. In Fig.~\ref{P1-23-BindClEclipse} we see the classes compiled from the scheduling block schema. \begin{figure} \epsscale{.70} \plotone{P1-23_0.eps} \caption{Generated binding classes seen in the Eclipse IDE.} \label{P1-23-BindClEclipse} \end{figure} Applications are written against the type-safe accessor and manipulator methods of these binding classes, thus getting coerced by the compiler to follow any changes in the data model, defined in the schemas. %ALMA software components written in Java use binding classes to work with XML data. Note that with the standard representations of XML (such as DOM), application code would contain generic calls like {\tt addChildNode} instead of {\tt add\-PhaseCal\-Target}, thus defying compile time checking. ACS harnesses \htmladdnormallinkfoot{Castor}{http://www.castor.org/xml-framework.html} for XML binding. Another potential candidate, SUN's \htmladdnormallinkfoot{JAXB}{http://java.sun.com/xml/jaxb/}, unfortunately lacks the ability to serialize and parse incomplete XML data. For C++ and Python, we have not yet found satisfactory binding frameworks. \section{Transparent Serialization} ALMA software is written as components that run inside ACS containers, as described in (Schwarz et.al.\ 2004). Each component specifies and implements one CORBA IDL interface; the methods of that interface may use XML data as parameters or return values (see section \ref{P1-23-SecXMLByValue}). However, with a straightforward approach, both the client and the component implementation would encounter XML as a string rather than as a collection of binding class instances. %At either client or server end of an inter-component method invocation, a straightforward implementation would require Java application code to translate between an XML string and the corresponding Java binding class. \begin{figure} \epsscale{.60} \plotone{P1-23_1.eps} \caption{Classes with XML data. To the (green-)shaded classes, XML data appears as binding classes, to others as serialized {\tt string}s.} \label{P1-23-TranspXmlClassDiag} \end{figure} In Fig.~\ref{P1-23-TranspXmlClassDiag}, we see the ``Transparent-XML'' interface, which ACS generates using a custom IDL compiler. It resembles the output of the standard IDL compiler (``Operations-IF''), except that binding classes are substituted for XML-strings. Independently of each other, the component or one of its clients may be programmed against that interface. The container will in this case receive the ``flat'' XML string from the CORBA ORB, instantiate the appropriate binding classes in its mapping layer, and pass them on to the application. The tedious task of XML parameter conversion is removed from the application code, and the developers can trust the compiler that at runtime no XML data of unexpected format will be received. The component developer does not even need to know that XML is the underlying interchange data format. Communication between collocated components can be shortcut by their container, so that binding class instances are passed without going through the serialization-parsing cycle. The presented ADASS poster is available at \htmladdURL{http://www.eso.org/\linebreak[1]projects/\linebreak[1]alma/\linebreak[1]develop/\linebreak[1]acs/\linebreak[1]OtherDocs/\linebreak[1]ACSPapersAndSlides/index.html}. It contains diagrams that will further illustrate the technique. % You can also add an acknowledgments section as indicated below. %\acknowledgments %My cats, Hal and Yoda, provided motivation for the initiation of this study. %----------------------------------------------------------------------- % References %----------------------------------------------------------------------- % List your references below within the reference environment % (i.e. between the \begin{references} and \end{references} tags). % Each new reference should begin with a \reference command which sets % up the proper indentation. Observe the following order when listing % bibliographical information for each reference: author name(s), % publication year, journal name, volume, and page number for % articles. Note that many journal names are available as macros; see % the User Guide for a listing "macro-ized" journals. % % Note the following are some of the tricks that can be used: % % o \& is used to format an ampersand symbol (&). % o \'e puts an accent grave over the letter e. See the User Guide % for details on formatting special characters. % o "\ " after a period prevents LaTeX from interpreting the period % as an end of a sentence. % o \aj is a macro that expands to "Astron. J." See the User Guide % for a full list of journal macros % o \adassvii is a macro that expands to the full title, editor, % and publishing information for the ADASS VII conference % proceedings. Such macros are defined for ADASS conferences I % through IX. % o When referencing a paper in the current volume, use the % \adassix and \paperref macros. The argument to \paperref is % the paper ID code for the paper you are referencing. See the % note in the "Paper ID Code" section above for details on how to % determine the paper ID code for the paper you reference. % \begin{references} \reference Fowler, M.\ 2002, Patterns of Enterprise Application Architecture (Addison-Wesley Pub Co) \reference Schmidt, D.~C.\ \& Vinoski, S.\ 2001, CORBA and XML, Parts \htmladdnormallink{1}{http://www.cuj.com/documents/s=7995/cujcexp1905vinoski/} \htmladdnormallink{2}{http://www.cuj.com/documents/s=7993/cujcexp1907vinoski/} \htmladdnormallink{3}{http://www.cuj.com/documents/s=7990/cujcexp1910vinoski/}, C/C++ Users Journal \reference Schwarz, J., Farris, A., \& Sommer, H.\ 2004, ``The ALMA Software System'', \adassxiii, \paperref{O8-1}\ok \end{references} % Do not place any material after the references section \end{document} % Leave intact