Distributed Automation System based on Java and Web Services

of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Poems

Published:

Views: 32 | Pages: 6

Extension: PDF | Download: 0

Share
Description
Distributed Automation System based on Java and Web Services
Transcript
  International Conference on Computer Systems and Technologies -  CompSysTech’06 Distributed Automation System based on Java and Web Services Nikolay Kakanakov, Mitko Shopov, Grisha Spasov  Abstract: The paper presents the implementation of a model for Distributed Automation Systems which is experimentally built in the laboratory for Distributed Systems and Computer Networks (http://net-lab.tu-plovdiv.bg/). It discusses the N-tier model and its integration to the filed of distributed automation. The implementation of service-oriented middleware for interaction between tiers in the model is proposed. The system is based on enterprise web portal technology for the realization of presentation tier and web services for interconnection between middle tiers. The implementation is flexible and scalable, by means of using open and popular technologies for enterprise application development and integration. The main aspect of presented system is spreading the work of applications for distributed automation over large distances. In the paper the distribution of automation services – lookup and registration (dynamic UDDI) and program-to-program interaction (SOAP) are discussed. The implemented system can be applied to Distributed  Automation Systems and makes the integration of automation and business logic of an enterprise feasible.  Key words: Distributed Automation, N-tier Models, SOA, Web Services. INTRODUCTION Design and development of Distributed Automation Systems (DAS) goes in a new direction over the past few years – towards standardization, openness and integration with other business entities. High-level programming languages, component-based platforms, Internet technology, and standardized communication interfaces, all influence the development of today’s DAS [4, 5]. Following this trend of progress, adaptation of enterprise application architecture to the field of automation is now feasible. Many organizations work on developing middleware technologies for Distributed Automation. An interesting solution using the latest technologies is the Web Services Architecture (WSA) – so called “middleware for middleware”. It is believed that WSA has the potential to spread automation systems over Wide Area Networks [4, 7, 9, 10]. The presented paper discusses a model for integration of enterprise technology and distributed automation. The implementation of service-oriented middleware for interaction between tiers in N-tier architecture for DAS is proposed in the paper [8]. Multi-tier approach Multi-tier architectures provide many benefits over the traditional client/server architectures [3, 10, 11]: •   Installing and deploying the user interface is virtually instantaneous - only the Web interface in the middle tier needs to be updated. •   Without a "thick" client interface, it is easier to deploy, maintain, and modify applications - no matter where the client is located. •   Because the application itself is server-based, users always access the most up-to-date version. These benefits explain the growing popularity of the multi-tier architecture, and why almost every client/server application provider has retooled or is retooling to support Web-based clients [3, 10, 11]. The integration between tiers is by means of a middleware technology. All middleware technologies have the same problems and aims – high performance, flexibility, interoperability, scalability and application-to-application interaction. The most promising middleware nowadays is WSA. Its popularity derives from its basic features [3, 10]: •   Ubiquitous infrastructure – they operate over standard TCP/IP networks and use ubiquitous HTTP/SMTP for transport. - IIIA.24-1 -  International Conference on Computer Systems and Technologies -  CompSysTech’06 •   Proven approaches – they use both message-oriented and RPC-based interaction which makes them flexible. •   XML – they do not need specific IDL for describing the interfaces and the data entities are self-describing. •   Business standards – Business-to-Business interaction is by means of standard documents and processes. The most important strength of WSA is that it accommodates diversity and heterogeneity, not only in platforms, but also in middleware systems. Enterprise portal technology Spreading of enterprise resources over large distances, together with complexity and expensiveness of modern software, has motivated many companies to invest in enterprise portals as a mechanism by which they can manage information in a cohesive and structured fashion. Among the benefits of using enterprise portals are: they provide a single point of entry for different type of clients; portals can access Web services transparently from any device in virtually any location; they provide the ability to integrate disparate systems and leverage the functionality provided by those systems. Portals have so many advantages, that they have become a standard for Web application delivery [14]. APPLICATION OF N-TIER MODEL FOR DEVELOPING DISTRIBUTED AUTOMATION SYSTEMS USING JAVA AND WEB SERVICES The implemented system is based on N-tier model for distributed automation [8]. This model generally consists of four tiers which are separated in their functionality and administration (figure 1). Figure 1: N-tier model for distributed automation. The functions of the tiers are as follows: •   Client tier   – It works on the top of the model. The clients request services from the system using regular Internet browser or via web services. Different responses can be constructed depending on the client’s platform (PC, PDA, cellphone). •   Presentation tier  – It is responsible for handling the requests and forming the responses .  The requests are analyzed and dispatched to the appropriate service on the next tier. The server working on this tier is called the enterprise Web Portal and is based on the portal technology.   •   Services tier   – On this tier the main functionality of the model is placed .  The different services work on different servers, so failure of a single server affects only the corresponding service. This modular approach increases the flexibility and reliability of the system.   •   Data tier  – the role of the data tier is to produce and/or store data. It depends on the corresponding upper tier server. In case of data logging service it can be a Database. In case of automation services – a controller network.   The format of the messages exchanged between individual tiers is chosen for best performance, universality, and scalability. Clients interact with the Portal via HTTP – a - IIIA.24-2 -  International Conference on Computer Systems and Technologies -  CompSysTech’06 HTML documents or a SOAP message. The service tier and the data tier are interconnected via standard (JDBC, ODBC) or custom protocols (CNDEP - Controller Network Data Extracting Protocol [12]). The Presentation and the Service tiers communicate using web services, as it is described in the following section. Service Oriented Middleware for DAS The interconnection between the Presentation and the Service tier is the backbone of the system – its middleware. The middleware technology chosen is based on web services because of their ability for application-to-application interaction. The portal first locates the web services provided by the service tier and then uses them in proper order and combination to achieve the result issued by the client. Every server from the Service tier provides one or more web services according to its functions and publishes them in central directory. The type and number of the provided services for every server depends on its role. It can provide common services like: logging, accounting, grouping and/or structuring the results of other services; or real automation services like fetching data from sensors or sending commands to actuators, working on the Data tier. In this case provided services are based on functions of controllers in corresponding controller network.  A similar Remote Service Architecture is proposed by N. Jazdi in [5]. The main idea of the paper is to present the functions of embedded devices as services on a gateway server. Localization Services  As documented in [6], there are two general ways for localization of remote services. The first one is to build up a central directory, in which any relevant information is stored. The information can be directly requested from the directory by a client. The other possibility is to carry out a Peer-to-Peer (P2P) search, that is to say, you prepare a current image of resources by a live search. Usually, P2P networks do not have any fixed topology and as a result are self-organized. The basic idea behind them is that every peer knows its neighbor and consequently the neighbor's neighbor and so on. Therefore, a failure of one peer would not cause a failure of the whole network [6]. In the central directory approach, a separate server is used to store information about available services. Clients can retrieve information from the server at any time. Therefore, the service provider has to register its information to the server, before it can be used by the clients. Popular implementations of central directory are Jini, Universal Plug and Play (UPnP), and Universal Description, Discovery, and Implementation (UDDI) [1, 6]. In the current paper, a central directory approach – UDDI, is chosen, as long as it is a part of the WSA specification. It defines how to interact with a registry and the format of the entries in it. Interactions with the registry are of two types: registration and lookup. There are two types of UDDI registries: public and private. Public ones are accessible to everyone and play the role of open search engines for Web services. Private ones are those that enterprises create for their private use. For obvious reasons, industrial strength Web service implementations are to be based on private repositories. The use of dynamic binding between client application and service factory is a double edge sword. If the dynamic binding is used simply to determine the location of a well defined service, it is indeed a useful feature. Any other form of dynamic binding will make it almost impossible to develop real applications [1]. Sample Implementation In this section a sample implementation is presented. The architecture of the system is shown on figure 2. It consists of a UDDI register, transaction servers (TS) and a web portal, repositioned on separate machines. The transaction servers are deployed on  Apache Tomcat 5.5.14 and for the UDDI register a Microsoft UDDI Services is used. There - IIIA.24-3 -  International Conference on Computer Systems and Technologies -  CompSysTech’06 are two measurement services and a calculation service deployed (see figure 4). All of the services are accessed from the web portal. The calculation service also access measurement services to collect data and perform a function over them ( average  in current implementation). A well defined web services are used and the UDDI register is used only to determine their location. Data producer components for the measurement services are controller networks (figure 2). Figure 2: The architecture of implemented system. The web portal provides a single point of entry for clients. It is built up from the following components (figure 2): presentation component – a Java Server Page (JSP) and a binding component – a Java Bean, used to transparently locate and call the right web service. A fragment from the JSP page that figures out the integration of these two components is shown on figure 3. Figure 3: Ivocation of services in JSP. <JSP: useBean  id=" ts " class="WSClients.TsClient" /> Average Temperature: <JSP: getProperty  name="ts" property=" temperature " /> Average Humidity: <JSP: getProperty  name="ts" property=" humidity " /> Location: <JSP:getProperty name="ts" property="locations"/>  A fragment from a WSDL file describing the interface of a temperature measurement service is shown on figure 4. The format of request and response messages can be seen. Figure 4: Service interface description from WSDL. <!--WSDL created by Apache Axis version: 1.3 --> <wsdl:message name="getTemperatureRequest"> <wsdl:part name="in0" type="soapenc:string"/> </wsdl:message> <wsdl:message name="getTemperatureResponse"> <wsdl:part name="getTemperatureReturn" type="soapenc:float"/> </wsdl:message> The data entities trasfered between the portal and transaction server and the service functions are enveloped in SOAP. The SOAP transport chosen is HTTP. This allows distribution over networks separated by firewalls. The encapsulation of SOAP message in HTTP body is exposed on figure 5a (Request) and figure 5b (Response). The Request consists of addressing the getTemperature  web service and calling its function  “Average” . This function contacts all registered measurment services for a particular location and returns the arithmetic mean of their responses (assuming the responses are float numbers representing temperature). The value data in the Response is not XML encoded because it is of a simple data type – float. - IIIA.24-4 -  International Conference on Computer Systems and Technologies -  CompSysTech’06 Figure 5a: SOAP request enveloped in HTTP POST. Figure 5b: SOAP reply enveloped in HTTP. CONCLUSIONS AND FUTURE WORK The implemented system is based on multi-tier architecture which makes it very flexible and scalable. The tiers are functionally separated for increasing security and reliability. Administration or maintenance of a server on a particular tier did not affect the other tiers. Component approach in designing allows interoperability and reusability. The proposed interconnection middleware between Presentation and Service tiers is service-oriented. This allows the system to spread over wide area networks (by means of VPNs). In that way the service tier is distributed over large distances, which is applicable for corporate automation businesses. Popular and standard technologies are used for implementation of every tier: on the Client tier is Web browser; on the Presentation tier is the portal technology; on the Service tier – web services. Only on the Data tier, where the real automation takes place, there are custom protocols for communication with controllers. The paper presents the implementation of a model for Distributed Automation Systems which is experimentally built in the laboratory for Distributed Systems and Computer Networks [13]. The future work includes the experimental analysis of the system, evaluation of request/response times, estimation of the effectiveness in a function of the server or network load. The other direction for evolution of the model is applying web services architecture to the Data tier – directly to the embedded devices. [2, 4]. - IIIA.24-5 -
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x