| |
| |
| |
| |
| |
| |
| |
| |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
| <meta name="keywords" content="SMILA/Project Concepts/BPEL Pipelining Concept" /> |
| <link rel="shortcut icon" href="http://wiki.eclipse.org/SMILA/Project_Concepts/favicon.ico" /> |
| <link rel="search" type="application/opensearchdescription+xml" href="http://wiki.eclipse.org/opensearch_desc.php" title="Eclipsepedia (English)" /> |
| <link rel="alternate" type="application/rss+xml" title="Eclipsepedia RSS Feed" href="http://wiki.eclipse.org/index.php?title=Special:Recentchanges&feed=rss" /> |
| <link rel="alternate" type="application/atom+xml" title="Eclipsepedia Atom Feed" href="http://wiki.eclipse.org/index.php?title=Special:Recentchanges&feed=atom" /> |
| |
| |
| <title>SMILA/Project Concepts/BPEL Pipelining Concept - Eclipsepedia</title> |
| |
| <style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "/skins/eclipsenova/novaWide.css?116"; /*]]>*/</style> |
| <link rel="stylesheet" type="text/css" media="print" href="http://wiki.eclipse.org/skins/eclipsenova/eclipsenovaPrint.css?116" /> |
| <link rel="stylesheet" type="text/css" media="handheld" href="http://wiki.eclipse.org/skins/eclipsenova/handheld.css?116" /> |
| <link rel="stylesheet" type="text/css" href="http://wiki.eclipse.org/skins/eclipsenova/Nova/css/header.css" media="screen" /> |
| <link rel="stylesheet" type="text/css" href="http://wiki.eclipse.org/skins/eclipsenova/tabs.css" media="screen" /> |
| <link rel="stylesheet" type="text/css" href="http://wiki.eclipse.org/skins/eclipsenova/Nova/css/visual.css" media="screen" /> |
| <link rel="stylesheet" type="text/css" href="http://wiki.eclipse.org/skins/eclipsenova/Nova/css/layout.css" media="screen" /> |
| <link rel="stylesheet" type="text/css" href="http://wiki.eclipse.org/skins/eclipsenova/Nova/css/footer.css" media="screen" /> |
| <!--[if IE]><link rel="stylesheet" type="text/css" href="/skins/eclipsenova/IEpngfix.css" media="screen" /><![endif]--> |
| <!--[if lt IE 5.5000]><style type="text/css">@import "/skins/eclipsenova/IE50Fixes.css?116";</style> <![endif]--> |
| <!--[if IE 5.5000]><style type="text/css">@import "/skins/eclipsenova/IE55Fixes.css?116";</style><![endif]--> |
| <!--[if IE 6]><style type="text/css">@import "/skins/eclipsenova/IE60Fixes.css?116";</style><![endif]--> |
| <!--[if IE 7]><style type="text/css">@import "/skins/eclipsenova/IE70Fixes.css?116";</style><![endif]--> |
| <!--[if lt IE 7]><script type="text/javascript" src="/skins/common/IEFixes.js?116"></script> |
| <meta http-equiv="imagetoolbar" content="no" /><![endif]--> |
| <script type= "text/javascript">/*<![CDATA[*/ |
| var skin = "eclipsenova"; |
| var stylepath = "/skins"; |
| var wgArticlePath = "/$1"; |
| var wgScriptPath = ""; |
| var wgScript = "/index.php"; |
| var wgServer = "http://wiki.eclipse.org"; |
| var wgCanonicalNamespace = ""; |
| var wgCanonicalSpecialPageName = false; |
| var wgNamespaceNumber = 0; |
| var wgPageName = "SMILA/Project_Concepts/BPEL_Pipelining_Concept"; |
| var wgTitle = "SMILA/Project Concepts/BPEL Pipelining Concept"; |
| var wgAction = "view"; |
| var wgRestrictionEdit = []; |
| var wgRestrictionMove = []; |
| var wgArticleId = "15162"; |
| var wgIsArticle = true; |
| var wgUserName = null; |
| var wgUserGroups = null; |
| var wgUserLanguage = "en"; |
| var wgContentLanguage = "en"; |
| var wgBreakFrames = false; |
| var wgCurRevisionId = "284632"; |
| var wgVersion = "1.12.0"; |
| var wgEnableAPI = true; |
| var wgEnableWriteAPI = false; |
| /*]]>*/</script> |
| |
| <script type="text/javascript" src="http://wiki.eclipse.org/skins/common/wikibits.js?116"><!-- wikibits js --></script> |
| |
| <!-- Performance mods similar to those for bug 166401 --> |
| <script type="text/javascript" src="http://wiki.eclipse.org/index.php?title=-&action=raw&gen=js&useskin=eclipsenova"><!-- site js --></script> |
| |
| <!-- Head Scripts --> |
| <script type="text/javascript" src="http://wiki.eclipse.org/skins/common/ajax.js?116"></script> |
| <style type="text/css">/*<![CDATA[*/ |
| .source-java {line-height: normal; font-size: medium;} |
| .source-java li {line-height: normal;} |
| /** |
| * GeSHi Dynamically Generated Stylesheet |
| * -------------------------------------- |
| * Dynamically generated stylesheet for java |
| * CSS class: source-java, CSS id: |
| * GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) |
| */ |
| .source-java .de1, .source-java .de2 {font-family: 'Courier New', Courier, monospace; font-weight: normal;} |
| .source-java {} |
| .source-java .head {} |
| .source-java .foot {} |
| .source-java .imp {font-weight: bold; color: red;} |
| .source-java .ln-xtra {color: #cc0; background-color: #ffc;} |
| .source-java li {font-family: 'Courier New', Courier, monospace; color: black; font-weight: normal; font-style: normal;} |
| .source-java li.li2 {font-weight: bold;} |
| .source-java .kw1 {color: #7F0055; font-weight: bold;} |
| .source-java .kw2 {color: #7F0055; font-weight: bold;} |
| .source-java .kw3 {color: #000000; font-weight: normal} |
| .source-java .kw4 {color: #7F0055; font-weight: bold;} |
| .source-java .co1 {color: #3F7F5F; font-style: italic;} |
| .source-java .co2 {color: #3F7F5F;} |
| .source-java .co3 {color: #3F7F5F; font-style: italic; font-weight: bold;} |
| .source-java .coMULTI {color: #3F5FBF; font-style: italic;} |
| .source-java .es0 {color: #000000;} |
| .source-java .br0 {color: #000000;} |
| .source-java .st0 {color: #2A00ff;} |
| .source-java .nu0 {color: #000000;} |
| .source-java .me1 {color: #000000;} |
| .source-java .me2 {color: #000000;} |
| |
| /*]]>*/ |
| </style> |
| <style type="text/css">/*<![CDATA[*/ |
| @import "/index.php?title=MediaWiki:Geshi.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000"; |
| /*]]>*/ |
| </style><style type="text/css">/*<![CDATA[*/ |
| .source-xml {line-height: normal; font-size: medium;} |
| .source-xml li {line-height: normal;} |
| /** |
| * GeSHi Dynamically Generated Stylesheet |
| * -------------------------------------- |
| * Dynamically generated stylesheet for xml |
| * CSS class: source-xml, CSS id: |
| * GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) |
| */ |
| .source-xml .de1, .source-xml .de2 {font-family: 'Courier New', Courier, monospace; font-weight: normal;} |
| .source-xml {} |
| .source-xml .head {} |
| .source-xml .foot {} |
| .source-xml .imp {font-weight: bold; color: red;} |
| .source-xml .ln-xtra {color: #cc0; background-color: #ffc;} |
| .source-xml li {font-family: 'Courier New', Courier, monospace; color: black; font-weight: normal; font-style: normal;} |
| .source-xml li.li2 {font-weight: bold;} |
| .source-xml .coMULTI {color: #808080; font-style: italic;} |
| .source-xml .es0 {color: #000099; font-weight: bold;} |
| .source-xml .br0 {color: #66cc66;} |
| .source-xml .st0 {color: #ff0000;} |
| .source-xml .nu0 {color: #cc66cc;} |
| .source-xml .sc0 {color: #00bbdd;} |
| .source-xml .sc1 {color: #ddbb00;} |
| .source-xml .sc2 {color: #339933;} |
| .source-xml .sc3 {color: #009900;} |
| .source-xml .re0 {color: #000066;} |
| .source-xml .re1 {font-weight: bold; color: black;} |
| .source-xml .re2 {font-weight: bold; color: black;} |
| |
| /*]]>*/ |
| </style> |
| <style type="text/css">/*<![CDATA[*/ |
| @import "/index.php?title=MediaWiki:Geshi.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000"; |
| /*]]>*/ |
| </style><link rel="stylesheet" type="text/css" href="BPEL_Pipelining_Concept.html" /> </head> |
| <body class="mediawiki ns-0 ltr page-SMILA_Project_Concepts_BPEL_Pipelining_Concept"> |
| <div id="globalWrapper"> |
| |
| |
| <div id="column-one"> |
| <!-- Eclipse Additions for the Top Nav start here M. Ward--> |
| |
| <div id="header"> |
| <div id="header-graphic"> |
| <img src="http://wiki.eclipse.org/skins/eclipsenova/eclipse.png" alt="Eclipse Wiki"> |
| </div> |
| <!-- Pulled 101409 Mward --> |
| |
| <div class="portlet" id="p-personal"> |
| <div class="pBody"> |
| <ul> |
| <li id="pt-login"><a href="http://wiki.eclipse.org/index.php?title=Special:Userlogin&returnto=SMILA/Project_Concepts/BPEL_Pipelining_Concept">Log in</a></li> |
| </ul> |
| </div> |
| </div> |
| |
| <div id="header-icons"> |
| <div id="sites"> |
| <ul id="sitesUL"> |
| <li><a href="http://www.eclipse.org"><img src="http://dev.eclipse.org/custom_icons/eclipseIcon.png" width="28" height="28" alt="Eclipse Foundation" title="Eclipse Foundation" /><div>Eclipse Foundation</div></a></li> |
| <li><a href="http://marketplace.eclipse.org"><img src="http://dev.eclipse.org/custom_icons/marketplace.png" width="28" height="28" alt="Eclipse Marketplace" title="Eclipse Marketplace" /><div>Eclipse Marketplace</div></a></li> |
| <li><a href="https://bugs.eclipse.org/bugs"><img src="http://dev.eclipse.org/custom_icons/system-search-bw.png" width="28" height="28" alt="Bugzilla" title="Bugzilla" /><div>Bugzilla</div></a></li> |
| <li><a href="http://live.eclipse.org"><img src="http://dev.eclipse.org/custom_icons/audio-input-microphone-bw.png" width="28" height="28" alt="Live" title="Live" /><div>Eclipse Live</div></a></li> |
| <li><a href="http://planeteclipse.org"><img src="http://dev.eclipse.org/large_icons/devices/audio-card.png" width="28" height="28" alt="PlanetEclipse" title="Planet" /><div>Planet Eclipse</div></a></li> |
| <li><a href="http://portal.eclipse.org"><img src="http://dev.eclipse.org/custom_icons/preferences-system-network-proxy-bw.png" width="28" height="28" alt="Portal" title="Portal" /><div>My Foundation Portal</div></a></li> |
| </ul> |
| </div> |
| </div> |
| </div> |
| <!-- NEW HEADER STUFF HERE --> |
| <div id="header-menu"> |
| <div id="header-nav"> |
| <ul> <li><a class="first_one" href="http://wiki.eclipse.org/" target="_self">Home</a></li> <li><a href="http://www.eclipse.org/downloads/" target="_self">Downloads</a></li> |
| <li><a href="http://www.eclipse.org/users/" target="_self">Users</a></li> |
| <li><a href="http://www.eclipse.org/membership/" target="_self">Members</a></li> |
| <li><a href="http://wiki.eclipse.org/index.php/Development_Resources" target="_self">Committers</a></li> |
| <li><a href="http://www.eclipse.org/resources/" target="_self">Resources</a></li> |
| <li><a href="http://www.eclipse.org/projects/" target="_self">Projects</a></li> |
| <li><a href="http://www.eclipse.org/org/" target="_self">About Us</a></li> |
| </ul> |
| </div> |
| <div id="header-utils"> |
| <!-- moved the search window here --> |
| <form action="http://wiki.eclipse.org/Special:Search" > |
| <input class="input" name="search" type="text" accesskey="f" value="" /> |
| <input type='submit' onclick="this.submit();" name="go" id="searchGoButton" class="button" title="Go to a page with this exact name if one exists" value="Go" /> |
| <input type='submit' onclick="this.submit();" name="fulltext" class="button" id="mw-searchButton" title="Search Eclipsepedia for this text" value="Search" /> |
| </form> |
| </div> |
| </div> |
| |
| |
| <!-- Eclipse Additions for the Header stop here --> |
| <!-- Additions and mods for leftside nav Start here --> |
| |
| <!--Started nav rip here--> |
| <!-- these are the nav controls main page, changes etc --> |
| <div id="novaContent" class="faux"> |
| <div id="leftcol"> |
| <ul id="leftnav"> |
| <!-- these are the page controls, edit history etc --> |
| <li class="separator"><a class="separator">Navigation   </li> |
| <li id="n-mainpage"><a href="http://wiki.eclipse.org/Main_Page">Main Page</a></li> |
| <li id="n-portal"><a href="http://wiki.eclipse.org/Eclipsepedia:Community_Portal">Community portal</a></li> |
| <li id="n-currentevents"><a href="http://wiki.eclipse.org/Eclipsepedia:Current_events">Current events</a></li> |
| <li id="n-recentchanges"><a href="http://wiki.eclipse.org/Special:Recentchanges">Recent changes</a></li> |
| <li id="n-randompage"><a href="http://wiki.eclipse.org/Special:Random">Random page</a></li> |
| <li id="n-help"><a href="http://wiki.eclipse.org/Help:Contents">Help</a></li> |
| <li class="separator"><a class="separator">Toolbox   </a></li> |
| |
| <li id="t-whatlinkshere"><a href="http://wiki.eclipse.org/Special:Whatlinkshere/SMILA/Project_Concepts/BPEL_Pipelining_Concept">What links here</a></li> |
| <li id="t-recentchangeslinked"><a href="http://wiki.eclipse.org/Special:Recentchangeslinked/SMILA/Project_Concepts/BPEL_Pipelining_Concept">Related changes</a></li> |
| <!-- This is the toolbox section --> |
| <li id="t-upload"><a href="http://wiki.eclipse.org/Special:Upload">Upload file</a></li> |
| <li id="t-specialpages"><a href="http://wiki.eclipse.org/Special:Specialpages">Special pages</a></li> |
| <li id="t-print"><a href="http://wiki.eclipse.org/index.php?title=SMILA/Project_Concepts/BPEL_Pipelining_Concept&printable=yes">Printable version</a></li> <li id="t-permalink"><a href="http://wiki.eclipse.org/index.php?title=SMILA/Project_Concepts/BPEL_Pipelining_Concept&oldid=284632">Permanent link</a></li> </ul> |
| </div> |
| |
| |
| <!-- Additions and mods for leftside nav End here --> |
| |
| |
| <div id="column-content"> |
| <div id="content"> |
| <a name="top" id="top"></a> |
| |
| <div id="tabs"> |
| <ul class="primary"> |
| <li class="active"><a href="BPEL_Pipelining_Concept.html"><span class="tab">Page</span></a></li> |
| <li><a href="http://wiki.eclipse.org/index.php?title=Talk:SMILA/Project_Concepts/BPEL_Pipelining_Concept&action=edit"><span class="tab">Discussion</span></a></li> |
| <li><a href="http://wiki.eclipse.org/index.php?title=SMILA/Project_Concepts/BPEL_Pipelining_Concept&action=edit"><span class="tab">View source</span></a></li> |
| <li><a href="http://wiki.eclipse.org/index.php?title=SMILA/Project_Concepts/BPEL_Pipelining_Concept&action=history"><span class="tab">History</span></a></li> |
| <li><a href="http://wiki.eclipse.org/index.php?title=Special:Userlogin&returnto=SMILA/Project%20Concepts/BPEL%20Pipelining%20Concept"><span class="tab">Edit</span></a></li> |
| </ul> |
| </div> |
| |
| |
| <script type="text/javascript"> if (window.isMSIE55) fixalpha(); </script> |
| <h1 class="firstHeading">SMILA/Project Concepts/BPEL Pipelining Concept</h1> |
| <div id="bodyContent"> |
| <h3 id="siteSub">From Eclipsepedia</h3> |
| <div id="contentSub"><span class="subpages">< <a href="../../SMILA.html" title="SMILA">SMILA</a> | <a href="../Project_Concepts.1.html" title="SMILA/Project Concepts">Project Concepts</a></span></div> |
| <div id="jump-to-nav">Jump to: <a href="BPEL_Pipelining_Concept.html#column-one">navigation</a>, <a href="BPEL_Pipelining_Concept.html#searchInput">search</a></div> <!-- start content --> |
| <table id="toc" class="toc" summary="Contents"><tr><td><div id="toctitle"><h2>Contents</h2></div> |
| <ul> |
| <li class="toclevel-1"><a href="BPEL_Pipelining_Concept.html#Description"><span class="tocnumber">1</span> <span class="toctext">Description</span></a></li> |
| <li class="toclevel-1"><a href="BPEL_Pipelining_Concept.html#Discussion"><span class="tocnumber">2</span> <span class="toctext">Discussion</span></a></li> |
| <li class="toclevel-1"><a href="BPEL_Pipelining_Concept.html#Technical_proposal"><span class="tocnumber">3</span> <span class="toctext">Technical proposal</span></a> |
| <ul> |
| <li class="toclevel-2"><a href="BPEL_Pipelining_Concept.html#Pipelet_instantiation_variants"><span class="tocnumber">3.1</span> <span class="toctext">Pipelet instantiation variants</span></a></li> |
| <li class="toclevel-2"><a href="BPEL_Pipelining_Concept.html#Pipelet_Implementation_rules"><span class="tocnumber">3.2</span> <span class="toctext">Pipelet Implementation rules</span></a></li> |
| <li class="toclevel-2"><a href="BPEL_Pipelining_Concept.html#Configuration_repository"><span class="tocnumber">3.3</span> <span class="toctext">Configuration repository</span></a></li> |
| <li class="toclevel-2"><a href="BPEL_Pipelining_Concept.html#BPEL_Extension_Activities"><span class="tocnumber">3.4</span> <span class="toctext">BPEL Extension Activities</span></a> |
| <ul> |
| <li class="toclevel-3"><a href="BPEL_Pipelining_Concept.html#Current_problems_are:"><span class="tocnumber">3.4.1</span> <span class="toctext">Current problems are:</span></a></li> |
| <li class="toclevel-3"><a href="BPEL_Pipelining_Concept.html#Issues_to_solve:"><span class="tocnumber">3.4.2</span> <span class="toctext">Issues to solve:</span></a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </td></tr></table><script type="text/javascript"> if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } </script> |
| <a name="Description"></a><h2> <span class="mw-headline"> Description </span></h2> |
| <p>In this model the orchestration of pipelets (= "pipeline") is defined by BPEL processes. We distinguish two seperate kinds of pipelets: |
| </p> |
| <ul><li> "Big Pipelets" are implemented as OSGi services, can be shared by multiple pipelines and their configuration are seperated from the BPEL prociess defition. |
| </li><li> "Simple Pipelets" are managed by a component of the BPEL engine integration, instances are not shared by multiple pipelines and their configuration is part of the BPEL process definition. |
| </li></ul> |
| <a name="Discussion"></a><h2> <span class="mw-headline"> Discussion </span></h2> |
| <a name="Technical_proposal"></a><h2> <span class="mw-headline"> Technical proposal </span></h2> |
| <p>In this model the orchestration of pipelets (= "pipeline") is defined by BPEL processes. The pipelets are implemented as OSGi services. This should make it easier later to support the execution of unsafe pipelets in own VMs, because there are several technologies for transparent remote communication with OSGi services available (Tuscany, ECF, Riena). In the following we assume that the service lifecycle of all services is controlled by OSGi Declarative Services (DS). This simplifies the starting and stopping of services and binding them to other services. To support the initialization of services at service activation, DS defines that a special method is called when the service is activated, in which the necessary initialization can be done (reading of configurations, connecting to used resources, creating internal structures, etc). DS also defines a method to be called when a service is deactivated that can be used for cleaning up. The two methods must have this signature: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java"><span class="kw1">protected</span> <span class="kw4">void</span> activate<span class="br0">(</span>ComponentContext context<span class="br0">)</span>; |
| <span class="kw1">protected</span> <span class="kw4">void</span> deactivate<span class="br0">(</span>ComponentContext context<span class="br0">)</span>;</pre></div> |
| <p>Each pipelet service must have a service property "smila.processing.service.name" that specifies the name of this pipelet. The name must be unique for each service in a single VM and is defined in the DS component description. The pipelet name is used in BPEL definition to refer to the pipelets. If multiple instances of the same pipelet class are needed, they can be distinguished using different pipelet names. |
| The pipelet execution method is currently: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java">Id<span class="br0">[</span><span class="br0">]</span> process<span class="br0">(</span>Id<span class="br0">[</span><span class="br0">]</span> recordIds<span class="br0">)</span> <span class="kw1">throws</span> ProcessingException;</pre></div> |
| <p>I.e. it is called by the workflow with a list of record IDs, the content of these records is supposed to be available via the Blackboard service, so all access and manipulation of the records is done using the Blackboard service. The result is also a list of record IDs. Usually these will be the same as the input IDs, a different list can be produced by pipelets that split records. This means that all data needed by the pipelet for processing must be on the blackboard: |
| </p> |
| <ul><li> record attributes and attachments |
| </li><li> record annotations |
| </li><li> workflow and record notes |
| </li></ul> |
| <p>The two latter items may also be used to pass parameters to a pipelet. However, we will need BPEL Extension Activities to be able to set them in the BPEL definition (see end of this chapter). |
| Pipelets as well as the BPEL integration get their configurations from a central "configuration repository". This can be a simple directory with a defined structure at first, or a complex service supporting centralized configuration management and updating (and notification of clients about configuration changes) later. |
| Pipelet configurations are separated from the BPEL pipelines, because Pipelets existence does not depend on the existence of a pipeline engine and must not depend on the implementation of the pipeline engine. This makes it easier to use pipelets independent from a special pipelining implementation, e.g. if we want to replace the BPEL engine by a JBPM engine or an own workflow engine implementation. This makes it also easier to share pipelet instances between pipelines which is crucial for pipelets that use lots of memory (e.g. semantic text mining) or need resources that can only be accessed exclusively by one client (e.g. writing to a Solr core). Finally it enables OSGi to restart the BPEL integration service without having to restart the pipelets (e.g. for software updates). |
| The BPEL integration is started by DS, too. Pipelets are bound to the BPEL integration as DS service references. This way the BPEL service can always keep track about currently available pipelet services. It would even be possible to track which pipelet is used in which pipeline and thus to know a priori which pipeline is currently completely executable. |
| </p> |
| <a name="Pipelet_instantiation_variants"></a><h3> <span class="mw-headline"> Pipelet instantiation variants </span></h3> |
| <p>Usually we have one instance of a Pipelet class that has a single configuration. The pipelet name is then a like a key to the combination "pipelet instance name = pipelet class + configuration". However, there may be cases in which it would be good to have a single pipelet class available with different configurations. There are two ways to support this: |
| </p> |
| <ul><li> Have a single pipelet instance with a configuration consisting of the different parts. Which part of the configuration is actually used in an invocation must then be passed using a record annotation. E.g.: There is a service "pipelet-name" = pipelet.A + config X & config Y, i.e. it has loaded both configurations. |
| </li></ul> |
| <p>An record in the invocation contains annotations: |
| </p> |
| <ul><li><ul><li> "pipelet-name/select-configuration" = X -> use config X for processing this record |
| </li><li> "pipelet-name/select-configuration" = Y -> use config Y for processing this record |
| </li></ul> |
| </li></ul> |
| <p>Note that this makes it possible to process different records with different configurations in a single invocation. |
| Of course in such a scenario one configuration should be marked as the default configuration to be used if no annotation is set. |
| </p> |
| <ul><li> Have multiple pipelet instances with different names, each having one of these configurations. E.g. there a two service instances of the same pipelet class with different pipelet names: |
| <ul><li> service 1: "pipelet-name-1" = pipelet.B + config X |
| </li><li> service 2: "pipelet-name-2" = pipelet.B + config Y |
| </li></ul> |
| </li></ul> |
| <p>Then the pipelet name used in the BPEL invoke activity determines which configuration is used. |
| </p> |
| <a name="Pipelet_Implementation_rules"></a><h3> <span class="mw-headline"> Pipelet Implementation rules </span></h3> |
| <p>Pipelets can potentially be invoked more than once at the same time. This means that a pipelet either should be written in a multithreading-safe way (stateless, read-only configuration and member variables) or it must take care itself about synchronization of critical sections (e.g. Solr core writing). |
| </p> |
| <a name="Configuration_repository"></a><h3> <span class="mw-headline"> Configuration repository </span></h3> |
| <p>This is just an ad-hoc proposal to give an idea of how it could look like. In details it's open to discussion. |
| </p><p>For the moment we assume that the configuration repository is a single directory with sub directories in the file system. The configurations for components are located in subdirectories in the repository root. The name of these subdirectories is the bundle name of the component. What's happening inside of a bundle configuration directory is up to the bundle implementation. E.g. for the ODE BPEL integration bundle it contains a property file for general BPEL engine configuration and another subdirectory containing pipeline definitions. E.g.: |
| </p> |
| <pre> |
| configuration |
| | |
| |-- org.eclipse.smila.processing.bpel |
| | |-- processor.properties |
| | \-- pipelines |
| | |-- pipeline-1.bpel |
| | |-- pipeline-2.bpel |
| | |-- ... |
| | |-- processor.wsdl |
| | |-- record.xsd |
| | |-- id.xsd |
| | | (predefined schema files necessary for reference. |
| | | Needed also during editing in BPEL designer) |
| | \-- deploy.xml |
| | (technical reasons, we can get rid of this) |
| |-- org.eclipse.smila.pipelet.A |
| | | (example: one instance managing multiple configurations) |
| | |-- config-X.xml |
| | \-- config-Y.xml |
| |-- org.eclipse.smila.pipelet.B |
| | | (example: one instance per configuration) |
| | |-- pipelet-name-1 |
| | | \-- config-X.xml |
| | \-- pipelet-name-2 |
| | \-- config-Y.xml |
| |-- ... |
| </pre> |
| <p>This is quite similar to [Configuration handling], but with an optional additional folder level for "configuration sections" to structure the configurations better, e.g. for pipelets that require multiple instances for multiple configurations there can be one section per pipelet instance. Of course, bundles are free on how to use the configuration repository structure for their purposes. But we should describe some usage patterns because that would make reading the repository easier for adminstrators. |
| </p><p>(To discuss: do we need folder structures of arbitrary depth?) |
| </p><p>SMILA should provide helper classes to make locating and parsing of simple configurations easy. We can define a common XML format for basic configurations that most pipelets can use for their configurations, e.g. something of similar structure than the Record Annotation format?). Simple Property files can be supported, too. Then we can create a simple ConfigurationAccess service with methods like |
| </p> |
| <ul><li> to navigate the Configuration repository: |
| </li></ul> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java"><span class="kw3">String</span><span class="br0">[</span><span class="br0">]</span> getSectionNames<span class="br0">(</span><span class="kw3">String</span> bundleName<span class="br0">)</span>; |
| <span class="co1">// e.g. getSectionNames("org.eclipse.smila.pipelet.B") </span> |
| <span class="co1">// returns ["pipelet-name-1", "pipelet-name-2"]</span> |
| <span class="kw3">String</span><span class="br0">[</span><span class="br0">]</span> getConfigNames<span class="br0">(</span><span class="kw3">String</span> bundleName<span class="br0">)</span>; |
| <span class="co1">// e.g. getConfigNames("org.eclipse.smila.pipelet.A") </span> |
| <span class="co1">// returns ["config-X.xml", "config-Y.xml"]</span> |
| <span class="kw3">String</span><span class="br0">[</span><span class="br0">]</span> getConfigNames<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> sectionName<span class="br0">)</span>; |
| <span class="co1">// e.g. getConfigNames("org.eclipse.smila.pipelet.B", "pipelet-name-1") </span> |
| <span class="co1">// returns ["config-X.xml", "config-Y.xml"]</span></pre></div> |
| <ul><li> to access and parse the configurations in common XML format: |
| </li></ul> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java">Configuration getConfig<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> configName<span class="br0">)</span>; |
| Configuration getConfig<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> sectionName, <span class="kw3">String</span> configName<span class="br0">)</span>;</pre></div> |
| <ul><li> to access and read property files: |
| </li></ul> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java"><span class="kw3">Properties</span> getProperties<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> configName<span class="br0">)</span>; |
| <span class="kw3">Properties</span> getProperties<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> sectionName, <span class="kw3">String</span> configName<span class="br0">)</span>;</pre></div> |
| <ul><li> to access other configurations: |
| </li></ul> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java"><span class="kw3">InputStream</span> getStream<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> configName<span class="br0">)</span>; |
| <span class="kw3">InputStream</span> getStream<span class="br0">(</span><span class="kw3">String</span> bundleName, <span class="kw3">String</span> sectionName, <span class="kw3">String</span> configName<span class="br0">)</span>;</pre></div> |
| <p>This would make accessing of simple configurations quite simple for a pipelet developer. |
| </p> |
| <a name="BPEL_Extension_Activities"></a><h3> <span class="mw-headline"> BPEL Extension Activities </span></h3> |
| <p>The BPEL specification allows extending BPEL by using Extension Activities. An Extension Activity is basically a Java class with a given interface that is registered to the BPEL engine under a qualified name. It the can be used in BPEL by a statement like this: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-xml"><span class="sc3"><span class="re1"><bpel:extensionActivity<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><myns:NameOfExtension<span class="re2">></span></span></span> |
| <span class="sc3"><span class="coMULTI"><!-- arbitary XML elements --></span></span> |
| <span class="sc3"><span class="re1"></myns:NameOfExtension<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></bpel:extensionActivity<span class="re2">></span></span></span></pre></div> |
| <p>The implementation class is then called with the complete XML element of its description and can access all workflow variables defined in the BPEL. This means the activity can configured in the BPEL. E.g. for setting record annotations we can provide an extension activity similar to this: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-xml"><span class="sc3"><span class="re1"><extensionActivity<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><ext:setAnnotations<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><ext:target</span> <span class="re0">variable</span>=<span class="st0">"request"</span><span class="re2">/></span></span> |
| <span class="sc3"><span class="re1"><rec:An</span> <span class="re0">n</span>=<span class="st0">"pipelet-name"</span><span class="re2">></span></span> |
| <span class="sc3"><span class="re1"><rec:An</span> <span class="re0">n</span>=<span class="st0">"select-configuration"</span><span class="re2">></span></span> |
| <span class="sc3"><span class="re1"><rec:V<span class="re2">></span></span></span>X<span class="sc3"><span class="re1"></rec:V<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></rec:An<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></rec:An<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></ext:setAnnotations<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></extensionActivity<span class="re2">></span></span></span></pre></div> |
| <p>This would set an annotation named "pipelet-name/select-configuration" with value "X" on all records the request variable. Of course it would also be possible to create a more specialized activity instead, that would define a simpler syntax to describe the annotations to be set. |
| </p> |
| <a name="Current_problems_are:"></a><h4> <span class="mw-headline"> Current problems are: </span></h4> |
| <ul><li> This is not supported by the current release (1.1.1) and also not in release 1.2 (currently about to be released) of ODE, but only in the trunk version (this will be release 1.3 probably). The latest estimation for a release date was "in about two months". |
| </li><li> It's also not supported by the current release (M3) of the Eclipse BPEL designer. According to Eclipse Bugzilla it should be added to M4, which in turn should be released in the near future. However, I think we will have to provide own extensions to the BPEL designer anyway in order to have user friendly editing of extension activities provided by us. |
| </li></ul> |
| <p>Integrating Simple Pipeline Model into BPEL Pipelining |
| Using extension activities it would even be possible to integrate the complete simple pipeline model into the BPEL pipelining model: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-xml"><span class="sc3"><span class="re1"><extensionActivity<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><ext:invokePipelet<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><ext:pipelet</span> <span class="re0">name</span>=<span class="st0">"pipelet-name"</span><span class="re2">/></span></span> |
| <span class="sc3"><span class="re1"><ext:variables</span> <span class="re0">input</span>=<span class="st0">"request"</span> <span class="re0">output</span>=<span class="st0">"result"</span><span class="re2">/></span></span> |
| <span class="sc3"><span class="re1"><ext:invocationConfig<span class="re2">></span></span></span> |
| <span class="sc3"><span class="coMULTI"><!-- parameters of invocation, e.g. error handling? --></span></span> |
| <span class="sc3"><span class="re1"></ext:invocationConfig<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"><ext:pipeletConfig<span class="re2">></span></span></span> |
| <span class="sc3"><span class="coMULTI"><!-- pipelet XML configuration, schema: to define --></span></span> |
| <span class="sc3"><span class="re1"></ext:pipeletConfig<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></ext:invokePipelet<span class="re2">></span></span></span> |
| <span class="sc3"><span class="re1"></extensionActivity<span class="re2">></span></span></span></pre></div> |
| <p>We could provide an Extension Activity implementation that manages the "simple pipelet" lifecycle and configuration and translates the calls from the BPEL engine into a convenient pipelet invocation. The execution interface of the simple pipelet would be the same as that of the pipelet service described above: |
| Because the lifecycle of extension activities themselves is undefined (it seems that in ODE a new instance is created for each call), the extension activity is only a simple class that promotes the BPEL call to a "SimplePipeletManager" that manages the pipelet instances (all in once or all for a single pipeline), configurations, invocations and error handling. |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java">Id<span class="br0">[</span><span class="br0">]</span> process<span class="br0">(</span>Id<span class="br0">[</span><span class="br0">]</span> recordIds<span class="br0">)</span> <span class="kw1">throws</span> ProcessingException;</pre></div> |
| <p>Simple pipelets would use the blackboard service to access the actual record data. |
| Additionally, simple pipelets need a method to set the configuration: |
| </p> |
| <div dir="ltr" style="text-align: left;"><pre class="source-java"><span class="kw4">void</span> configure<span class="br0">(</span>PipeletConfiguration config<span class="br0">)</span> <span class="kw1">throws</span> <span class="kw3">ConfigurationException</span>;</pre></div> |
| <p>(Question: Do we also need a method for "shutdown" method to be called when the pipelet is destroyed? Or can we require simple pipelets to be so simple that they do not need such a method?) |
| </p><p>The tasks of the SimplePipeletManager are |
| </p> |
| <ul><li> Start of Pipeline/Pipelet becomes available: |
| <ul><li> Instantiate Pipelet |
| </li><li> Parse PipeletConfiguration from BPEL pipeline and call pipelets configure method. |
| </li></ul> |
| </li><li> Pipelet Invocation (very similar to invocation of "big pipelets", see [Blackboard Service Concept]: |
| <ul><li> Parse records from "input" variable and sync them to blackboard |
| </li><li> Call simple pipelet's execute method with record IDs |
| </li><li> Create workflow objects from result IDs and blackboard content and write them back to "output" variable |
| </li></ul> |
| </li><li> In case of a pipelet error: care about indicating the error in a correct way to the BPEL engine. |
| </li></ul> |
| <a name="Issues_to_solve:"></a><h4> <span class="mw-headline"> Issues to solve: </span></h4> |
| <ul><li> Simple pipelets should be instantiated and configured at deployment of the BPEL pipeline. This way missing pipelet implementations and configuration errors can be reported during system start up and not during first execution. For this it is probably necessary to introspect the pipeline definition and search for occurrences of the extension activity, because the BPEL engine may not support this directly. |
| </li><li> Like in the Simple Pipeline Model itself we must decide on a pipelet lookup and instantiation model that makes it easy to support OSGi dynamics: The SimplePipeletManager must be able to track deactivation of bundles providing simple pipelets such that it can destroy the provided pipelets and re-instantiate them when the bundle reappears. Two mechanisms are possible: |
| <ul><li> OSGi Service Factories: The providing bundle declares an OSGi service factory that the SPM can use to create actual pipelet instances. This way we can use the DS support for dynamic services also for simple pipelets. We can probably provide a default implementation of this factory such that the providing bundle must only contain a suitable component description starting this factory customized for its own pipelet. |
| </li><li> OSGi Extender Model: Use BundleListener/Tracker to check installed or removed bundles for contained pipelet implementations (declared in a contained XML file). See this for document for details: <a href="http://neilbartlett.name/downloads/preview_extender_20080527_1320.pdf" class="external autonumber" title="http://neilbartlett.name/downloads/preview_extender_20080527_1320.pdf" rel="nofollow">[1]</a>. |
| </li></ul> |
| </li></ul> |
| <p>Configuration using Eclipse BPEL designer |
| </p><p>The Eclipse BPEL designer is extensible itself using extension points. Details have to be clarified by somebody with more experience in Eclipse/GUI/RCP programming, but it should be possible to: |
| </p> |
| <ul><li> Define a view displaying all available pipelets, maybe grouped. |
| </li><li> Drag an available pipelet from this view into the BPEL pipeline which generates a <extensionActivity> element with the <ext:invokePipelet> activity for the dragged pipelet. |
| </li><li> Show a specialized properties tab for simple configuration of the pipelet such that the user does not have to write the contained XML. For this the pipelet provider must declare names, types, multiplicity, etc. of the pipelet's configuration properties. This should be done in an XML file provided with the pipelet bundle (schema to be defined). |
| </li><li> Provide a view showing all pipelets used in all pipelines grouped by pipelines. |
| </li></ul> |
| <p>Note that this is not limited to simple pipelets, but can be used similar to handle the "big pipelets". It has to be decided if that should be supported by calling "big pipelet services" also using an extension activity for consistent handling of both types of pipelets. (currently the implementation uses the standard BPEL invoke activity to call pipelet services) |
| </p> |
| <!-- |
| NewPP limit report |
| Preprocessor node count: 46/1000000 |
| Post-expand include size: 0/2097152 bytes |
| Template argument size: 0/2097152 bytes |
| #ifexist count: 0/100 |
| --> |
| |
| <!-- Saved in parser cache with key wikidb:pcache:idhash:15162-0!1!0!!en!2!edit=0 and timestamp 20120203101509 --> |
| <div class="printfooter"> |
| Retrieved from "<a href="BPEL_Pipelining_Concept.html">http://wiki.eclipse.org/SMILA/Project_Concepts/BPEL_Pipelining_Concept</a>"</div> |
| <div id="catlinks"><p class='catlinks'><a href="http://wiki.eclipse.org/Special:Categories" title="Special:Categories">Category</a>: <span dir='ltr'><a href="http://wiki.eclipse.org/Category:SMILA" title="Category:SMILA">SMILA</a></span></p></div> <!-- end content --> |
| <div class="visualClear"></div> |
| </div> |
| </div> |
| |
| |
| </div> |
| |
| |
| <!-- Yoink of toolbox for phoenix moved up --> |
| |
| |
| </div> |
| </div> |
| <div id="clearFooter"/> |
| <div id="footer" > |
| <ul id="footernav"> |
| <li class="first"><a href="http://www.eclipse.org/">Home</a></li> |
| <li><a href="http://www.eclipse.org/legal/privacy.php">Privacy Policy</a></li> |
| <li><a href="http://www.eclipse.org/legal/termsofuse.php">Terms of Use</a></li> |
| <li><a href="http://www.eclipse.org/legal/copyright.php">Copyright Agent</a></li> |
| <li><a href="http://www.eclipse.org/org/foundation/contact.php">Contact</a></li> |
| <li><a href="http://wiki.eclipse.org/Eclipsepedia:About" title="Eclipsepedia:About">About Eclipsepedia</a></li> |
| </ul> |
| <span id="copyright">Copyright © 2012 The Eclipse Foundation. All Rights Reserved</span> |
| <p id="footercredit">This page was last modified 08:56, 16 January 2012 by <a href="http://wiki.eclipse.org/index.php?title=User:Daniel.stucky.attensity.com&action=edit" class="new" title="User:Daniel.stucky.attensity.com">Daniel Stucky</a>. Based on work by <a href="http://wiki.eclipse.org/User:Juergen.schumacher.empolis.com" title="User:Juergen.schumacher.empolis.com">Juergen Schumacher</a>.</p> |
| <p id="footerviews">This page has been accessed 2,285 times.</p> |
| </div> |
| |
| <script type="text/javascript"> |
| var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); |
| document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); |
| </script> |
| <script type="text/javascript"> |
| var pageTracker = _gat._getTracker("UA-910670-4"); |
| pageTracker._trackPageview(); |
| </script> |
| |
| |
| |
| |
| |
| |
| |
| <!-- <div class="visualClear"></div> --> |
| |
| <script type="text/javascript">if (window.runOnloadHook) runOnloadHook();</script> |
| </div> |
| |
| <!-- Served in 0.233 secs. --></body></html> |
