<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head><body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;overflow-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Paul,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Just to say that the coupling is by the definition of the ExecutionWorker in the ExecutionBroker that overlaps UWS. I think it is basically what you said and what I think it could be good to decouple although
there are some problems that Dave can explain.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Yes, we can have a chat on this with Dave. As you know, the work on the ExecutionBroker is being developed in the context of the SRCNet so we can organize a meeting within one of the SRCNet architecture discussions
to get your feedback accordingly in the spec.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jesus<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;color:black">From:
</span></b><span style="font-family:"Calibri",sans-serif;color:black">Paul Harrison <paul.harrison@manchester.ac.uk><br>
<b>Date: </b>Friday 30 August 2024 at 16:11<br>
<b>To: </b>Jesus Salgado <jesus.salgado@skao.int><br>
<b>Cc: </b>Grid and Web Services WG <grid@ivoa.net><br>
<b>Subject: </b>Re: ExecutionBroker and prior art.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 26 Aug 2024, at 11:34, Salgado, Jesus <jesus.salgado@skao.int> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:Helvetica">Hi Paul,<br>
<br>
I'm not entirely certain that the functionality of ExecutionBroker aligns precisely with the domain of UWS. ExecutionBroker is designed to assess the complexity of a specific execution on a particular science platform (or node) by considering execution requirements,
available resources, permissions, data proximity, and more.<br>
<br>
As I've discussed with Dave several times, there is a degree of coupling between the execution interface and ExecutionBroker so the execution interface defined in UWS is partially redefined within ExecutionBroker (Dave could provide more specific details).
Due to the time-limited nature of "execution offers," complete decoupling is not feasible in his design. However, this is something I would be in favour of mitigate by a better decoupling if possible.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I am not sure what the coupling is really - that needs to be explained.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:Helvetica"><br>
Rather than adding new functionality to UWS, I prefer to explore a more decoupled approach. This would involve using ExecutionBroker to identify available resources for an execution and employing UWS (potentially with updates in UWS 2.0) as the execution interface
to execute the offer. This decoupling would result in clearer interfaces and simpler implementation, as we wouldn't need a monolithic service.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I am not suggesting adding the whole of the ExecutionPlanner interface to UWS - what I am saying is potentially add whatever is missing to achieve whatever the necessary coupling is.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:Helvetica"><br>
It's true that there is some overlap in the definition of execution parameters and resource data models (e.g., CPUs, GPUs, memory). We might be able to reuse previous work (e.g. CEA) in this area. In fact, I also advocate for a separate data model that both
UWS and ExecutionBroker can utilize for characterization.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I am all in favour of creating data models nowadays!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:Helvetica"><br>
Let's discuss this further with Dave.<br style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px;word-spacing:0px">
<br>
</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal">Of course the execution planning part is only of limited value if there is some sort of workflow runner that can make decisions based on what it gets back - it probably was not as obvious from the IVOA note, but the Astrogrid system did
have a workflow system JES - described in this ADASS poster <a href="https://github.com/Javastro/astrogrid-legacy/blob/main/astrogrid/applications/docs/ADASS2004/PosterA3.pdf">https://github.com/Javastro/astrogrid-legacy/blob/main/astrogrid/applications/docs/ADASS2004/PosterA3.pdf</a> -
in the end we did not attempt to bring any of the workflow part to the IVOA as we though it would be too difficult to get agreement, so only is the actual job execution interface - which got renamed UWS. However, I still feel that to properly design an execution
planner there does need to be a simultaneous consideration of what will be the caller of the executionBroker.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Paul<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</div>
<br>
<br>
<font size="1.5px">
The SKA Observatory is an inter-governmental organisation and the successor of SKA Organisation, a private limited company by guarantee registered in England and Wales with registered number 07881918, with a registered office of Jodrell Bank, Lower Withington, Macclesfield, Cheshire, England, SK11 9FT.
<br><br>
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please inform the sender, and immediately and permanently delete the email. Do not use, copy or disclose the information contained in this message or in any attachment.
<br><br>
This email has been scanned for viruses and malware, and may have been automatically archived, by Mimecast Ltd. Although SKA Observatory and SKA Organisation have taken reasonable precautions to ensure no viruses are present in this email, neither SKA Observatory nor SKA Organisation accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and attachments) are virus free.
</font>
</body></html>