XJFTP > FTP Process Diagrams

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

Important note about "Web Services"

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.

Server Side Replacement with Customer Handler Diagram

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.

alternatively...

Client Side Full XJFTP Solution Diagram 2

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:

Write your Handler and ensure it calls your web service client successfully
Configure XJFTP to use your Handler, which calls through to your web service
Test that an FTP client communicating with XJFTP is seeing the data from your web service
Ensure that this test works from outside your firewall
Package up XJFTP, your Handler JAR and any configuration changes into a ZIP or installer
Send this bundle to your client site, and have them install it
Ensure they have allowed the server to have outbound HTTPS access to your Web Server
Get them to configure their FTP Client Application to talk to their local XJFTP server
This should now result in their FTP Client having a transparent connection to your web service

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.