**A Review of Service Interface Design Approaches for**

**Interoperability of Heterogeneous Systems**

Norziana Yahya<sup>1</sup>\*, Mohd Azahani Md Taib<sup>2</sup>

<sup>1</sup> Faculty of Computer and Mathematical Sciences, Universiti Teknologi MARA Perlis Branch, Malaysia

<sup>2</sup>RichTech Synergy Sdn Bhd, Menara Maxis, 26th Floor, KLCC, Kuala Lumpur, Malaysia

Corresponding author: \*norzianayahya@uitm.edu.my

Received Date: \*date

Accepted Date: \*date

ABSTRACT

*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, subsystems, processes, and interfaces that affect the system integration architecture at the initial design stage.* *A review on types of System Integration Patterns (SIP) covering File-Based, Common Database, Remote Procedure Call (RPC), Socket, Distributed Objects, and Messaging has been carried out to support this study. Based on literature review, we define three prominent approaches to Service Interfaces Design (SID) namely Method-oriented Interfaces, Message-oriented Interfaces, and Resource-oriented Interfaces.* *Discussions on these approaches serve as a basis for the solution of interoperability of heterogeneous systems. The findings from this study shows SID approaches able to interoperate with all types of SIP. In conclusion, theoretically, combination of SID approaches selection will be able to provide improved interoperability for heterogeneous SI.*

*Keywords: System Integration, Service Interface, Interoperability, Service Oriented Architecture*

# 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 (Roshen, 2009; Buyle, 2017). Impacts from this situation, information are unable to exchange effectively and this leads to the interoperability problem in SI (Hohpe and Woolf, 2011; Masethe et al., 2016).

Indeed, the success of interactions among the systems depends on how well the service interfaces are exposed (Henkel and Zdrakovic, 2005; Teo and Kadir, 2006). The stability of the service interfaces in solving the SI problem has been the subject of many researchers such as in (Larsson, 2007; Djavanshir and Khorramshahgol, 2007; Nilsson et al., 1990). To address the interoperability issues (Rezaei et al., 2014), interfacing processes need to be made more easily by defining components, subsystems, processes, and interfaces that affect the SI architecture at the initial design stage. The importance of service interfaces in integration process utilizes this study to focus on the interoperability of the service interfaces involved.

Service Oriented Architecture (SOA) with Web Services (WS) concepts has been chosen as a system architectural to guide researcher in this study. A number of the research regarding SOA have decided to address the implementation of WS as a technology used to implement the principle of service orientation (San-Yih et al., 2007; Wei et al., 2011; Shej and Cico, 2011; Zhao et al., 2011; Awang, 2015;). A well-designed service interfaces concept used in WS is said to be an important element in order to make ease of SI (Jie et al., 2010).

Based on literature review, three prominent approaches related to Service Interface Design (SID) have been reviewed and discussed in this paper which was method-oriented, message-oriented and resource-oriented. We present the summary of each approach that could be clustered in a single interface model to provide high interoperability in heterogeneous SI.

# OVERVIEW OF SYSTEM INTEGRATION

Generally, SI is understand as connecting up two or more systems physically and logically to satisfy the needs of an organization. Most researchers agreed that the SI is difficult and complicated. They also have their own definitions of SI. It would include a huge number of topics and it means different thing to different people (Zaitun and Wood-Harper, 2000).

From an architectural perspective, the concerns of SI is more on the technical solutions used to fulfil requirements on functionality and quality attributes such as performance and reliability (Nilsson et al., 1990). Another study stressed on the importance of determining the architecture and design of components, subsystems, processes, and the effect of the interface to the process of integration (Jain et al., 2008).

Druffel, director of the Software Engineering Institute at Carnegie Mellon University defines SI as an effective integration at a system-level architecture that allows the integration of system components and allows later integration of unplanned components. The effective integration involves an integrating mechanism that allows for data and function sharing of the applications.

**Interoperability**

Interoperability is defined as "the ability of two or more systems or components to exchange information and to use the information that has been exchanged" (ISO/IEC/IEEE 24765, 2017). Other definition of interoperability is "the ability to share information and services" (Open Group, 2018). In a complex organization, the degree to which the information and services need to be shared is a very useful architectural requirement.

In this study, interoperability refers to the ability of two or more systems to work together, to allow for information exchange (Slater, 2012) as well as to enable them to operate effectively together by adhering to common standards. The integration of different systems to use different data models and formats can be accomplished through mutual communication languages and protocols.

