WMW: A Secure, Web based Middleware for C4I Interoperable Applications

Modern-day enhancements in Enterprise Architectures (EA) has increased the interoperability issues in almost all domains; these issues are increasing day-by-day as organizations are spanning and information is being exchanged between different platforms. Command Control Computer Communication and Intelligence (C4I) complex systems are also facing the interoperability issues due to highly classi ﬁ ed and sensitive information being exchanged. In this paper we have discussed the integration of different C4I applications running under heterogeneous platforms by allowing them to communicate using a secure and ciphered web based middleware named as Web Middleware (WMW). This middleware is a client-server based web adaptor to achieve clean, systematic, secure and reliable communication. The main feature among many is the simple HTTP browser based customization that do not require any speci ﬁ c or special add-ons and controls to be installed on the client machine. Architecture usage, and initialization of the WMW middleware is discussed with security and performance discussion.


INTRODUCTION
Data integration is the main goal and task of different organizations working under different domains from last 02 decades. Every organization has different means of data transfer depending on the environment they are using. A small organization comprises of few number of computerized systems doesn't have that much critical interoperability issues. Big organizations dealing with huge integration between different channels have major integration issues. These issues get critical when applications are penetrating on different platforms. Changing the complete computerized structure of a huge organization for future interoperability is a massive task that requires cost ef icient solutions and will affect the whole enterprise working and behavior.
If any large scale domain lacks structure, ef iciency, communication and on top of all information security then this will not only affect that particular organization but it will mess up the functions of other organizations associated with it. In this research, we are stressing upon Command, Control Computer, Communication and Intelligence (C4I) interoperability, commonly known as System of Systems (SOS) or Command & Control (C2) [1].
The main interoperability issue of a complex C4I System is joint operations; these issues are already well de ined and pointed out in many studies [1][2][3][4][5]. There may be different C2 systems and applications running under different C2 platforms, the problem gets more complex when different C2 platforms are exchanging information using a single platform. Every C2 application has its own crucial information which may be required to interoperate with another C2 application and that information should be same and un-forged as it was sent. Considering this scenario, there are many interoperability issues and hurdles which are observed e.g. platform dependency, security structures, terminology differences, metadata structuring and many more [6,7].
The best way to accomplish complete and secure interoperability is to introduce a middleware platform that act as a bridge to communicate different domains to exchange information without platform dependencies. In a small organization, the integration platform can be based on desktop application. But in a huge environment like C2 infrastructure, where a single system is controlling and interfacing many systems located remotely, the preeminent way to accomplish the interoperability task is to use secured web based middleware.
In this research we have proposed a Web Middleware (WMW). The rest of the paper structure is discussed as follows: Section II discusses literature review, Section III describes the WMW architecture, Section IV addresses its usage, Section V covers its core features, section VI covers the conclusion and future work.

LITERATURE REVIEW
Mainly, proxies are used for irewalling and other security related to networks. Although research is present on which the whole communication is dependable on proxies, however, very unassertive research is available that is identical to our research, especially for a complex system as C4I.
In 2013, Dickerson et al, discussed the ROSE methodology applied to a large scale SOS tactical data-link interoperability. A model-driven architecture is engaged using the ROSE method. This technique recommends a repeatable approach for the analysis performed by the Of ice of Chief Engineer of the U.S. Navy. This study concentrates on a framework and factorized SOS architecture for selection and evaluation of portfolio. This case study has analyzed the original data-link interoperability [8]. A general purpose proxy system and its usage have been discussed with respect to mobile environment in the paper title, "A General Purpose proxy iltering mechanism applied to mobile environment." [9].
David. J and others, in their paper title "ANTS: A Toolkit for building and dynamically deploying Network protocols", present a novel approach to build and deploying network protocols, without the need of coordination and without unwanted interaction between existing protocols [10]. Introduction of an adaptable interface, including adaptable protocols, to adopt the change in the resources and protocols is being presented by T. Kunz and J.P. Black, in their paper title "An Architecture for adaptive mobile applications." [11].
Mika. L and others demonstrated their designed communication architecture that makes it possible to exploit the existing TCP/IP protocols. How the architecture is used to improve the WWW information browsing. In their paper title "Optimizing World Wide Web for Weakly Connected Mobile Workstations: An Indirect Approach" [12].
Above we have shortened our literature review posting due to the paper lengthiness, there were many reviews with respect to the settlements of remote adaptations of web information using proxies [13,14]. There were many papers related to time-outs and delays and performance. Example pro ile based pre-fetching with local and remote proxies to reduce the web sur ing waiting time delay. As discussed in [15] the number of links diagonally on the wireless link can be reduced using remote processing.

