External communication in the 3 Tier Architecture

Question

When I read about the 3 Tier Architecture I can not understand where communication over eg FTP and Telnet fits the model.

Should I place the communication layer beside the Data Access Layer?

It seems logical when I use FTP and Telnet to retrieve and update information in an external system, just as you do with a database. Moreover, one can hide the complexity of the telnet commands behind the Business Layer.

Or is there any best practice within the model that I can use?

Edit

FTP

Ftp is used to read and update files located on an legacy system. It can therefore be seen as a form of data access component.

The files to be retrieved from the system can be both source code and configuration files. I will map the configuration files with DTO objects to make it more easily to work with them.

In the future, we plan to expose the legacy file system as a normal Windows File System so that we can access it as a normal file system.

Telnet

Telnet is used to:

• Give commands to the system
  This do not belong to DAL, maybe it can lie alongside the DAL in a separate layer
• Get the information from the system
  I'm not sure where this belongs. I can, for example, be interested in the status of the system, which feels as DAL. But to get this information, I have to run Telnet, and then it feel like as same as the point above.
• Communicate with the real-time database
  In the legacy system, there is a real-time database which we have to access. We plan to expose it with a modern database interface (eg ODBC) in the future, but today it is only possible to access it via telnet. Maybe I can create a LegacyDbBlock in DAL which internally uses Telnet functionality?

Here's a suggestion on how I might be able to design it . Is it a good idea?

Answer 1

What do FTP and Telnet accomplish in the context of the system?

FTP is typically used to store and retrieve data, in the form the files. That is a kind a data access. If this is how FTP is used, then FTP belongs in the data abstraction layer. For example, there might be a new component named Company.FtpDataBlock. FtpDataBlock component would play an analogous role a relational-data access component. Instead of connecting to a relational DB, it connects to an FTP server. The FTP server could be placed in the DatbaseServerSide rectangle, or you could create a new rectangle called "FileServerSide".

Business entities in the business layer would send requests to the data access layer for information. The data access layer then decides how fulfill the request by choosing the appropriate data access component. Ideally, the DAL insulates the business entities from knowing if the data store is an RDBM, FTP server, WebDAV server, NoSQL DB, or anything else.

Telnet is a little more difficult. Telnet is more general than FTP and is generally used for command and control. The FTP protocol is actually built on top of telnet, if I remember correctly.

If the application uses Telnet for command and control, then conceptually it does not not really belong in the data access layer. For practical reasons, you might end up treating it as a session-based data source. Issuing a command becomes a combination of a sychronous data-write (the command) and data-read (the response).

However, if Telnet is really used to issues commands to another system, then it should be in another box with a name like "Gateway" or "External System Access Layer". Architecturally you can treat Telnet like another other remote-procedure-call technology such as SOAP.

Of course, it all depends on how Telnet is being used.