**Heterogeneous Systems**

According to the Merriam-Webster online dictionary, heterogeneous is defined as consisting of dissimilar or diverse elements or components. Ghazi et al. (2015), define a heterogeneous system as a system comprised of multiple systems (system of systems) where at least one subsystem exhibits heterogeneity with respect to the other systems.

The system of systems approach taken in development of heterogeneous systems give rise to various challenges due to continuous change in configurations and multiple interactions between the functionally independent subsystems. The challenges posed to heterogeneous systems are mainly related to interoperability (Xia et al., 2009).

# SYSTEM INTEGRATION PATTERNS

In this section a few patterns of SI are described. The purpose is to look at the methods and the mechanisms used for sharing data or information.

**File-Based**

Storing data in a file is universal and being the most common method of data sharing. This is because the files can be stored on most operating systems and hardware systems. 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.

![](148-1-392-1-4-20200831_media/media/image1.png)

Figure 1: File-based data sharing method

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).

**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.

![](148-1-392-1-4-20200831_media/media/image2.png)

Figure 2: Common Database sharing method

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.

**Sockets**

Sockets provide real-time connection between applications performed as a communication connection point in a network (client/server networking). Socket application programming interfaces are the network standard for TCP/IP and supported by wide range of operating systems (Hohpe& Woolf, 2011). The program that uses a socket can be located on the same system or on the different systems on the different networks. Figure 3 shows code flow for sharing data using sockets.

![](148-1-392-1-4-20200831_media/media/image3.png)  
  
Figure 3: Code flow for sharing data using sockets (Source: Roshen, 2009)

Socket has to be created then specify the IP address and port. Next process is, to using connect() method to request connection then the client can start exchange the data by read from and write to the socket. In this method, the data is shared in real-time because the listening application able to read data as soon as the second application writes the data.

**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.

![](148-1-392-1-4-20200831_media/media/image4.png)  
  
Figure 4: Remote procedure calls between different hosts

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 4). 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 user-defined 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.

![](148-1-392-1-4-20200831_media/media/image5.png)

Figure 5: Object Request Broker Architecture (CORBA)

Three models of distributed objects are Microsoft’s Distributed Component Object Model (DCOM), Java Remote Method Invocation (RMI), and Common Object Request Broker Architecture (CORBA).

Like RPC, DO also employ synchronous interaction. Client application is allowed to do further work until the server application completes its work and returns control to the client application (as illustrated in Figure 5).

**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 publish-and-subscribe. Point-to-point allows message to be given to one receiver only (as illustrated in Figure 6). In publish-and-subscribe, any number of receivers can get and act on a message (as illustrated in Figure 7).

![](148-1-392-1-4-20200831_media/media/image6.png)

Figure 6: Point-to-point Queue

![](148-1-392-1-4-20200831_media/media/image7.png)  
  
Figure 7: Publish-and-subscribe Queue

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 ORIENTED ARCHITECTURE**

SOA is an approach with a service orientation concept and interactions between services are defined using a description language. Connell (2003) described service as a module of business or application functionality with exposed interfaces, and are invoked by messages. Meanwhile, Crawford et al. (2005), have different perception where service described as a self-contained and maintains its own state.

Figure 8 shows the famous triangle that often used to illustrate the concept of service interaction in SOA. There are three essential elements for service interaction involved stated as below:

1.  > Register the service to a registry (Register).

2.  > Locate the service (Find).

3.  > Make service calls and message exchanges (Bind and execute).

![](148-1-392-1-4-20200831_media/media/image8.png)

Figure 8: Typical Service Interactions in SOA

A view from (Jie et al., 2010) in their research work, the communication between services is completed through simple, well defined service interface. In a service-oriented environment, service interface definitions are available in some form of service registry (Bloomberg, 2006; McGovern et al., 2003). An interface describes the contract between the service consumer and the service provider (Allen, 2006). Services in this paradigm defines the “how-to” of assigning interfaces in a servicing method which undoubtedly leads to independent of hardware platforms, operating systems and programming languages (Jie et al., 2010; Kester and Kayode, 2013).

There are a number of researches works dealing with an approach for describing SOA (Josuttis, 2007; Bloomberg, 2006; Marechaux, 2006; Brown, 2008; Krafzig et al., 2005; Papazoglou & Heuvel 2006). It’s one of the most remarkable technologies in the domain of information systems’ design and architecture in the modern world of technology (Niknejad, 2014). Therefore, SOA with WS concepts has chosen as a system architectural to guide researcher in this study.