WMW ARCHITECTURE EXPLANATION
There are numerous customs in which our research is different from other studies: • WMW adapting system designed speci ically for the WWW.
• We have used a simpli ied coding instead of using generalized coding, which we have discussed in depth in our forthcoming article.

•
The prominent feature and utilization of Restricted Working (RW) that is capable of handling multiple Distant Working (DW) at a time.
The stimulation behind this research is to develop and program a web based middleware that acts as an overpass to help communicate dependable platforms together without changing their dependencies and without motivating the client to install additional plug-ins/add-ons or upgrade infrastructure resources which are usually require in many middleware based applications.
In our interoperability process, when a request is passed by any application that require speci ic data integration from another application, it routes to the speci ic middleware adapter. The request is being altered according to the requirement of that middleware adapter before the communication. As a result, the request is being forwarded to the requested server for response. As soon as the response reaches back to the adapter it transforms or alter the response and send it back to the originator.
Requester doesn't have to know who the responder is and vice-versa. This is because, for the requester the responder is the WMW adapter which is available in the form of a proxy and for the responder the requester is also the WMW adapter. WMW architecture contains two workings; Restricted Working (RW) and Distant Working (DW). The requester has to deal with (RW) named as Restricted Working Request (RWR) and the responder has to contract with Distant Working Response (DWR), as illustrated in the igure 1.

PRIMARY ROLES OF RW & DW
That WMW middleware adapter is the combination of two workings i.e. RW and DW. It is because the roles for both are different and distinct in nature. The browser codes cannot be altered because altering any browser code during any data transformation is in any way not a suitable task. RW works crucially as a browser extension. The RW runs on RWR i.e. on request server, RW contains the information of system situations and availability of supply. The RW have further communication with DW for performance improving and performance status. Another primary role of RW is to keep track of data encryption and decryption being done in DW working.
DW distant working as the name speaks for itself is mainly responsible for remote activities for being deployed near the server or responder i.e. DWR. Main role of DW is to perform site dependable(s) and data irmness before it broadcast on any bandwidth. There may be number of web servers planted, each web server is handled by his own RW. In the same way, one client can easily handle multiple DW and each acts as a combination of separate RW and DW. However, the main difference is the RW generated by the client, runs on the same client server i.e. RWR, handling different RWs within a single instance. DW is different against each RW and each DW is assigned to each DWR or Web server separately as shown in igure 2.
The RW is available in the form of proxy settings con igured in the client's browser. The request automatically parses through the RW to their respective RWR which is then forwarded to the adapter. The client machine should be capable of handling such type of transactions; because these RWs can be located on different machines to distribute the load.

•
The middleware adaptors are built to introduce a middleware that can be easily implemented and accessed on any client browser. Therefore, the RWs are available in the form of hyperlinks that are clickable to access the speci ied RW. Further, we discuss the following two signi icant behaviors of the WMW adapter workingInitializing WMW, and • Query/Request execution

INITIALIZATION OF WMW
Browser should be con igured to use the speci ied RWR Server. The proxy settings are the only thing which is required to do that. The set of instructions and information required to initialize the corresponding adapter by clicking the hyperlink is stored and contained in a ile called Middleware Information File (MIF). Following information is stored in the MIF;

