An Overview of Service Interface Design Approaches for Interoperability of Traditional System Integration Patterns

One of the major issues in system integration is to deal with interoperability of legacy systems which use traditional System Integration Patterns (SIP). Information are unable to exchange effectively when the systems involved comes from developer that tended to not interoperate and this leads to the interoperability problem in heterogeneous system integration. To address the interoperability issues, interfacing processes need to be made more easily by defining components, processes, and interfaces that affect the system integration architecture at the initial design stage. This paper includes a basic concept on types of traditional SIP covering File-Based, Common Database, Remote Procedure Call (RPC), Distributed Objects, and Messaging. An overview of three Service Interface Design (SID) approaches for systems interoperability is discussed. The discussions on these approaches serve as a basis for the solution of interoperability of heterogeneous systems which use traditional SIP.


INTRODUCTION
Over the years, system integration (SI) has become more complex and more heterogeneous due to rapid innovation in the IT industry. The complexity increases when the number of systems involved increased. Systems need to share information by sharing data and functionality of systems involved but it comes from manufacturer or developer that tended to not interoperate (L'Amrani et al., 2020;Buyle, 2017;Roshen, 2009). Impacts from this situation, information is unable to exchange effectively and this leads to the interoperability problem in SI (Paniagua et al., 2019;Masethe et al., 2016). Things get worse when this legacy system uses traditional SI methods that are less interoperable. In this paper, interoperability refers to the ability of two or more systems to work together, to allow for information exchange (Jakimoski, 2016) as well as to enable them to operate effectively together by adhering to common standards. The integration

BASIC CONCEPT OF TRADITIONAL SYSTEM INTEGRATION PATTERNS
In this section a few patterns of traditional SI are briefly reviewed. The purpose is to look at the methods and the mechanisms of this traditional SIP used for sharing data or information.

File-Based
File Transfer Protocol is the most common method of file transfers in the case of two applications running on two different machines. The text file is the most common type for file-based data sharing because the character is represented by one byte in almost all operating systems and languages (Kazman et al., 2013). This method allows different applications running on the same machine to read and write to the same file. Figure 1 shows how file sharing over a network.

Common Database
Common database method is quite similar with file-based method in term of data sharing where two applications running on two different machines able to read and write from/to a common database (Kazman et al., 2013). The database in most cases always runs on its own machine. Figure 2 shows how the common database method sharing data. Integration is achieved by storing all data in a shared database where it defines the schema of the database to handle all the needs of the different applications. The widespread use of SQL based relational databases as the common database become very popular for application integration. In addition, SQL is supported by almost all development platforms.

Remote Procedure Call (RPC)
RPC is a function-oriented interface. It is also known as client/server and 2 tier architecture. It introduced important concepts and features of functions sharing (Hohpe & Woolf, 2011). RPC involves synchronous function calls only where the calling code is allowed to do further work until the function returns. It has three types of function calls involved stated as below: 1. Local calls. 2. Restricted remote calls involving two applications (on the same machine). 3. RPCs between two applications (on different machines) connected by a network. In this method, the application calling the function is called client and the application where the function resides is called server (as illustrated in Figure 3). Thus, this method involves service concept and it may be considered as the beginning of the services-based integration pattern.

Distributed Objects -Object Request Broker (ORB)
Distributed objects (DO) are a method with language platform independence which means applications can share functionality even though it is written in different programming languages and different platforms (Hohpe & Woolf, 2011). The distributed objects extend the concepts of classes and objects introduced by object-oriented programming (OOP). Java and C++ languages are samples of OOP. Classes are userdefined constructs that encapsulate functionality and data related to a certain entity. OOP includes inheritance which leads to code reuse, and polymorphism that allows functions performing similar work can have the same name. Like RPC, DO also employ synchronous interaction. Client application can do further work until the server application completes its work and returns control to the client application (as illustrated in Figure 4).

Messaging
Three basic elements of messaging system are message, queue, and endpoint. Applications are communicating through queues. There are two type of basic queues which are point-to-point, and publishand-subscribe. Point-to-point allows message to be given to one receiver only (as illustrated in Figure 5).
In publish-and-subscribe, any number of receivers can get and act on a message (as illustrated in Figure 6). Messaging system is also called Message Oriented Middleware (MOM). One of the important features of MOM is guaranteed delivery. For example, a message sent to a target application is unable to be delivered due to network is down, the messaging system will try and try again until the message is delivered (which is the network is available).
Messaging is an asynchronous type interface. In this method, a service consumer who sends a message to a service provider is not waiting for the response. It allows the service consumer (client) application to perform other work while the service provider (server) is completing the request from the client.

SERVICE INTERFACE DESIGN APPROACHES
This section defines the SID approaches covering method-oriented service, message-oriented service and resource-oriented service. An overview of SID approach architecture is illustrated to show the proposed components involved in interfacing with legacy application using traditional SIP.
Service interface refers to a set of defined operations that enable the communication or integration process occurs. The "service interface" term is commonly used in the service-oriented environment that refers to communication point between components. It is one of the key elements for interaction in systems integration. It defines a way in which other elements can interact and exchange information with the service. Many approaches to SI with regards to SID have been identified by previous researchers (Papazoglou & Heuvel, 2007;Henkel & Zdrakovic, 2005;Teo and Kadir, 2006).
Service Oriented Architecture (SOA) with Web Services (WS) concepts has been chosen as a system architectural for SID approaches. Several research regarding SOA have decided to address the implementation of WS as a technology used to implement the principle of service orientation (Awang, 2015;Wei et al., 2011;Shej & Cico, 2011;Zhao et al., 2011). A well-designed service interfaces concept used in WS is said to be an important element to make ease of SI (Jie et al., 2010).
Most definitions of SOA identify the use of WS using Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery and Integration (UDDI) in its implementation. SOAP protocol is used for accessing a WS (UDDI, 2021). WS can be published and discovered using UDDI. WS interactions share a common WSDL file. Figure 7 shows typical relationship of WS. The following sections describes three approaches to SID proposed to provide solution for upgrading interoperability of traditional SIP. The three SID approaches are method-oriented interface, messageoriented interface and resource-oriented interface.

Method-Oriented Interface
Method-oriented interface is a design approach that allows a program or application to call procedures located in other domains or machines. The application is exposed as one or more network objects, each with a unique set of functions or service interfaces which can be invoked.
The service interfaces have a large set of operations and each operation performs a certain function. Service consumers have to know the exact definition of the service interface (Teo and Kadir, 2006). Figure 4 shows one of the technologies of method oriented.
In an environment where separate applications are communicating, any changes to the interface will require the service to be updated. This type of design can cause tightly coupled interfaces and also cause a lot of work in a large system in the case of changes to the interfaces. A good example of a method-oriented interface is the Remote Procedure Call (RPC) (Krzyzanowski, 2010).
In web service application, a specific operation on a service point with input arguments is invoked by service consumers. Description of the operations which the interface supports including their parameters is contained within WSDL files. But the use of XML schema to describe the parameter structures is optional.
In method-oriented design, WSDL plays a major role whereas XML a minor.

Message-Oriented Interface
In message-oriented design, service consumers consume a service defined in message structures instead of invoking function calls. The service endpoint embedded in the messages is sent to the Web service. In message-oriented design, the interface is fixed and changes are only made to the message structure. All the messages are described by using XML schema (Henkel and Zdrakovic, 2005;Teo and Kadir, 2006). Figure 6 show the technologies of message oriented. However, the design makes it difficult to interpret and understand the functionality provided by a service. The structure of the messages that the service can handle needs to be examined in order to understand the functionality of the service. In messageoriented design, XML plays a major role, whereas the WSDL plays a minor role.

Resource-Oriented Interface
The resource-oriented interface or constrained interface is an interface that adheres to a fixed set of standardized operations. An example of a resource interface is HTTP. HTTP defines the operations of PUT, POST, GET, and DELETE which are then applied to resources, located with Unified Resource Locators (URLs). With constrained interfaces, it is possible to build large distributed systems. Since the interface is standardized, it does not have to be updated. REST-style architecture, resource-oriented interfaces (Dar et al., 2015;Vettor, 2016) and content-oriented interfaces are used in lieu of constrained interfaces. Figure 8 illustrates the proposed architecture of SID approaches for legacy application involving traditional SIP. Based on this architecture, any traditional SIP used by the legacy application has to be converted into relevant SID to upgrade its interoperability with any web-based client applications.

Figure 8: SID Architecture
The first step is to define service interface. The legacy application has to define and establish type of data it requires to publish and share to other systems or applications. Service interface will define interface name and schema, and register them in the Service Interface Registry. The interface schema stored in the Service Interface Registry will also be published in the UDDI.
The type of service produced depends on the type of SIP and according to the compatibility between SID and SIP. For example, interfaces that use RPC are more suitable to be converted to Method Oriented Service. Table 1 provides example of definition of interfacing between the three prominent SID approaches and traditional SIP. SID approaches are suggested to be clustered in a single interface model to provide high interoperability in heterogeneous SI.  As summarized in Table 2, each approach has advantages and disadvantages, but it does not mean that architect has to choose the ideal approach as the solution to their SI. As long as the approach(es) can meet the demand of the integration requirements, either with single or combination of approaches, it can be considered has met the objective or purpose of integration. Selection of a single approach to SID of SI is not practical due to various systems with various technologies involved in the SI. ▪ Changes on the interface will need the service to be updated (tightly coupled).

Interface Schema
▪ Service consumers invoke an application-specific operation on a service endpoint.
▪ Description of operations that the interface supports, and their parameters are contained within WSDL files.
▪ XML plays a minor role whereas WSDL a major.
▪ Interface is fixed.
▪ Message structure is changeable.
▪ All the messages are described by using XML schema.
▪ Difficult to interpret and understand the functionality provided by a service. The structure of the messages that the service can handle need to be examined in order to understand the functionality of the service.
▪ XML plays a major role whereas WSDL a minor.
▪ Interface adheres to a fixed set of standardized operations.
▪ HTTP is one of the resource-oriented interfaces.
▪ Possible to build large distributed systems.
▪ Interface is standardized does not need to be updated.

CONCLUSION AND RECOMMENDATION
In traditional SI, application developers are more familiar with single type of interface that able to integrate with limited integration pattern or systems. In such case, the integration design is scoped within the context of single SID approach. For example, method-oriented services can only talk with few SIPs such as filebased and remote procedure call.
Selection of a single approach for heterogeneous SI is not practical due to various systems with various technologies involved in the SI. Hence, the SI involving SIP demands a service interface mapping mechanism which can mediate the interaction between SID and SIP during the integration process.
For future works, a mediator approaches could be a focus on providing access to specific functions or services for heterogeneous systems.