Issue 3821: Accessing Server-side File Systems: (ftamftp-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: There is no operation in the IDL to allow for directly accessing a file’s contents. However, this scenario has been considered. In order for a CORBA application to access the contents of the files on a server-side file system, it would be necessary for that application to provide an object implementing the FileTransferSession interface. Only the FileTransferSession::transfer (in File src, in File dest) operation and the FileTransferSession::protocols_supported attribute would have to be fully implemented. The procedure for transferring the contents of a file would be as follows; The reduced FileTransferSession would be instantiated. A File object would be created, setting the associated_session attribute to point to the reduced FileTransferSession object. The name, complete_file_name and parent attributes can be set to arbitrary values. The FileTransferSession::transfer() operation would be called on the remote FileTransferSession, passing in the remote File as the src parameter, and the locally created File as the dest parameter. The reduced FileTransferSession object would accept transport connections on the address’s specified by the FileTransferSession::protocols_supported attribute. When the connections have been set up, the remote FileTransferSession will call the transfer() operation on the reduced FileTransferSession, and transfer will commence. The reduced FileTransferSession object can then read the contents of the file from the transport connection. Data may be written to a remote file in a similar fashion, however the reduced FileTransferSession will have to be able to set up transport connections. The append() operation may also be implemented in the same way, if so desired. Resolution: see above Revised Text: Complete details are in Section 2.1.4 File Transfer that describes the file transfer negotia-tion and Section 2.2.3 that defines the requirements for supporting a corba based trans-fer. The CosFileTransfer::OctetTransferIterator interface is defined in Section 3.1.9 OctetTransferIterator Actions taken: September 11, 2000: received issue Discussion: Resolution Allow corba interfaces to be used along with “ftam” and “ftp” to transfer a file. This allows pure clients to use the service and removes the requirement that two services both speak ftam or ftp to transfer a file. The original IDL was under specified in regard to negotiating a transfer protocol or com-pleting the required handshaking for file transfer. The IDL has been modified to negotiate a transfer connection in a manner similar to the A/V streams specification. A mandatory corba interface for file transfer has been defined: CosFileTransfer::OctetTransferIterator. With the new IDL, clients and service implementations can negotiate the transfer protocol at runtime. Clients can be written generically without concern for the actual transfer mechanism. The OctetTransferIterator interface itself is: interface OctetTransferIterator { FileOctetSeq get_octet_seq(in FileOffset from_octet, in FileCount max_octets) raises (FileSystemError); void put_octet_seq(in FileOffset to_octet, in FileOctetSeq octetSeq)raises(FileSystemError); void destroy() raises(FileSystemError); }; End of Annotations:===== From: Stephen Egan Organization: Broadcom Eireann Research Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ftamftp-ftf@omg.org Subject: [Fwd: FW: FTAM/FTP RFP issues] Content-Type: multipart/mixed; boundary="------------C9E636FBB03DEA826AB1C596" X-UIDL: %-[!!MfW!!9O!!!p#B!! Accessing Server-side File Systems: There i The reduced FileTransferSession would be instantiated. A File object would be created, setting the associated_session attribute to point to the reduced FileTransferSession object. The name, complete_file_name and parent attributes can be set to arbitrary values. The FileTransferSession::transfer() operation would be called on the remote FileTransferSession, passing in the remote File as the src parameter, and the locally created File as the dest parameter. The reduced FileTransferSession object would accept transport connection The reduced FileTransferSession object can then read the contents of the file from the transport connection. Data may be written to a remote file in a similar fashion, however the reduced FileTransferSession will have to be able to set up transport connections. The append() operation may also be implemented in the same way, if so desired. Best Regards, Stephen Egan ---------- From: Marcin Przysowa [SMTP:mprzysow@bya1c16.pl.lucent.com] Sent: Friday, September 01, 2000 3:55 AM To: Rutt, T E (Tom) Cc: Roman Biesiada Subject: FTAM/FTP RFP issues Tom, In fact I implemented FTAM/FTP gateway according to earlier version of FTAM/FTP RFP what I realized now. Most of bugs were corrected but in RFP 2000-02-04 still one remains. There is an operation defined in FileTransferSession interface called "delete" which is to delete the file in file system. The "delete" is a C++ keyword so it cannot be mapped from IDL to C++. Another issue is related to the architecture. We would like to provide a customer with an IDL for accessing server side file systems. The most important operation is a file transmission. In current design of FTAM/FTP Interworking there is a "transfer" operation that copies file between two Virtual File Systems. In this case customer will have to implement his VFS and a driver (or we will have to implement for him) and we afraid that from his point of view it may be not acceptable. I would like to know if an operation of FileTransferSession which just returns file contents is considered for FTAM/FTP RFP (i.e. operation that returns sequence of octets). In this case customer will not have to implement his VFS - the file contents will be retrieved by simple IDL operation. Thanks and regards, Marcin -- Marcin Przysowa Administration Application Services Networks Application Development phone +48 52 349 1304 Bydgoszcz, Poland e-mail:mprzysowa@lucent.com [] sen.vcf s on the addresss no operation in the IDL to allow for directly accessing a file Date: Tue, 20 Feb 2001 16:39:41 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Comment on issue 4055, 3821: Architecture Issue / Server Access Message-ID: <20010220163941.D10708@ooc.com.au> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: IGG!! To: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss Date: Tue, 20 Feb 2001 18:31:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: 8_&!!2@/!!$,Z!!9Mfd9 But everybody has FTP. Why use CORBA to pump large amounts of data, when FTP does the job fine. I think that a CORBA response with a 35 MB message size seems unattractive to me. Tom Rutt terutt@lucen t.com ter ---------- From: Ted McFadden [SMTP:tmcf@ooc.com.au] Sent: Tuesday, February 20, 2001 1:40 AM To: ftamftp-ftf@omg.org Subject: Comment on issue 4055, 3821: Architecture Issue / Server Access Hi, Comment on ftam/ftp issue 4055, 3821: Architecture Issue, Accessing Server Side File Systems --------------------------------------------------------- Issues 4055, 3821 appear to refer to overlap. I have to agree with the original submitter of this issue, Marcin Przysowa [SMTP:mprzysow@bya1c16.pl.lucent.com], that it is highly desirable to allow a client to read / write a file without having to implement a (limited) FileTransferSession object to do so. Forcing a client to implement a server object requires the client to act as a mixed corba client and server, which requires an orb's server side support to be present (linked in). Since the specification does not allow for using CORBA to actually perform the file transfers, this also burdens pure client applications with writing and testing protocol handlers. A new handler would have to be written each time a new file system supported_protocol is encountered. It should be possible to add interfaces that allow for a pure client to read or write to a File using a CORBA interface. Providing such an interface would allow any two Virtual File Systems to transfer files because at a minimum they would both support the `corba protocol', in addition to "tcp" or whatever. This would help address issue 4056, concerning protocol bridges. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts Inc. - An IONA Company http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Wed, 21 Feb 2001 11:16:09 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss In-Reply-To: <4490F7068AC0D111A7120008C72878EC085E69D5@nj7460exch003u.ho.lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: LKT!!$i[!!))Wd95)""! On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > But everybody has FTP. Why use CORBA to pump large amounts > of data, when FTP does the job fine. > > I think that a CORBA response with a 35 MB message size seems > unattractive to me. Tom, no-one is talking about sending 35 MB messages with CORBA here. Naturally, file contents are transferred in smaller chunks. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Michi Henning'" Cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss Date: Tue, 20 Feb 2001 22:26:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: /p!e9D4:!!lped9*m!"! If you send each File segment in a separate corba message, you are re-inventing a file transfer protocol. With the ubiquity of FTP why do this? Tom Rutt ter ---------- From: Michi Henning [SMTP:michi@ooc.com.au] Sent: Tuesday, February 20, 2001 8:16 PM To: Rutt, T E (Tom) Cc: ftamftp-ftf@omg.org; 'Ted McFadden' Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > But everybody has FTP. Why use CORBA to pump large amounts > of data, when FTP does the job fine. > > I think that a CORBA response with a 35 MB message size seems > unattractive to me. Tom, no-one is talking about sending 35 MB messages with CORBA here. Naturally, file contents are transferred in smaller chunks. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 21 Feb 2001 13:30:54 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss In-Reply-To: <4490F7068AC0D111A7120008C72878EC085E69D8@nj7460exch003u.ho.lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c-Zd9F!O!!,BCe9)29e9 On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > If you send each File segment in a separate corba message, you are > re-inventing a file transfer protocol. With the ubiquity of FTP why > do > this? The FTP-FTAM spec is about providing CORBA access to virtual file systems. The way it is written, the client must have built-in support for FTP or FTAM, which begs the question what CORBA is doing in this picture to start with. The aim should be to allow a CORBA client to access files that are on such a virtual file system without having to know about the various protocols involved (that is, a pure CORBA client should be able to do file transfers). When you look at comp.object.corba, you will find that one of the most commonly asked questions is: "How can do file transfer with CORBA?" Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 23 May 2001 14:37:32 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Issue 3821 comment Message-ID: <20010523143732.D27054@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: ]`'e9$'nd9~gT!!`--!! Some comments on this issue: I think that there should be IDL to support reading a file's contents without requiring a client to go through another object (FileTransferSession). There are a number of reasons why a client should be able to set up a transfer and then transfer a file directly with CORBA. -- 1. clients (embedded devices, portable devices, etc...) that only support a client side CORBA library will not be able to transfer files but would benefit greatly from being able to do so. 2. clients, even if they implement a FileTransferSession, is required to have knowledge of the specific transfer protocol that the server supports. This is unacceptable. 2A. This also means any two implementations of the FileTransferSession will only interoperate if they support the same non-corba transfer protocol. This puts serious constraints on future implementations wishing to work with existing ones. The current specification esentially demands that file transfer take place as is done with FTP, where the data is streamed over a socket and the socket closure denotes end of file. (This works ok with local file systems and FTP, I'm not so sure about FTAM.) What happens when there is a future implementation that is not FTP/ FTAM based and use of TCP sockets for data transfer is not appropriate or violates security/firewall policies? The older client will not be able to talk to the new implementation. That is unacceptable, given that we're just talking about file transfer here. 3. If an organization has gone to great lengths to make sure there CORBA usage is secure, why force them to worry about security for out-of-CORBA-band data transfer, unless they want to? 4. Not being able to access the incoming file data stream puts undue restriction on the client, as it may have no local concept of a `file' or the storage space to save it. It is a valid application to process the file stream as it is received. -- A least common denominator of being able to transfer strictly using CORBA should be available, so that *any* client will always be able to transfer files with any CosFileTransfer implementation. This is not to say that a client should not be able to negotiate a different transfer protocol with a server. Nor does it require, that once the transfer is set up, that a CORBA iterator be used to send/receive the file octets. The prototype IDL I posted last week supports transfer between file systems as described in the spec using either corba or TCP sockets. It supports allowing `pure' clients to set up a transfer to/from a server and then to transfer using the negotiated protocol (corba or TCP) We have used this when talking to an FTP based server, to allow the client to talk directly to the FTP server's data connection. The upshot of all this, is that IONA is planning a YES vote on this issue. Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia