Re: Proxylet Downloading and metadata

I certainly like to hear this enumerated. It was an area of confusion for 
me at the NYC meeting, since I went in there with the "proxylet means local 
execution" assumption... which I picked up from the original EPSFW... but 
it didn't seem like everyone was working off that document anymore. 
Therefore, if we get rough consensus around this definition, perhaps it 
belongs in the OPES Taxonomy draft?
--
Phil


At 10:13 AM 3/5/01 -0500, Markus Hofmann wrote:
> Rajnish,
>
>
> >     After going through the mailing list, I come to conclusion that we 
> > can have proxylet execution on both local( where rule base has matched) 
> > and some other server.
> I think the original intention was to use ther term "proxylet" whenever 
> the code was executed on the local machine, i.e. the machine on which the 
> rule base has matched. There might be a proxylet that triggers code to be 
> executed sitting on a remote call-out server.
> Originally, the term was mainly used to describe the data flow, which is 
> different between local execution of code (proxylet) and remote execution 
> of code (remote call-out). However, I believe that in recent discussions 
> we also used the term "proxylet" to refer to the actual CODE being 
> executed. And this code can be used local (i.e. as proxylet) or remote 
> (i.e. as call-out). This might have caused some confusion.
> Example: Assume there's a virus scanner software. This software could be 
> installed and executed on the rule matching machine (i.e. as proxylet), or 
> it can be installed and executed on a remote machine (i.e. remote 
> call-out). If local and remote machine have the same interface, the code 
> to be executed on both machines can be the same. I believe we also used 
> the term "proxylet" to refer to this piece of code - which probably was 
> confusing.
> Suggestion: Let's refer to the actual code as "(service) plug-in". If the 
> plug-in is installed on the local rule matching machine, it's a 
> "proxylet", i.e. a local service. If the plug-in is installed on a remote 
> machine, it's a "call-out service". Would that help?
> In this sense, we can have "plug-in" execution on the local machine 
> (proxylet) and on the remote machine (call-out).
>
> >     When it is local execution, proxylet needs to be downloaded from 
> > proxylet vendor.
> We should probably refer to "plug-in" vendor rather than "proxylet" 
> vendor, see above. The plug-in can be installed either on the local (rule 
> matching) machine or on a remote call-out server (assuming both machines 
> offer similar interfaces).
> > For downloading proxylet, proxylet location is required which is obtained 
> > from proxylet metadata.So, first, proxylet metadata has to be downloaded 
> > from proxylet vendor.Then using the "location" element, proxylet is 
> > downloaded. And service offered by this proxylet is obtained by 
> > specifying     "Action" element as
> >     <Action> proxylet:\\localhost\proxyletp1 </Action>
> >
> >     Now when we are going to have proxylet execution on some other 
> > server, how things are different ?
> We should probably re-name "proxylet location" into "plug-in location", 
> because it refers to where the CODE can be downloaded. After retrieving 
> the "plug-in" meta-data, we use the "location" element to retrieve the code.
> If we install the code on the local (rule matching) machine, we trigger 
> execution of the code by using
>   <Action> proxylet:\\localhost\proxyletp1 </Action>
>
> in the rule.
>
> If we install the code on a remote call-out server, we trigger execution 
> of the code by using
>  <Action> icap:\\www.icap.org\proxyletp1 </Action>, or
>  <Action> xyz:\\www.foo.org\proxyletp1 </Action>
>
> where "xyz" refers to any remote-callout protocol (such as iCAP).
>
>
> Summary: The actucal code providing a specific service can be called 
> "(service) plug-in". Depending on where the code will be installed, it 
> instances either a "proxylet" service or a "call-out" service.
> Does this help or is this even more confusing?
>
> -Markus
--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)