A Middleware Application Framework for IOS David Alfred Ostrowski System Analytics Research and Innovation Center Ford Motor Company Abstract perspective of an application interface or extension of ETL-based design to support integration to cloud- For optimal utilization of pervasive architectures, a based resources [11][12]. Semantic web technologies comprehensive approach to the management of all have also been developed in support of a completely available resources must be considered. We examine ubiquitous environment. While providing a solution three categories including service-orientated to connectivity and integration in the enterprise they architectures (SOA), human machine interface (HMI) have not taken over as a dominant technology [14]. access to existing legacy applications and integration Despite these efforts, there are currently no IOS in of informational resources (e.g. file systems). To this general use due to three main reasons: 1) Users have goal we present an internet operating system (IOS) invested much in their application software, which architecture designed as a middleware application often meets their current problem solving needs. Due relying on a Representational State Transfer (REST) to this investment they will not adopt a new operating – based approach.. Our framework relies on a novel system that will not run their applications, whatever incorporation of a number of open source advantages it offers [15]. 2) Users tend to maintain a technologies including a document-orientated high degree of control as well as autonomy for their database and server-side Javascript. Initial machines even in a tightly knit organization [16]. 3.) experiments have demonstrated that our approach Performance also remains a concern, as there still is performs effectively among the dynamics of our an order of magnitude difference between transfer environment. times on a local architecture as compared to a network [17]. This paper defines an IOS-based architecture as a 1. Introduction solution to identified issues within the specified Networked computers have slowly gained domain. The paper follows in Section Two with a capability in the area of heterogeneity and review of prior work performed in this area. Section transparency. Recently, high speed internet Three outlines our architecture and Section Four technologies have accelerated access between provides a conclusion with future considerations. disparate architectures. The most popular implementation has been in the form of cloud 2. Current Research computing with users working with global storage Work attributed to IOS design was originally and software [1][2][3]. This approach has proliferated considered from the perspective of resource into the support of a complete web based operating management with many of these original objectives system which includes a file system, file remaining relevant. Jade was an early example of an management, production and communication architecture which provided a uniform way to name applications [4]. and access files in an internet environment [18]. (Rao The concept of a distributed OS has been in et. al.) proposed the extension of the scope of file existence for a long period of time from earlier systems from LANs to the internet, encouraging efforts including Amoeba, Chorus and Clouds collaborations and information on a broader scale operating system [5][6][7]. Newer environments [19]. (Liu and Dempsey) presented an Internet including Rebol, cloudi and eyeOS have supported resource management system with multiple facets accessibility between platforms thus overcoming the that provided tailored functions and associated user limitations of traditional client-server architecture interfaces to a hierarchy of users [20]. (Anderson et. [8][9][10]. Other current applications have taken the al.) supported the development of a global namespace discovery and integration. By following design for the means of supporting a file-system grid. [21] patterns of ETL architecture, views could also (Kumar et. al.) considered peer-to-peer distributed support filtering of data between existing data architectures to support scalability [22]. sources to provide higher level applications. Applications have driven the design of IOS in particular with work supporting the migration of 3.1 Data Flow legacy–based applications to virtual distributed Figure 1 shows the overall software architecture environments. Among them, (Beaty et.al.) examined from the perspective of a data flow. Here we installation, configuration settings and security issues designate three layers: 1) the client 2) our IOS regarding the movement of the applications from the prototype architecture and 3) the legacy environment. desktop to the cloud [23][24]. Pervasive Considering the start from client interaction, an environments have also largely influenced the HTML / javascript page served by a document development of IOS including [25][26][27][28]. database is utilized to invoke a resource. Each SOA technologies have also moved forward resource would in turn be routed through the database concepts of distributed OS with integration of proxy returning data directly to the client from a software lifecycle, transition plans between backend tier. conventional architectures and integration of In the first scenario (a) , the data flow is a direct semantics into user level design [29][30][31]. While communication from the client to an established initial web service implementations such as XML- REST resource. Correspondingly, updates from a RPC and SOAP , were originally designated in such client to the service could be directly routed through designs, REST-based architecture has gained the database. In the second scenario (b), a migration popularity due to its efficiency, brevity and support process would be supported for legacy applications of rapid prototyping [32]. To this end, it has thus requiring the decomposition and wrapping of a proliferated in many environments as well as in novel legacy system to be supported by a server. distributed applications such as Amazon web services Minimally, this would require an existing interface to [33][2]. be separated from the server component. Here, we Designed around REST-based philosophies, a consider this be served independently from the legacy number of projects supporting document-oriented application and invoked in a REST format from the databases have proliferated including couchDB , AJAX calls by a client (routed through the database). mongoDB and SimpleDB [34][35][36]. In particular, In the third scenario (c), resources such as file couchDB (frequently with server-side javascript) is systems could be established in a served environment described in implementation of distributed with identifiers distinguishing individual resources. applications [37]. AJAX/ REST implementations also Here, we would rely on single URLs supporting have been identified as suitable means for lightweight multiple resources extended through the addition of distributed applications [38]. unique identifiers for each handler. 3.0 Methodology a. b. c. Legacy Our position is that document-orientated database WS File system 3. Legacy application environment architecture can be leveraged to support the design of IOS. By supporting a REST-based philosophy, HTTP server server can be used directly to support this transition. This could be designed and tested incrementally across distributed resources thus allowing for 1) co- Documentation-database existence with current operating systems 2) fast server prototyping and 3) flexibility in implementation. Our 2. IOS application software architecture is presented from the perspective of our three identified domains. Here, each individual client would perform discovery, 1. client testing and integration of all accessible resources Figure 1.0 data flow diagram. within a desktop or mobile application. In this plan, the document database assumes the 3.2 Testing role of an application server supporting an MVC- Relying on a REST-based architecture, three influenced architecture. Here, resource descriptions distinct layers (client, database and backend-tiers) are are established as documents from which views identified supporting an independent testing process. would be created to support activities such as This allows for flexibility in incremental testing among the legacy environment. In the context of our Our service contract will exist as a document to be architecture, resource information along with testing published within the database. The process starts with logic is tightly coupled as they reside in the same the publication of each services contract. Step two application. Here, testing activities could be (supported by an application developer) is where the managed by views, with semantics to be directly registry documents would be scanned to identify the represented in URLs vs. reliance on Web Service most effective match. Step three involves the basic Description Language (WSDL) definitions such as in understanding of the use of the service. Step four traditional Simplified Object Access Protocol represents the extra work that is necessitated to (SOAP) implementations (Figure 2.). In this determine how to implement the service. Finally, step environment, tests can be supported at three five involves service construction. incremental levels: 1) service invocation from a utility (such as curl) 2) direct invocation routed 3.4 Security through the database or 3) GUI (browser) level tests While AJAX-based implementations