**Web Services**

WS are communication methods between two applications over internet which can convert an application into a Web-application and publish its function or message to the rest of the world. WS place together a set of XML-based technologies which provides a standard way for communication and interoperability of heterogeneous computing environments.

In (Vogels, 2003), WS is defined as a method for server access that uses World Wide Web (WWW) to enable applications to offer services to users using a defined interface. WS in (San-Yih et al., 2007) is defined as software components that are reusable over the internet to develop other applications based on SOA.

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, 2004). WS can be published and discovered using UDDI. WS interactions share a common WSDL file. Figure 9 shows typical relationship of WS.

![](148-1-392-1-4-20200831_media/media/image9.png)  
Figure 9: Web Service Typical Relationship Lifecycle

SOAP is a lightweight protocol for exchanging XML messages among applications (SOAP, 2007). It supports both asynchronous and synchronous style of communication. SOAP messages are referred to as SOAP envelope and consist of two parts, Header and Body. Information is optional in the header. Information to be transmitted to the receiver is in the message body.

WSDL is a standard method to describe services provided by a particular web service and their interface (WSDL, 2007). It specifies what data to be sent, what the expected return data is and what protocol to use (Khosrow-Pour, 2006). WSDL consist two parts, abstract part and concrete part. The abstract part consists of types, messages, operations and port types, without concrete binding or implementation. The concrete part describes a service, specifying service bindings, constructs and ports.

Extensible Markup Language (XML) becomes the most important standard in WS development. It’s provides a middleware-independent format for the exchange data. It has emerged as a powerful self-describing language to enable businesses to share information and conduct transactions on the Internet.

The emergence of XML as a standard, to a large extent, has driven the evolution of application integration technologies (Erl, 2004; Ho, 2003). SOAP, UDDI, and WSDL are XML-based.

**SERVICE INTERFACE DESIGN**

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 important to design service interfaces because the interactions of the components are highly depending on the exposed service interfaces.

Service interface 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 those SID have been identified by previous researchers (Henkel and Zdrakovic, 2005; Teo and Kadir, 2006).

There are three common approaches to SID i.e. method-oriented, message oriented and resource-oriented. Next sections will describe on each approaches accordingly.

**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 and Figure 7 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 message-oriented design, XML plays a major role, whereas the WSDL plays a minor role.

**Resource-Oriented Interface**

The resource-oriented interface or constrained interface (Orchard, 2003) 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 (Lucchi, R., & Millot, 2008) and content-oriented interfaces are used in lieu of constrained interfaces.

**Summary of SID Approaches**

Table 1 summarizes the overview of the three prominent SID approaches which could be clustered in a single interface model to provide high interoperability in heterogeneous SI.

Table 1: Summary of SID Approaches

<table>
<thead>
<tr class="header">
<th><strong>Method-Oriented Interfaces</strong></th>
<th><strong>Message-Oriented Interfaces</strong></th>
<th><strong>Resource-Oriented Interfaces</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><ul>
<li><blockquote>
<p>RPC type.</p>
</blockquote></li>
<li><blockquote>
<p>Service consumers have to know the service interface definition exactly.</p>
</blockquote></li>
<li><blockquote>
<p>Changes on the interface will need the service to be updated (tightly coupled).</p>
</blockquote></li>
<li><blockquote>
<p>Service consumers invoke an application-specific operation on a service endpoint.</p>
</blockquote></li>
<li><blockquote>
<p>Description of operations that the interface supports and their parameters are contained within WSDL files.</p>
</blockquote></li>
<li><blockquote>
<p>XML plays a minor role whereas WSDL a major.</p>
</blockquote></li>
</ul></td>
<td><ul>
<li><blockquote>
<p>Interface is fixed.</p>
</blockquote></li>
<li><blockquote>
<p>Message structure is changeable.</p>
</blockquote></li>
<li><blockquote>
<p>All the messages are described by using XML schema.</p>
</blockquote></li>
<li><blockquote>
<p>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.</p>
</blockquote></li>
<li><blockquote>
<p>XML plays a major role whereas WSDL a minor.</p>
</blockquote></li>
</ul></td>
<td><ul>
<li><blockquote>
<p>Interface adheres to a fixed set of standardized operations.</p>
</blockquote></li>
<li><blockquote>
<p>HTTP is one of the resource-oriented interfaces.</p>
</blockquote></li>
<li><blockquote>
<p>Possible to build large distributed systems.</p>
</blockquote></li>
<li><blockquote>
<p>Interface is standardized does not need to be updated.</p>
</blockquote></li>
</ul></td>
</tr>
</tbody>
</table>

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 very practical due to various systems with various technologies involved in the SI.

