Interface

If two application components want to communicate with each other, there must be an interface between them specifying details of the communication. The interface represents a logical channel through which internal functions of an application component are exposed, enabling external systems to call them as services. An interface is a group of logically related messages which can be sent to the receiving system.

According to who exposes the functionality, interfaces could be internal or external. Internal interfaces are exposed by the systems within the organization, so the organization owns them and is responsible for their documentation. The external interfaces, on the other hand, are provided by systems that are not controlled by the organization. Therefore, the client applications must know how to call such interfaces - they need an interface specification. The specification must be provided by the interface vendor and serves as a formal contract between the supplier of the interface and its clients.

The implementation of the interfaces depends on the type of integration: calling a service or exchanging data files:

Type 1: Sending Messages

The first type of integration is based on sending messages from the source system to the target system, where receiving the message invokes a specific operation on the target's side. The system, which was called sends back the result, either after the request was completed (synchronous) or immediately, without waiting for the request to be processed (asynchronous).

The following diagram shows the Customer Management System exposing the Customers interface, which provides 3 services. Calling these services by Front Office System is demonstrated using a sequence diagram:

Type 2: Batch Interface

The message interface illustrated in the previous example is a convenient way to create real-time integrations between the systems but are not suitable for executing high-volume repetitive tasks. This type of integration is modeled using a batch interface, which is based on sending big data files for processing during non-peak times that trigger a background process. Typically, the system providing a batch interface is waiting for a data file of a given structure, and then it processes it.

Unfortunately, there is no clean solution to document batch interfaces using UML, as the notation is based on sending messages and does not support the procedural way of modeling. One way to overcome this issue is to introduce an abstract operation, AcceptFile(), in this case, which indicates that the Reporting System accepts a batch file. Its structure is defined via the CustomerInput data file that is passed to the AcceptFile() operation as a parameter.