[cddlm] CodeBase semantics

[Ayla Debora Dantas de Souza - Projeto Ourgrid]

Hi Stuart,

thanks for answering. In fact we will change the CodeBase and 
CommandPath according to our engine, I just wanted to know if there was 
any problem on that.
Thanks again,
          Ayla

Stuart Schaefer wrote:

>Ayla,
>
>I have looked into providing "stock" components.  My implementation is
>based on the .NET Framework.  I know that everyone else is using some
>Java based technology like Tomcat or otherwise.  I don't think this will
>be feasible to provide, as the engine differences are not small.
>
>The CDL snippet you outlined below presumes that you will change the
>CodeBase element to be some .war file for your implementation.  The
>CommandPath should be changed as well to suit your engine.
>
>Stuart
>
>-----Original Message-----
>From: owner-cddlm-wg at ggf.org [mailto:owner-cddlm-wg at ggf.org] On Behalf
>Of Ayla Debora Dantas de Souza - Projeto Ourgrid
>Sent: Wednesday, April 05, 2006 1:13 PM
>To: cddlm-wg at ggf.org
>Subject: [cddlm] CodeBase semantics
>
>Hi,
>
>regarding the discussion about CodeBase and CommandPath semantics that 
>can vary from implementation to implementation and the Component Model 
>test plan, I have an initial doubt. In the CDLs from the test plan, 
>there is a part:
>
><!-- change these per your system -->
>
><cmp:CodeBase>http://localhost/test1.jar</cmp:CodeBase>
>
><cmp:CommandPath>com.exns.Test1</cmp:CommandPath>
>
>
>I was not sure if the code that will be provided in source forge will be
>
>the code for this class (com.exns.Test1) or if we should change  
>CodeBase and CommandPath values.
>
>In this latter case, can we totally replace both the CodeBase and 
>CommandPath to something that is understandable by our engine or should 
>the engine support  CodeBases specified as a ".jar" file and simply 
>execute (someway) one of the classes from this jar that should be able 
>to provide a service endpoint for the component?
>
>In our Engine, for example, we are only supporting now the deployment of
>
>"war" files, and then, the "war" file once deployed will originate the 
>service whose endpoint will manage the component lifecycle. Is this ok?
>
>Thanks,
>  Ayla
>
>Milojicic, Dejan S (HP Labs) wrote:
>
>  
>
>>Attendees: Jun, Ayla, Satish, Guilherme, Flavio, Steve, Stuart, Dejan.
>>
>>Note taker: Dejan.
>>
>> 
>>
>>    
>>
>>>0. Reference implementation status update 
>>>1. Update on the testing of interoperability 
>>>   
>>>
>>>      
>>>
>>Ayla: did some additional tests, would like some more examples of CDL.
>>Will be working on tests from Stuart, not sure about how component
>>    
>>
>model
>  
>
>>is going. Still beginning, will make questions as soon as we have them.
>>
>>Steve: was out last week. Given up completely from Apache Axes 2, and
>>instead rolling back to his own. Targeting next week, automating
>>    
>>
>process
>  
>
>>with bringing up endpoint. First release will be atrociously bad and
>>broken. A lot of interoperability problems because SOAP stack will be
>>new, then ramp up quickly. Serve it up from home rather than from
>>    
>>
>behind
>  
>
>>the firewall. SmartFrog will use and interesting implications about
>>security, limit it to a small set of components (1 out of 10) for
>>security reasons.
>>
>>Stuart: their plan is to leverage Ayla's endpoint to test their end
>>point and then they will put up their own endpoint. Released component
>>model spec test. Source forge was down, so did not put it in the source
>>forge.  Steve: source forge has broken file system, do not trust it.
>>
>>Jun/Satish: get access some time this week, has not heard from the sys
>>admin in Princeton, they should have the end point up and running by
>>Friday, currently testing Ayla's EPR. Also looking into component model
>>test plan.
>>
>>CDL is pretty good. Jun will work on it next week and Steve will run
>>    
>>
>the
>  
>
>>automation of inclusion thereafter.
>>
>> 
>>
>>    
>>
>>>2. OGSA and CDDLM F2F meeting on Thursday 
>>>   
>>>
>>>      
>>>
>>Jun and Dejan will attend, Stuart will attend remotely.
>>
>> 
>>
>>    
>>
>>>3. Going over the BLAST example that Jun provided 
>>>   
>>>
>>>      
>>>
>>Steve: We should have quotes right, turn off autocorrect smart quotes.
>>
>>Ayla: uncertain about specifying "code base", how the engine would not
>>that. How does the engine work, each implementation should chose to
>>understand the code base. Jun: this example is not meant to have a
>>running code, but describe how it is used for BLAST code, in the real
>>code one would have to write a real URI and some appropriate URI.
>>Guilherme: too much flexibility and decision on implementation could
>>lead to different understanding of "code base", this should be a
>>    
>>
>problem
>  
>
>>for interoperability. In other words, CDL can not work in certain
>>implementation. Steve agrees with that. 
>>
>> 
>>
>>    
>>
>>>4. Going over the scenarios that Steven Newhouse provided 
>>>   
>>>
>>>      
>>>
>>Team will review the document.
>>
>> 
>>
>>    
>>
>>>5. Various
>>>   
>>>
>>>      
>>>
>>Update on the documents. CDL is almost done with the reviewing.
>>Deployment APIs will go through the steering committee review shortly.
>>
>>Thanks,
>>
>>Dejan.
>>
>>
>> 
>>
>>    
>>
>
>
>  
>