•
The 'congregation machine name' running the DWR server that is responsible to execute the RW of the adapter.

•
The veri ication certi icates for the server that is running the RWR.
• Java Archiving ile i.e. jar ile that supports and includes the execution of the java classes.

•
The java major class that is responsible for initializing the RW from the jar ile.

•
The java major class that is responsible for initializing the DW to send it back to the DWR server.

•
Initializing con iguration constraints for DW and RW. • The relevancy of Domain, which spells out the sites to be operated by the adapter.
• Initialization and con iguration page URLs.
The igures 3 and 4 are illustrating the above explanation clearly: and their appropriate MIF ile.
The above illustration demonstrates that the client do not have to know any sort of knowledge about their server location; they don't require to store those DWs which are not requested by the client.

QUERY/REQUEST EXECUTION
The main WMW association is the repository of websites which we have named as Relevancy of Domains (RD). The adapter will only receive and send the query on the basis of these listed relevant websites. On the reception of request, the behavior of the RWR is as follow: • Check the URL association within the RD domain.
• Send the query/request to RW and then to DWR Server.
• Choose the irst initialized adapter if URL is common in multiple RDs.
• Send back the failure request to the Web Server if no URL is found in the RD.
All the above is illustrated in igure 5.

INFORMATION SECUREITY & OTHER FEATURES & BENEFITS
Up-to this point we have discussed the architecture and behavior of our WMW. Further, we discuss the technical features of WMW. We have divided this discussion into following points:

OPERATION CONSISTENCY
The reliability of our WMW middleware is unique in a sense that even on unreliable connections the data is not lost. The technique which we have used is simple; the client requests many or multiple documents while browsing normally. Each request contains a separate connection; in case of loss of connectivity the browser simply displays the broken placeholder that allows the user to re-send the request. In case of a weaker link, the DW stores the object temporarily until the request is successfully sent back to the client. This all is done by the Operation Consistency Store (OCS), the OCS stores all the transactions records and lags only when there is a failure. The client operations are accessible to the client by accessing the non-completed requests. In this way there is no re-request generation.

INFORMATION SECURITY & CONFIDENTIALITY
There are two Coded/Encoded Mechanisms (CMs) available on both ends i.e. RW and DW. These CMs cipher the data from the requester and decipher it at the server end. The WMW middleware is basically content based, therefore; the CMs do not cipher/decipher sensitive information on detection.
The following is the low of CMs during ciphering:  • Ciphered content sent to RW over non secured connection for deciphering • Original query result provided to client WMW is secured and reliable in a sense that the whole communication is taking place on proxies and whether how open the client side is, the (CMs) used at both ends will tighten the security. There are many other options available to increase the security walls that can also be taken into consideration i.e. by installing additional irewalls, ilters etc.

PERFORMANCE
The performance factor is excessively vital for our WMW, if the performance is slow then nothing can be achieved and the concept of an ef icient web middleware cannot be ful illed.
The performance depends on the geographical locations of the contacted C2 servers, where the RWs are located. The web operations and WMW delay in response are the two important factors to be observed. These performance tests are planned to be covered in our forthcoming extended studies. Following listed issues are considered critical during operations, these issues are also highlighted in

CONCLUSION AND FUTURE WORK
This research discusses a thorough and detail functionality of WMW architecture, design, security and other bene its. The following conclusions have been made: • WMW is lexible as compared to adaptation • WMW provides the freedom of add-ons and pre-requisites that are the mandatory ingredients of most present middleware • WMW is considered to be a very user-friendly and easy to implement middleware • WMW is tightly interoperable to the web model, existing in present time This research is an ongoing work therefore; in our forthcoming studies we demonstrate the WMW middleware transparency and information iltering testing on various domains to have the consistency usage and irm ability knowledge. Our future based on its implementation using a case-study and testing.