[cddlm] In preparation for the CDDLM/ACS joint session at GGF14

[Keisuke Fukui]

Hi Steve,

Thanks for your comments.
Although not complete, here are some comments:
- We understand the File upload stuff is meant to be a transient/interim
   and a real repository is expected.
- We have one use case with commercial data center for ACS, where clients
   exist outside of the data center and submit their task to the system, then the
   task is deployed and executed in the system. In this case, it might require
   much and/or indeterministic latency for component to pull the data outside
   of the system.
   Thus, we assumed that it is more reasonable to have data repository inside
   the system, even though it may not be what the CDDLM specification requires.
   We assumed that the purpose of having AddFile is to "push" the data
   from outside to inside of the system in advance. Then components can
   "pull" the data easier from there.
- As such, the file server in the case 1 diagram may not be a primary
   or sole implementation of CDDLM, but we understand it is among possible
   implementations of larger system under the current CDDLM specification.
   (We may have had to color it neutral one rather than light blue.)
- I understood all topics are about the case 1 diagram. Do you have any
   issues on case 2 or 3?

BTW,
Thanks for a heads up for JSR 277. We will keep an eye for it.
It sounds like the improvement of the jar itself and pretty much java
focus.

  -Keisuke

Steve Loughran wrote:
> Keisuke Fukui wrote:
> 
>> Folks in the cddlm-wg,
>>
>> As you know we will have a joint session at GGF14 between CDDLM and ACS.
>> This is in preparation for the session from acs-wg.
>> After the GGF13 inside the acs-wg, we studied and discussed about the
>> possible interactions between CDDLM and ACS, especially in terms of
>> "File upload" section and AddFile() in the deployment API document.
>> Sequence diagrams in the attachment describe our interpretation about
>> how CDDLM works, and our proposal for the possible interactions in the 
>> case
>> that the ACS co-exists in the system. We believe our proposal goes along
>> with what the current set of CDDLM specifications define and doesn't 
>> require
>> change in the original definitions.
>>
>> We are looking forward to discuss about this at the joint session
>> for CDDLM/ACS at GGF14. It is very much appreciated if we get responses
>> before the joint session at GGF14 in case that important overlook in our
>> understanding is found. Please feel free to make comments or questions.
>>
>> FYI,
>> At GGF14 joint session, we'd like to start our discussion with this
>> diagram and if we don't find critical issues, we may go down to the
>> detail of the interface and/or advanced interaction. We'd also like
>> to hear requirements on ACS in terms of the event notification and
>> asynchronous invocation of the interfaces, if the time permitting.
>>
>> Thanks in advance for you efforts on this!
>>
>> Best Regards,
>> Keisuke Fukui
>> ACS-WG
>>
> 
> thank you, I will comment briefly.
> 
> -The File upload stuff was very much written to be a transient/interim 
> solution in the absence of a real repository, which is why it is so 
> minimal and barely functional. I didnt want to be dependent upon 
> anything not yet designed, but didn't want to do a repository myself
> 
> -the current revision allows the sender to declare the URL schema to 
> use. That could be file: for a shared filesystem and http: or https for 
> HTTP access. It could also be fancy custom stuff; there is some java 
> project whose name escapes me that provides a multicast URL resolution 
> system, the file could be stored across multiple machines without ever 
> having to give them a hostname, which is very good for fault-tolerance.
> 
> -There is also support for adding metadata to a request, but nothing to 
> do searches, retrieval, or even introspection on what stuff is 
> supported. I've left that for implementations.
> 
> -There is the perennial problem of how to get files up over SOAP. SwA is 
> only available in java distrubutions, and then not consistently, DIME is 
> in .NET WSE and Axis 1,x, but even more unpopular. As for MTOM, well, 
> who implements that yet?
> 
> As a workaround I've put in stuff for having the endpoint actually 
> retrieve the files themselves, but this is a bit unsatisfactory, because 
> it requires the files to be broadly visible on the 'net, and introduces 
> race conditions. Otherwise, data goes inline in base-64 encoded form, 
> unless/until MTOM lets you pretend that the file attached to the message 
> is really inline base 64.
> 
> 
> here are two example mesages and responses from the XSD-validation tests
> 
> 
> 
>     <api:addFileRequest>
>       <api:name>urn://45</api:name>
>       <api:mimetype>application/x-pdf</api:mimetype>
>       <api:schema>file</api:schema>
>       <api:uri>http://example.org/files/source.pdf</api:uri>
>     </api:addFileRequest>
>   </t:test>
> 
>     <api:addFileResponse>
>       <item>file://nas1/temp/source.pdf</item>
>       <item>file://nas2/4fgdbb.tmp</item>
>     </api:addFileResponse>
> 
> 
> 
>     <api:addFileRequest>
>       <api:name>urn://46</api:name>
>       <api:mimetype>application/x-ssh-key</api:mimetype>
>       <api:schema>http</api:schema>
>       <api:data>
>       AAAAB3NzaC1yc2EAAAABIwAAAIEAwVmUkPzXdWEyJZ8nCR8GvdrDtO00RI4Z
>       Bg3Gyviuz5IrWj2C6b2BdcKn+S/swDV1fiEFY4+ewYHUfmg+UKm2T8Lfksjn
>       Hinks0GoVvkwy3bF48U5yVk1akAzR5YbSLJa6Naj8XS9681xVzWpbjxrV3KR
>       QNWvEqI0MqRE34MzT4M=
>       </api:data>
>       <api:metadata>
>         <x:expires date="2005-07-18" xmlns:x="http://example.org/expiry" />
>       </api:metadata>
>     </api:addFileRequest>
>     <api:addFileResponse>
>       <item>http://server/job5/files/1</item>
>     </api:addFileResponse>
> 
> 
> On a related note, I see that Fujitsu are listed as one of the 
> interested parties in JSR 277, the java modules/repository proposal. Are 
> you involved in that?
> 
> -steve
>