Architecture for Web-based services integration Vassilis Kapsalis1, Konstantinos Charatsis1, Manos Georgoudakis1, and George Papadopoulos1,2, Member IEEE 1. Industrial Systems Institute, Patras, Greece 2. Applied Electronics Laboratory, Dept. of Electrical and Computer Engineering, University of Patras, Greece
[email protected],
[email protected],
[email protected],
[email protected]
Abstract - Industrial applications and systems still lack in adopting the Web Services architecture. Legacy systems, either OPC-based or proprietary ones, compose a huge source of data, which can be migrated and integrated into enterpriselevel information systems. Within the context of prevailing and emerging technologies, such as HTTP, XML, SOAP, OPC and Web-enabled application servers, we propose an architecture that allows for the integration of existing stand-alone industrial automation systems into Web-based distributed environments, forming the base for the provision of largescale e-services by a multitude of service providers to industrial-type clients.
net in mind. This means it inherently doesn’t support the access of objects across Internet, resulting into problems when such an attempt is made. The third limitation is that the types of communication messages generated by the COM protocol are very complex and would have trouble being carried over any medium other than they were specifically built for. Sending COM messages over the Internet poses particular difficulties, mainly due to the presence of firewalls. Several approaches have been proposed to overcome these limitations [4], [5], [6]. In general, access to industrial networks is being achieved by accessing the DCOMbased data sources through pure HTTP and Java RMI protocols. However, these approaches although solving the problem of transferring industrial data over the Internet, are based on a point-to-point connection between industrial networks and end-users and cannot meet all type of requirements regarding security, manageability and extensibility. Recently, OPC Foundation has formed the OPC XML working group, which is currently working on the OPC XML-DA specification and has already published a draft version V1.8 [7]. The OPC XML working group will create XML data schema for use in exposing OPC data to applications over the Internet, enabling the sharing of timely manufacturing information from control devices and automation systems on the plant floor with applications throughout the manufacturing enterprise. Essentially, the OPC XML-DA specification will enable the development of OPC-compliant solutions with enhanced e-commerce capabilities and functionality, by delivering multi-vendor interoperability and plug-and-play connectivity to plant floor information via the Internet. This is the first step towards the direction of fully integrating the industrial automation data at the enterprise level. OPC XML-DA is an interface specification based on XML and SOAP – Microsoft’s Simple Object Access Protocol [8]. The data exposed is the same as in the older, DCOM-based OPC DA. Since XML and SOAP are the fundamental parts of Web Services, OPC XML-DA actually describes a Web Service [9]. This standard overcomes the two major drawbacks of the DCOM architecture, namely the platform dependence, since it operates on Microsoft platforms and the firewall unfriendliness. Another source of industrial type data, in addition to the real-time data sources, are the historical data, which are stored in databases within the industrial LAN and conform
I. INTRODUCTION Web is gradually evolving towards a service-oriented distributed environment by extended use of Web Services, which are loosely coupled software components delivered over the Internet through standards-based technologies, such as XML, SOAP and HTTP. Web services are a natural consequence of the Web evolution into an open medium, which facilitates complex business and application interactions, providing a viable solution for enabling data and system interoperability [1]. Nowadays there are a growing number of Web Services implementations across several industries, mainly in the Enterprise Application Integration (EAI) and the Business-to-Business (B2B) sectors [2]. The OPC Foundation, a major standardization organization, has published a multitude of standards related to the integration of industrial type data. These standards describe and enable the seamless integration of control networks with LANs [3]. OPC standards have launched a common way for connecting data sources such as automation devices, databases, etc., with host server applications. OPC technology is based on DCOM (Microsoft’s model for distributed computing - Distributed Common Object Model), allowing the integration of industrial applications and the sharing of their data locally over a LAN. DCOM is essentially an extension to the COM (Common Object Model), which allows the software components residing in different machines to communicate by replacing the local interprocess communication with a network protocol. However, several inherent features of DCOM make it not the ideal technology under all cases. First of all, it is a platform-depended technology, since it is best supported on Microsoft platforms. The second limitation concludes from the fact that this protocol was not built with the Inter-
0-7803-7906-3/03/$17.00 ©2003 IEEE.
866
to the OPC HDA specification [10]. OPC HDA restricts access within the LAN environment; currently, there is not any specification from the OPC Foundation for a standard, which would specify access mechanisms to historical data sources through Internet. Thus, historical data, which reside at industrial databases and are accessed locally by OPC HDA clients, cannot be accessed through Internet in a similar to OPC XML-DA, standardized way. In addition to OPC-based systems, there is a multitude of automation networks that utilize, in parallel to OPC, different technologies for their communication and integration to enterprise-level systems. A well-known control network of this type is LonWorks, which uses a proprietary technology, called LNS (LonWorks Network System) for achieving management, monitor and control of network nodes [11]. Each supported operation of the LNS can be performed locally, through DCOM-based clients and remotely through IP-based clients. A middleware technology with many similarities compared to DCOM is CORBA (Common Object Request Broker Architecture), which manages communication and data exchange between objects. Although CORBA is a robust object communication protocol with features such as object activation, stateful and stateless requests etc., it has quite a few drawbacks [12]. For instance, CORBA uses binary encoding for data transmission so it is assumed that both the receiver and the sender have full knowledge of the message context since no meta-data information is encoded. Although this approach offers better performance than XML where an amount of overhead is involved, it makes hard for intermediaries to process the message. In addition, CORBA relies on the Internet Inter-ORB (IIOP) protocol, which is firewall-unfriendly. The objective of this paper is to present an architecture that will enable the provision of large scale e-services by a multitude of service providers to end-users, over a common infrastructure, based on truly open standards, with high scalability and extensibility. A service provider is an entity, which provides some type of e-service(s) that require a network connection between it and its clients’ automation networks/devices. An e-service client can be any industrial site or building, with a network of automation devices (e.g., boilers, chillers, HVAC, alarm systems, etc.) that require value-added e-services. These e-services range from simple monitor and control functions, to sophisticated services, like equipment maintenance, energy management, surveillance, etc., which require extensive processing of both realtime and historical data, together with scheduling and reporting functionality.
Service Provider
Automation Network
Service Provider
Automation Network
Service Provider
Automation Network
Fig. 1. The Point-to-point model A. Point-to-point model In the point-to-point model, the service providers have to keep a separate network connection with each automation network as illustrated in Fig. 1. The number of pointto-point connections between n service providers and m networks is potentially up to n × m. Thus, although this approach is highly resilient, it has a major drawback regarding manageability, especially as connections increase. This approach has the following major features: •
•
•
•
The Web gateway, which will constitute the entrypoint to each client’s automation network, must implement an adequate security policy for protection from unwanted traffic and hacking attacks. The implementation of this policy is of great importance and it must address requirements such as authentication, authorization, data integrity and confidentiality. Service providers need to know about the particulars of each connected network, its protocols, gateway dialect and devices. If the configuration of an industrial client’s automation network changes, for instance by replacing a gateway or the ISP, all service providers that provide services to this client must update their databases. Security administration, to control which devices and operations the service providers are allowed to access, is spread between different Web sites, potentially having different user interfaces and even security models. There is no central schedule of events and things that should happen within the industrial environment at specific intervals or points in time, including periodical gathering of measured values and events needed by service providers.
II. POSSIBLE CONNECTION MODELS B. Hub-and-spoke model In an analogy to Enterprise Application Integration (EAI) Systems, there are two models for the connection between service providers and clients’ automation networks, namely point-to-point and hub-and-spoke [13].
The hub-and-spoke model (Fig. 2) adds a central point between the clients’ automation networks and the service
867
providers. The operator in the middle becomes an aggregator of digital services to consumers (Service Aggregator). In contrast to the point-to-point model, the number of connections between n service providers and m networks, is potentially up to n + m instead of n × m. The features of the hub-and-spoke approach are the following: •
•
•
• •
Taking into account the above-mentioned features of both models, it can be concluded that the hub-and-spoke solution is more advantageous, in the long term, for the provision of large-scale e-services. Thus, it is the architecture followed by our approach, as illustrated in Fig. 3. On the right side of the figure, there are the clients’ automation networks, either industrial or building networks. In the middle, there is the Service Aggregator, which forms the core of the e-services system. Finally, on the left side, we have the service providers (and end-users), which interact with the SA and use its services.
Service providers only need to talk to the Service Aggregator (SA), who takes care of all the details for each individual client network in a transparent way. SA is able to support multiple device control standards, gateway types and communications protocols, in a way that is transparent to the service providers. End users (industries, building operators, etc.) can centrally control how service providers are allowed to access their networks, assigning authorization and security parameters. All events and things that should happen within the client’s automation network at specific intervals are specified and stored in a Scheduler component which is detailed in the following section. The services/applications can be updated centrally, bringing immediate benefits to all users. The hub-and-spoke architecture introduces the single point of failure risk, requiring redundant/clustered configurations and high-availability systems.
Service Provider
A. The industrial site’s infrastructure It is assumed that access to automation networks at the clients’ sites is either OPC-based or is provided by some type of proprietary interfaces, like LNS of Echelon, which are based on COM technology or could be COM-wrapped. These COM servers can provide access to the local DCOM-based SCADA client applications, too. The followed approach, in order to achieve connectivity and extensibility of legacy automation networks over the Internet, in the client’s network side involves rendering the COM servers into SOAP–enabled objects [14]. This can be easily achieved by using one off-the-shelf SOAP toolkit. However, in order to achieve 1-1 consistency between the methods and properties of the COM server and the SOAP server, the COM server must follow specific conventions such as implement all its methods under a single Automation Interface or ensure that the properties’ types are supported for conversion by the SOAP toolkit. Experimenting with various OPC and proprietary servers has shown that this is not usually the case and therefore only partial conversion can be achieved in terms of functionality, which most likely will be unacceptable. This approach is preferred only in the case where the COM server will be developed from scratch and therefore it can conform to the limitations imposed not only by SOAP itself but also from the SOAP toolkit that will perform the conversion. In the case where the entire software infrastructure of the automation network will be implemented, the developer can always design the comprising parts as pure SOAP objects avoiding the hassle of conversion.
Automation Network
Service Provider
Automation Network
Service Aggregator
Service Provider
Automation Network
Fig. 2. The Hub-and-spoke model III. SYSTEM ARCHITECTURE
Service Providers
Service Aggregator ASP
Automation Networks
Soap-based Interfaces
Table of values 1 0:0 0
1 0:0 5
1 0:1 0
1 0:1 5
104
123
132
133
145
p ara me ter 2
122
111
135
154
130
p ara me ter 3
121
125
134
144
129
p ara me ter 3
135
130
109
132
143
p ara me ter 4
146
137
145
134
132
157
168
168
179
165
p ara me ter 1
p ara me ter 5
Industry / Building Automation
IIS
1 0:2 0
ASP Internet SOAP / XML
Internet SOAP / XML
Soap Soap Server Server
Web browser / SOAP client
Fig. 3. End-to-end system architecture
868
COM COM Server Servers
Automation controller (OPC, LNS, etc.) COM Server
COM Client of automation controller
COM Server wrapping
SOAP Server wrapping
Service Aggregator Database
Fig. 4. Access to a COM-based server Billing
The proposed solution, in order to render a COM server (i.e. the automation network controller) to a SOAP server, is to create a COM client on the automation network side that will be bound to the COM server (Fig. 4). This COM client exposes methods, which are mapped to the corresponding methods of the COM server. The COM client has a COM wrapping so it also operates like a COM server whose methods call the methods of the underlying COM server at the automation network side. The client has been carefully designed in order to easily attach a SOAP wrapping by a SOAP toolkit. In the end, at the automation network side we have a SOAP server which maps to as many methods of the original COM server as desired. Although this solution apparently dictates the development and use of additional components, it is a rather easy method to extend the usability of automation networks, while ensuring consistency between the functionality of the original COM server and the resultant SOAP server.
Access Control
Configuration
Authentication
Scheduling
Web GUI
Interface Adapters
Fig. 5. Functional blocks of the Service Aggregator Authentication and encryption: The SA provides a high level of security to clients wishing to access automation networks. It is equally important to ensure that established sessions cannot be eavesdropped from the outside. To this end, the SA relies on well – established techniques. To deal with eavesdropping, SA makes use of HTTPS, which is essentially the use of HTTP over the Secure Socket Layer (SSL) protocol. Alternatively, IPSec might also be employed. Since 128-bit length keys are employed, intercepting successfully an established session can be next to impossible. Additional security can be implemented by configuring the gateways at the clients’ automation networks to accept incoming connections only from the SA, thus further reducing the possibility of a security breach. Since all communications take place over HTTP, the SA can be safely configured to establish connections at port 80 (HTTP) and 443 (SSL) for both service providers and automation network servers. As far as the implementation is concerned, it can safely rely on off-the-shelf software components, which on some cases are built-in in the operating system (i.e. IPSec) or hardware devices. The data that the user provides are verified against those stored either in a relational database – in the case of small-scale applications or in an LDAP server which is optimized for quick retrieval of the requested information while holding millions of records. Access control: The purpose of access control is twofold. Primarily, it ensures that authenticated users are able to invoke allowed operations only. Secondly, according to privileges each user has, it creates dynamically a user interface that reflects the access rights of the user. The SA’s access control implementation is based on a role-based scheme. Users are assigned one or more roles. However, the role assigned serves as a template since customization can be performed in order to restrict or empower the user. When invoking operations such as sending commands to devices, the system checks whether the user requesting to issue the command has the required access rights and if so
B. The Service Aggregator The Service Aggregator will allow clients (service providers and end-users) to access the services exposed from remote SOAP servers residing at the clients’ automation networks. SA must incorporate much more functionality than merely making available the functions exposed from the automation networks (e.g. the OPC servers). Support for access control, authentication, billing is essential for the overall model to meet real-world application demands. The SA will be comprised of the following modules as it is illustrated in Fig. 5: - Authentication and encryption - Access control - Billing - Scheduling - Interface adapter - Configuration & Web GUI These modules must also expose their functionality over the Internet as an API in order to be feasible for a custom client application to seamlessly manage the remote automation network(s) through the SA. In order to meet this requirement, the modules can be implemented as pure SOAP servers, or alternatively they can have COM wrapping and be given a WSDL file and a scripting page (e.g. ASP) so that they can manifest themselves as SOAP servers if calls are made to the scripting page that instantiates them. Each module is a self-contained server that exposes a number of methods and properties.
869
adapters will encompass the functionality exposed from the network controllers, they must also incorporate a standard set of functions that will allow uniform data manipulation from the SA. As far as the installation of an Interface Adapter is concerned, this can be performed by the Configuration module, which is detailed below. The SA therefore acts as a content management system as it has to manipulate different Interface Adapters, security settings, the files that instantiate the SOAP objects and, depending on the user settings, they might as well manage data obtained from the automation networks. Configuration & Web GUI: The Configuration module allows a user (service provider) to manage his account settings and customize the data retrieval and handling from the remote automation network. The user can determine whether the retrieved data are stored at the SA site, which might be the case for non-sensitive data or sent directly at the service provider’s site. Forwarding the data to the service provider’s site can be achieved either by letting the client application at the user site to manage them or by sending them to the user in a predefined format. The SA supports a number of data formats such as CSV, XML, etc. Given that the native format of the data as they arrive from the Interface Adapters are in XML (SOAP packets) there is a common denominator for all parsers that have to be implemented. The Configuration module also provides the Web GUI through which a user can manage the Scheduler module. The user can also add Interface Adapters to the SA in order to support different types of automation networks. The administrator can have total control on all Interface Adapters and insert new ones or disable existing ones at will. Through the Configuration module he can change account settings for all users and can map users or group of users with particular automation networks. To summarize, within the Configuration module, a user can perform the following: - Change account settings - Insert a new Interface Adapter - Insert a new ASP page that will call and instantiate the SOAP object. - Choose a format for the returned data - Set the timer of the Scheduler to perform specific tasks - Obtain the location of CSS and/or HTML pages associated with an automation network that he could modify in order to change the Web GUI.
it permits operation invocation. Otherwise, a handled exception is thrown and the operation is not carried out. The scenario described applies when the client makes use of the exposed API programmatically, i.e. accesses the automation network through the SA which acts as a server for a SOAP client residing at the service provider’s side. In the case that the Web GUI is used, the operations that the user is allowed to perform have been determined prior to the GUI instantiation since, as has been mentioned before, the GUI presented to each user corresponds to his access rights. A user who is assigned the Administrator role can only perform customization of user accounts. Billing: Though not compulsory, the SA can be provided by a third party. Of course, it is possible that the vendor who has installed a multitude of dispersed automation networks has also a SA to control all these automation networks from a central point. However, if the SA is provided by a third party, then some sort of billing mechanism must exist. Charging can be based on a per-hour use basis or per transaction. In addition to standard data about each transaction (account reference, time stamp, service package reference, unit price and total amount fields), the system can store an XML document further describing the specifics of the transaction in question, to aid in billing and perhaps in final charge calculation. If the SA is not provided by a third party, then the Billing module can be omitted. Scheduling: The SA’s comprising modules can interact with each other through SOAP mechanisms; thus, it is possible to invoke operations in a timely fashion. This can be easily implemented by using a timer to call methods of the SOAP servers residing in the Interface Adapter module. The Scheduler can collect for example the values returned from specific devices within a remote automation network by setting time intervals for specific data retrieval. The Scheduler is essentially a global timer module which can be called by all users while each user’s scheduler presets are stored in the user’s account database. Essentially there are two levels when configuring the Scheduler: one per user and one per service/function. The Scheduler API, though COM–based in its core implementation, can be called remotely using its WSDL file, which will instantiate a SOAP server object that will point to the Scheduler COM server and call the requested method. Interface Adapter: The core feature of the SA is the Interface Adapter since this component is essentially a customizable interface that ensures the extensibility of the SA. On the SA side, the Interface Adapter for each client’s remote automation network is a SOAP client that calls the methods exposed from the SOAP server on the network side. Moreover, the SOAP client residing in the SA must be able to expose this functionality over the web so that service providers and end-users can interface to the remote automation network either by using the Web GUI provided by the SA or by custom SOAP client applications. Therefore, the SOAP client on the SA side is also a SOAP server, which acts as a network adapter. Although the
C. Service providers Service providers will be clients of the SA’s services and will use the functionality provided by its modules, in order to provide value-added e-services to their own customers. Service providers can use two types of clients: Web browsers and custom applications operating as SOAP clients. In both cases, access will be provided by the corresponding URL endpoints (ASP-based), residing in the SA,
870
[3] OPC Foundation, OLE for Process Control (OPC) Data Access Automation Interface Standard, Version 2.02, February 1999. [4] V. Kapsalis, A. Kalogeras, K. Charatsis, G. Papadopoulos, “Seamless Integration of Distributed Real Time Monitoring and Control Applications Utilising Emerging Technologies”, IEEE-IECON 2001, pp. 176-181, USA. [5] V. Kapsalis, K. Charatsis, A. Kalogeras, G. Papadopoulos, “Web Gateway: A Platform for Industry Services over Internet”, 2002 IEEE International Symposium on Industrial Electronics IEEE-ISIE'2002, pp. 73-77, Italy, July 2002. [6] Alfred C. Weaver, “Internet-based Factory Monitoring”, IEEE-IECON 2001, pp. 1784-1788, USA. [7] OPC Foundation, OPC XMLDA 1.00 Specification version 0.18 draft, March 2002. [8] Aaron Skonnard, “Understanding SOAP” March 2003, MSDN Library, http://www.microsoft.com/indonesia/msdn/understandsoap.a sp [9] K. Haus, “OPC XML-DA Introduction”, February 2003, Technosoftware Inc., www.technosoftware.com [10] OPC Foundation, Historical Data Access Automation Interface Standard, Version 1.0, January 2001. [11] Echelon Corporation, LNS for Windows Programmer's Guide, www.echelon.com [12] Fei Sophie Gao, “The Comparison of CORBA and SOAP”, http://taz.itsc.uah.edu/CIT/Spring2002%5Cpresentations%5 CComparisonofCORBAandSOAP.pdf [13] Vilhjalmur Thorsteinsson, “Delivering Value to Personal Networks”, April 2002, Homeportal Inc., www.homeportal.com [14] V. Kapsalis, S. Koubias, G. Papadopoulos “OPC-SMS: A Wireless Gateway to OPC-based Data Sources”, Computer Standards & Interfaces, Elsevier Science B.V, Vol. 24, Issue 5, pp. 437-451, November 2002.
which will instantiate the proper SOAP clients that will act on behalf of the requesting service provider, in order to access the remote automation networks or off-line stored data. In the latter case, the request will be directed to files or links residing in the SA (e.g. periodical reports, which have been previously accessed by the SA) instead of accessing directly the remote network(s). V. CONCLUSION With the explosive growth of the Internet, businesses of all sizes aim on applying network-wide solutions to their IT infrastructures, migrating their legacy systems and applications into web-based environments, and thus transforming them into on-line Web Services. Under this evolution, totally XML-based information exchange between applications by extended use of Internet standards, such as SOAP, WSDL and HTTP, would provide a framework for universal connectivity and interoperability. Our proposal for an open-architecture platform, based entirely on SOAP/XML standards, that will integrate and extend legacy industrial applications, either OPC-based or proprietary ones, into the enterprise level, is a future-proof solution with high scalability and extensibility. REFERENCES [1] F. Curbera, W. Nagy, S. Weerawarana, “Web Services: Why and How”, OOPSLA 2001 Workshop onObject-Oriented Web Services, October 2001. [2] A. Gulhati, P. Murray, “The Evolving Ecosystem of Web Services, Application Integration, and E-Commerce Frameworks”, www.capescience.com/articles/content/eaiwebservices.pdf
871