**CONCLUSION AND RECOMMENDATION**

In traditional SI, application developers are more familiar with single SID approach 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 file-based and remote procedure call.

Selection of a single approach for heterogeneous SI is not very 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.

**REFERENCES**

Allen, P. (2006). Service Orientation: Winning strategies and best practices. Cambridge University Press.

Awang, N. (2015). MIPAF: A Policy-based Middleware Framework to Control Nedative Effects of Software Evolution*. Journal of Theoretical and Applied Information Technology*. Vol.70 No.3.

Bloomberg, J., (2006). Process-Driven SOA: Leveraging Service-oriented Architecture for Business Process Innovation. ZapThink White Paper. Unpublished.

Brown, P.C. (2008). Implementing SOA : Total Architecture in Practise. Addison-Wesley.

Buyle, R. (2017). Towards interoperability in the public sector. Presented at the *ISWC2017, the 16e International Semantic Web Conference*. Vol. 1931, pp. 1-8.

Connell, B. (2003). Service-oriented architecture (SOA). Retrieved Feb 16, 2010, 2010, from <http://www.microsoft.com/biztalk/en/us/business-rule-framework.aspx>

Crawford, C., Bate, P., Cherbakov, L., Holley, K., \&Tsocanos, C. (2005). Toward an On Demand Service-Oriented Architecture. *IBM Systems J*., vol. 44, no. 1, 81-107.

Djavanshir, G. R. \&Khorramshahgol, R. (2007). Key Process Areas in Systems Integration. *IT Professional*, vol. 9, pp. 24-27.

Erl, T. (2004). Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall PTR, Upper Saddle River, NJ, USA

Ghazi, A. N., Petersen, K., \&Börstler, J. (2015). Heterogeneous Systems Testing Techniques: An Exploratory Survey. Paper presented at the *Software and Systems Quality in Distributed and Mobile Environments, Cham*.

Henkel, M. \&Zdrakovic, J. (2005). Approaches to Service Interface Design. In Proceedings of the *Web Service Interoperability Workshop, First International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA'2005)*. Geneva

Heterogeneous. (n.d.). Retrieved June 25, 2018, from <https://www.merriam-webster.com/dictionary/heterogeneous>

Ho, H. (2003). What is Service-Oriented Architecture?. O'Reilly XML.com, Retrieved Jan 18, 2010, 2010, from <http://www.xml.com/pub/a/ws/2003/09/30/soa.html>

Hohpe, G. & B. Woolf (2011). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. The Addison Wesley Signature Siries.

ISO/IEC/IEEE 24765 (2017). ISO/IEC/IEEE 24765:2017(E) Systems and software engineering--Vocabulary, New York, NY.

Jain, R., Chandrasekaran, A., Elias, G., \&Cloutier, R. (2008). Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity. *IEEE Systems Journal*, 2(2), 209-223.

Jie, J., Hai-feng, X., & Ling, Z. (2010). The Design for General-purpose Interface of Community Informatization Basic Database Based on SOA. Paper presented at the *2010 International Conference on E-Business and E-Government*.

Josuttis, N.M. (2007). SOA in Practice. O'Reilly Media, Inc, ISBN: 13: 978-0-596-52955-0

Kazman, R. (2013). Understanding Patterns for System-of-Systems Integration. Software Engineering Institute.

Kester, Q.-A., & Kayode, A. I. (2013). Using SOA with Web Services for effective data integration of Enterprise Pharmaceutical Information Systems. *International Journal of Advanced Research in Computer Science and Software Engineering(IJARCSSE)*, Vol 3(Issue 6), 1-8.

Khosrow-Pour, M. (2006). Encyclopedia of E-Commerce, E-Government, and Mobile. *IGI Publishing.*

Krafzig, D., Banke, K., & Slama, D., (2005). Enterprise SOA: Service-Oriented Architecture Best Practise. Prentice Hall.

Krzyzanowski, P. (2010). Remote Procedure Calls. June 08, 2013, from <http://www.cs.rutgers.edu/~pxk/416/notes/15-rpc.html>

