XJFTP > FTP Process Diagrams
This page may look a bit complicated when you first look at it, but if you take a little time to follow the diagrams through one by one, it should become clear how the solution is intended to work
Whilst and much of the documentation about XJFTP refers to Web Services, it is not restricted to web services for communication! If you have a proprietary protocol, RMI, JMS, Corba/IDL or any other Java-compatible interface to your application, you are free to use this as your preferred communications mechanism. All that XJFTP requires you to do is write a Java class that adapts its RequestHandler Interface to be compatible with the client for your comms mechanism. Some different examples of this will be provided in the source code for XJFTP.
|Fig. 1 : Standard FTP Client -> Standard FTP Server connection for transferring data from site to site.|
|This diagram shows how a standard (RFC959 compliant) FTP client application connects to any FTP Server. A Traditional FTP is ok if you are only supporting a small number of clients, but in Enterprise-Scale applications you often need to support thousands or tens of thousands of users. You therefore need more disk space, and managing the user accounts (securely and reliably) becomes a problem.|
|Fig. 2 : FTP Client -> "Out of the box" XJFTP Server (simple swap-in replacement for another FTP Server)|
|You could replace your existing FTP Server with XJFTP. Whilst you are free to do this, it doesn't really provide you with any tangible benefits, other than not requiring OS-level accounts for authentication (not a unique feature to XJFTP).|
|Fig. 3 : FTP Client -> XJFTP FTP Server with customised handler.|
This is where it starts to get interesting. If you configure XJFTP to call your own Handler implementation
(via the SpringFramework configuration file), you can do something more powerful than simply reading/writing
files on a disk. You could write a Handler to store the files into a database for example. The diagram shows
XJFTP calling a Web-Service client, which submits the files into the Enterprise Application's web service
interface. Because Web Services are based purely on XML, there's nothing to stop XJFTP and your JavaBean Handler
submitting the XML Web Service request into an application running on another architecture (.NET, Perl etc)
The only disadvantage of this solution, is that you still require FTP access across the Internet. This is both insecure (unless a VPN is used), and requires firewall configuration.
|Fig. 4 : FTP Client -> FTP Server Connection for transferring data from site to site.|
Solution 4 requires exactly the same amount of programming/development as Solution 3, but is much easier to setup.
If you have a Web Service interface to your Enterprise Application, you most likely already have HTTP and HTTPS access
to your application from the whole Internet. You can leave the FTP ports completely closed on your firewall, and yet
an FTP client is still able to communicate with your application!
What you need to do:
It really is that simple! Because XJFTP is distributed under the Apache License you are free to bundle it with your own JAR files (containing your Handler and Web Service Client), and distribute this to your client site.
Copyright © 2005 XJFTP Team. All rights reserved. Licensed under Apache License v2.0 (The Apache Software Foundation)