Larsson, S. (2007). Key element of software product integration processes. Marladalen Universiti Press, 50-57.

Lucchi, R., \&Millot, M. (2008). Resource Oriented Architecture and REST. JCR Scientific and Technical Reports. Retrieved Jan 15, 2010, from <https://inspire.ec.europa.eu/reports/ImplementingRules/network/Resource_orientated_architecture_and_REST.pdf>

Marechaux, J.L. (2006). Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus. IBM Software Group

Masethe, H.D., Adewumi, A.O., & Masethe, M.A. (2016). The Scoping Review of Integration of Heterogeneous Healthcare Systems. *Proceedings of the International Multi Conference of Engineers and Computer Scientists* 2016, Vol I.

McGovern, J., Tyagi, S., Stevens, M., & Matthew, S. (2003). Java Web Services Architecture. *Morgan Kaufmann Publishers*.

Niknejad, N., Ghani, I., \&Hussin, A. R. C. (2014). Organizational Factors Affected by SOA Adoption : A Critical Overview (2008-2013). *Journal of Theoretical and Applied Information Technology* Vol. 64 (No.2).

Nilsson, E.G, Nordhagen, E. K, \&Oftedal. G, (1990). Aspects of System Integration. *Center for Industrial research*.

Open Group (2018). TOGAF Standard, Version 9.2. Retrieved Jan 25, 2018, from <http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap22.html>

Papazoglou, M.P., & Heuvel, W.J., (2006). Service-Oriented Design and Development Methodology. *International Journal of Web Engineering and Technology (IJWET)*.

Rezaei, R., Chiew, T. K., Lee, S. P., & Shams Aliee, Z. (2014). Interoperability evaluation models: A systematic review. *Computers in Industry,* 65(1), 1-23.

Roshen, W. (2009). SOA-Based Enterprise Integration: A Step-by-Step Guide to Services-based Application Integration. McGraw-Hill, Inc.

San-Yih, H., Ee-Peng, L., Chien-Hsiang, L. & Cheng-Hung, C. (2007). On Composing a Reliable Composite Web Service: A Study of Dynamic Web Service Selection. *IEEE International Conference on Web Services.*

Shej, A., \&Cico, B. (2011). Integration of Applications Based on SOA in Government Institutions. *1st International Symposium on Computing in Informatics and Mathematics (ISCIM 2011)*.

Slater, T., (2012). What is Interoperability?. *Network Centric Operations Industry Consortium - NCOIC,* 2012.

SOAP (2007). Simple Object Access Protocol (SOAP), Version 1.2. Retrieved May 11, 2017, from <https://www.w3.org/TR/soap/>

Teo, H. M. \&Kadir, W. M. N. W. (2006). A Comparative Study of Interface Design Approaches for Service-Oriented Software. *XIII Asia Pacific Software Engineering Conference (APSEC'06).*

UDDI (2004). Universal Description, Discovery, and Integration (UDDI). Version 3.0.2 Specification. Retrieved Jan 15, 2010, from <http://www.uddi.org/pubs/uddi_v3.htm>

Vogels, W. (2003). Web Services are not distributed objects. *IEEE Internet Computing,* Vol. 7, Issue 6., 59-66.

Wei, N., Song, M. N., Xu, K., & Jiang, C. (2011). A Novel WebService Architecture Based on REST. *Advanced Materials Research, International Conference on Smart Materials and Intelligent Systems, SMIS* 2010*,* 143-144.

WSDL (2007). Web Service Description Language (WSDL), Version 2.0. Retrieved August 6, 2010, from <https://www.w3.org/TR/wsdl20-primer/>

Xia, Q., Peng, T., Li, B., & Feng, Z. (2009). Study on Automatic Interoperability Testing for E-Business. Paper presented at the *2009 International Conference on Computational Intelligence and Software Engineering*.

Zaitun, A. B., Mashkuri, Y., & Wood-Harper, A. T. (2000). Systems Integration for a Developing Country: Failure or Success? A Malaysian Case Study. *The Electronic Journal of Information Systems in Developing Countries*, 3(1), 1-10.

Zhao, X., Liu, E., \&Clapworthy, G. J. (2011). A Two-Stage RESTful Web Service Composition Method Based on Linear Logic. Paper presented at the 2011 *IEEE Ninth European Conference on Web Services*.