DIP. WP 10: Case study ebanking. D 10.6 Specification of application 2

Transcription

1 DIP Data, Information and Process Integration with Semantic Web Services FP Deliverable WP 10: Case study ebanking D 10.6 Specification of application 2 Silvestre Losada Alonso Dariusz Kleczek Jose Luis Bas Sergio Bellido Jesús Contreras Jose Manuel Gomez Richard Benjamins Monica Martinez Montes September 16 th, 2005 Deliverable 10.6 MS 20/01/2006

2 ii

3 EXECUTIVE SUMMARY This deliverable describes the requirements of Stock Market prototype that takes advantage of the Semantic Web Services (SWS) technology provided by the DIP Consortium. The Stock Market prototype will be developed in Bankinter with the support of isoco to demonstrate the advantages and benefits of implementing this application using SWS. In the chosen scenario the advantages of a SWS based solution are clearly in the area of service composition and system integration. Bankinter offers services to consult different kinds of Stock Market information (news, charts, index variations, stock prices), services to sell and buy stocks, services to send alerts and others. These services allow operating on the continuous stock market using a complete service delivery platform based on WS technology. This prototype intends to take advantage DIP technology (automatic service discovery, service composition and service mediation) to construct more complex operations working on different formats and driven by the final user requests. It will use a natural language interface to define the user goal and to construct and invoke the services. In order to build an SWS based solution of the use case scenario several SW Services need to be developed. The requirements provided in this document enumerate and describe these SW Services. As the Stock Market prototype will be use Semantic Web Services, this deliverable contributes to one of DIP s main goals, applying Semantic Web Services as an infrastructure in real world scenarios within an organization and between organizations and its customers, providing a use case for the use of WSMO in the description of the SWS involved in an application, and for the use of the SWS architecture defined in the context of this project. The core component for this prototype is the open source architecture WSMX. The prototype provides a proof of concept of the WSMX in the area of ebanking. Finally an exploitable tool will be developed. Audience is targeted by this deliverable. It may also be useful for other use-case partners (WP8, WP9) to read this document, in order to compare their scenarios and prototype architectures. This could be of great benefit for all the use-case partners in to make cross fertilization. For Technical WP partners also provides relevant information about how this case study will use the functionalities provided by the DIP infrastructure, namely discovery, mediation and execution and will provide requirements Finally, External readers who are interested in finding information about a use case for SWS. Disclaimer: The DIP Consortium is proprietary. There is no warranty for the accuracy or completeness of the information, text, graphics, links or other items contained within this 3

4 material. This document represents the common view of the consortium and does not necessarily reflect the view of the individual partners. 4

5 IST Project Number Full title Project URL FP Acronym DIP Data, Information, and Process Integration with Semantic Web Services Document URL EU Project officer Kai Tullius Deliverable Number 10.6 Title Specification of application 2 Work package Number 10 Title Case study ebanking Date of delivery Contractual M 21 Actual 27-Sep-05 Status version. 0.xx final Nature Dissemination Level Prototype Report Dissemination Ontology Public Consortium Authors (Partner) Responsible Author Silvestre Losada (isoco), Dariusz Kleczek (isoco), Jose Luis Bas, (Bankinter), Sergio Bellido (Bankinter), Jesús Contreras (isoco) Silvestre Losada slosada@isoco.com Partner isoco Phone Abstract (for dissemination) This deliverable describes the requirements of Stock Market prototype that takes advantage of the Semantic Web Services (SWS) technology provided by the DIP Consortium that will be created in the forthcoming months The main objective of this prototype is create a system that allows realize complex operations based on more simple operations that exist actually Keywords Prototype, Ontology, Financial, Stock Market; SWS, SW, e-banking Version Log Issue Date Rev No. 001 Initial version Author Silvestre Losada Change Initial version of document 5

6 Jose Luis Bas Sergio Bellido Jesús Contreras, Silvestre Losada Silvestre Losada Jose Luis Bas / Sergio Bellido Richard Benjamins Dariusz Kleczek Added introduction and problem description Added section 3.1,2.1.1 Section 4.1 Section 5 Sections 3.2, Corrections Corrections Update of the deliverable, added specification of Natural Language Component 6

7 Project Consortium Information Partner Acronym Contact National University of Ireland Galway Fundacion De La Innovacion.Bankinter Berlecon Research GmbH British Telecommunications Plc. Swiss Federal Institute of Technology, Lausanne Essex County Council Forschungszentrum Informatik NUIG Bankinter Berlecon BT EPFL Essex FZI Prof. Dr. Christoph Bussler Digital Enterprise Research Institute (DERI) National University of Ireland, Galway Galway Ireland Tel: Monica Martinez Montes Fundacion de la Innovation. BankInter Paseo Castellana, Madrid, Spain Tel: Dr. Thorsten Wichmann Berlecon Research GmbH Oranienburger Str Berlin, Germany Tel: Dr John Davies BT Exact (Orion Floor 5 pp12) Adastral Park Martlesham Ipswich IP5 3RE, United Kingdom john.nj.davies@bt.com Tel: Prof. Karl Aberer Distributed Information Systems Laboratory École Polytechnique Féderale de Lausanne Bât. PSE-A 1015 Lausanne, Switzerland Karl.Aberer@epfl.ch Tel: Mary Rowlatt, Essex County Council PO Box 11, County Hall, Duke Street Chelmsford, Essex, CM1 1LX United Kingdom. maryr@essexcc.gov.uk Tel: +44 (0) Andreas Abecker Forschungszentrum Informatik Haid-und-Neu Strasse Karlsruhe Germany 7

8 Tel: Partner Acronym Contact Institut für Informatik, Leopold-Franzens Universität Innsbruck ILOG SA UIBK ILOG Prof. Dieter Fensel Institute of computer science University of Innsbruck Technikerstr. 25 A-6020 Innsbruck, Austria dieter.fensel@deri.org Tel: Christian de Sainte Marie 9 Rue de Verdun, Gentilly, France csma@ilog.fr Tel: inubit AG Intelligent Software Components, S.A. NIWA WEB Solutions Inubit isoco NIWA OU Torsten Schmale inubit AG Lützowstraße D Berlin Germany ts@inubit.com Tel: Dr. V. Richard Benjamins, Director R&D Intelligent Software Components, S.A. Pedro de Valdivia Madrid, Spain rbenjamins@isoco.com Tel Alexander Wahler NIWA WEB Solutions Niederacher & Wahler OEG Kirchengasse 13/1a A-1070 Wien wahler@niwa.at Tel:+43(0) The Open University Dr. John Domingue Knowledge Media Institute The Open University, Walton Hall Milton Keynes, MK7 6AA 8

9 United Kingdom Tel.: SAP AG Sirma AI Ltd. Unicorn Solution Ltd. Vrije Universiteit Brussel SAP Sirma Unicorn VUB Dr. Elmar Dorner SAP Research, CEC Karlsruhe SAP AG Vincenz-Priessnitz-Str Karlsruhe, Germany elmar.dorner@sap.com Tel: Atanas Kiryakov, Ontotext Lab, - Sirma AI EAD Office Express IT Centre, 3rd Floor 135 Tzarigradsko Chausse Sofia 1784, Bulgaria atanas.kiryakov@sirma.bg Tel.: Jeff Eisenberg Unicorn Solutions Ltd, Malcha Technology Park 1 Jerusalem Israel Jeff.Eisenberg@unicorn.com Tel.: Pieter De Leenheer Starlab- VUB Vrije Universiteit Brussel Pleinlaan 2, G Brussel,Belgium Pieter.De.Leenheer@vub.ac.be Tel.: +32 (0)

10 LIST OF ABBREVIATIONS API CRM IBEX Application Programin Interface Customer Relationship Management Madrid Stock Exchange Main Index IBEX 35 Madrid Stock Exchange Index composed of the 35 stocks with more volume negotiated NLRS SMS SOA SWS UDDI UMTS WS WSDL WSML Natural Language Recognition System Short Message Service Service Oriented Architecture Semantic Web Services Universal Discovery, Description and Integration Universal Mobile Telecommunications System Web Services Web Service Description Language Web Service Modeling Language WSMO Web Service Modeling Ontology WSMX Web Service Modeling Ontology XML extensible Markup Language 10

11 Specification of application 2 TABLE OF CONTENTS EXECUTIVE SUMMARY... 3 LIST OF ABBREVIATIONS TABLE OF CONTENTS... I 1 INTRODUCTION Problem definition Project constraints DESCRIPTION OF CURRENT IMPLEMENTATION/USAGE Current operations Data Sources Operations for application SWS Framework VS WS Framework REQUIREMENTS Introduction/Objectives Functional requirements Non functional requirements Performance Accuracy Scalability Distributed System, SOA architecture ARCHITECTURE AND IMPLEMENTATION System architecture Story Board Natural Language Recognition DIP Components for implementation QoS-enabled Discovery Non DIP components for implementation CONCLUSION REFERENCES ANNEX LIST OF FIGURES Deliverable 10.6 i 20/01/2006

12 Specification of application 2 Figure 1 Bankinter broker... 5 Figure 2Web Service architecture... 8 Figure 3: Sequence diagram: The stock value is in the top five variations and next system execute some action Figure 4: Sequence diagram: When volume rise execute buy or sell operation Figure 5: Sequence diagram: When stock volume rise and belongs to certain set, buy. 13 Figure 6: Sequence diagram If recommendation of some entity is buy or sell then execute Figure 7: Sequence diagram Send alert when restrictions are fulfilled Figure 8 Sequence diagram: Alert if the opinion of Goldman about some values change Figure 9 Sequence diagram Perform operation if stock gain some limit Figure 10 System architecture with DIP components required to develop second application Figure 11 Sequence Diagram for the Interaction with the Prototype Figure 12 Natural Language Component Architecture LIST OF TABLES Table 1: bestcotizaciones Input parameter Table 2: bestcotizaciones output parameter Table 3: mainindexes output parameter Table 4 cotizacionindice input parameter Table 5: cotizacionindice output parameter Table 6: relevantvariations input parameter Table 7: relevantvariations outputparameter Table 8: searchvalue input parameter Table 9: searchvalue output parameter Table 10: getnews input parameter Table 11: getnews output parameter Table 12: news Detail input parameter Table 13: news Detail output parameter Table 14: performbuysell input Parameter Table 15: performbuysell output Parameter Table 16: getmyporfolio input parameter Table 17: getmyporfolio output parameter Deliverable 10.6 ii 20/01/2006

13 Specification of application 2 Table 18: getportfolios input parameter Table 19: getportfolios output parameter Table 20: sendalert input parameter Table 21: sendalert input parameter Table 22: docurrencytransformation input parameter Table 23: docurrencytransformation output parameter Deliverable 10.6 iii 20/01/2006

14 1 INTRODUCTION This deliverable provides the requirements specification of the second application for ebanking use case. The prototype focuses on the stock market application that will offer the following use cases: Consult stock market values Invoke operations on the stock market that might involve compositions of existing primitive services. The objective of the deliverable is to provide the outline architecture and design for the stock market prototype that will be delivered at M30 (June 2006). The prototype will make use of components that have been developed within DIP and the WSMO/WSMX working groups with the intention of demonstrating the benefits of semantic-based discovery and composition. The prototype will be based on the DIP Architecture as described in D6.5. Much of the prototype will use the components produced by the tool work packages, DIP Work Packages 1, 2, 3, 4 and 5. As such, this deliverable does not need to reproduce the work from these work packages. In turn these work packages use the results from the WSMX project. The prototype makes use of components developed in the DIP technology workpackages (1-5) and the associated WSMO working groups As described in [3] one of the main concerns/opportunities that SWS represents in the Financial Market is the opportunity for third party developers to easily aggregate data offered by banks. This ability could transform the way the electronic communications between the Bank and its clients is performed, especially when referred to CRM issues and specifically for sell new products to actual clients. As an example, if Google were capable of aggregate public and private information from different SW or SWS sources, clients will prefer (for their own convenience) to join this hypothetical Google service rather than consult each bank at a time. This will include the cross selling activities with actual clients, which is the main focus of the CRM systems In [3] it was described in more depth the concerns/opportunities that SWS brings to the products that represent a huge part of the Financial Institutions markets: mortgage loans and credit. WS alone are not a significant opportunity/concern in the market. Only the huge clients with enough computer abilities (big and medium sized corporations) are capable of aggregating information from different sources, due to the time and effort required to discover, develop and adapt their systems to the available WS. This kind of companies (for example, real state corporations) have actually access to that aggregated information in order to offer a quality service for their clients, so WS alone are not expected to be relevant to substitute the actual available services.. 1

15 But SWS s, and, specifically the discovery and mediation modules, will allow the automatic search of information and, therefore, accessible for individuals and small enterprises if a simple interface is provided. As described in [3], in this environment, the competitive advantage of a Financial Institution against their competitors is mainly a time to market and efficiency task. Building and offering a new service gives to its developer the possibility to attack web traffic and create cross-selling opportunities Also mentioned in [3] in [4], and in the above paragraph, Financial Institutions are looking for efficiency in their own processes. Since prices (interests and commissions) are not a differentiation factor in the European markets, the only way to be more profitable is to reduce the costs and improve the service quality In this context, efficiency must be defined with a double focus Efficiency as lower costs Efficiency as better convenience for the clients Both factors together are critical and are good in-advance-measures of the success of a projected service. The lower costs requirement implies that banks can produce product sales or services at a lower price. The better convenience for clients implies that more clients are able to understand and fulfil the required profile. One of the biggest advantages of SWS is its ability to perform automatic services discovery and its capacity to automatically aggregate and compose information from different sources with a minimal amount (or without any) human interaction. These SWS-related factors, the natural language interface (using SWS or WS capabilities) and the use of several SWS (i.e.: for statistic processes) fulfil both efficiency requirements. 1.1 Problem definition From a dissemination point of view, SWS are, in the actual state of the art, oriented to the professional and scientific communities. It is required to have an amount of specialised knowledge to make use of a WS and more than the previous, due to its more complex structure, if a SWS is intended to be developed or used. Only a few people are able to develop SWS or make use of SWS applications. So, SWS are not yet available to the general public. WS (without semantics) are not efficient for many applications since new available services have to be discover by humans, changes in actual WS s must be reprogrammed by experts and semantic tasks (translations of the terms involved in different WS s) are also required. 2

16 For a Financial Institution, and for many other industrial sectors that are oriented to a huge number of small operations, it is not suitable to offer a service (for example an access to a WS or SWS) that is going to be used by a low percentage of their clients, except if the price is too high to cover the costs. So what we intend is to develop an application that is both efficient and usable for the average client of a Financial Institution Also, we want to demonstrate how SWS s could be a useful technology for the general public, (not only for experts), although it must be transparent for all of them. Also, we believe that the deployment of the application will help to disseminate the SWS technology in our sector, due to the leader follower structure of the financial market described in [3]. To achieve these goals, the system will have a natural language interface, text-based. A brief explanation of the process is provided in the following lines, although a more technical description is developed in the next chapters. A client describes in a textbox its own necessity, by typing it in natural language. A natural language recognition system (NRLS) filters the text and extracts the more relevant concepts involved in the text using an appropriate ontology, This module will be realized using an appropriate SWS available Once the client question is understood the system builds a WSMO GOAL 1. Again, to realize this task, an appropriate SWS is discovered and executed.. If the client asks for it, the goal will be executed by discovering the appropriate/s discovered SWS for that task, making use of them and waiting for a result. If the client wants to make use of the goal for further applications. The client receives the result if his inquiry in natural language format. Again, appropriate SWS will be used to build it

17 1.2 Project constraints Several constraints are addressed to achieve the described process 1) Building a consensuated Financial Ontology might look easy but there are several constraints in working that way: 1. There are hundreds of financial products and services and thousands of subproducts and subservices. Not all banks have all the services and products, and not all banks use the same internal process to solve the same problem. 2. There are several financial standards (i.e.:ifx) but are oriented to clients using financial services. Thus, they are not able to manage some of the internal processes a bank must perform to produce a result (i.e. : a transfer) 3. There is not a standard ontology, in the sense that is broadly used by banks. Usually, banks tend to accept as a standard those systems or processes that are sufficiently proved and with some success background. 4. Most of the banking transactions will not be available in WS/SWS format in the short term, including if the security concerns were solved. It is not an easy task to involve banks in a collaborative environment until business is clearly stated. 2) Natural Language Recognition Systems (NLRS) work fine in limited environments but they are not always able to detect with a reasonable degree of precision what the client is asking for. This is especially true for weakly defined domains. The SWS description and the underlying ontology need to provide some additional information for the NLRS in order to achieve an acceptable level of user satisfaction. 2 DESCRIPTION OF CURRENT IMPLEMENTATION/USAGE At the present time there are four ways to gather information of the Spanish Stock Market using a Bank: 1) Branches. Too expensive for Banks. Only for high end clients. 2) Phone Banking Service. Expensive for banks. Only for selected clients 3) Internet. Cheap for banks. Several levels of services (free or not) are available for clients and non-clients 4) Mobile Services (SMS, mobile phone applications). Cheap for banks, usually free or at a small fee per consult. Usually all the channels have the same internal flow with different interfaces. Anyway, the building of new transactions could be very expensive. At the present time a low level development will be required in most of the banking systems. To explain the latest let us consider this example of a client input: 4

18 Buy shares of company X when the expert s consensus is BUY or NEUTRAL In this example, all the information is available in the Web (let us suppose that is also public) To give the client a result, the NRLS must define the correct ontology terms, describe the goal in WSMO, discover as many expert WS s as possible, execute the goal, gather the information, check it and, if all that is fine with the user requirements, execute the BUY order Developing this specific solution using the current architecture will be inefficient, and will require a huge effort in coding maintenance and it will almost never be able to gather all the expert WS s providing their recommendation available in the Web. 2.1 Current operations In this section we present a list of all the on line transactions available in the Bankinter Web Site. Most of them are also available in a large number of financial sites as checked Figure 1 Bankinter broker. Portfolio composition * Retrieves the costumer's portfolio, including the number shares, name, their last price, last update time, tendency Best selling price/best buying price of a share* Sells/buys a number of shares at the best possible price offered by the stock market at that moment Price/volume of a share* Shows the last price and the trading volume of a given share Share Historic Graphic* Shows the price historic evolution of a given share Buy * Buys a number of shares at a given price 5

19 Sell * Sells a number of shares at a given price Alert * Sets an SMS alert which is triggered based on a price variation event Buy/sell history * Retrieves the historic buying and selling activity of a particular costumer Share in portfolio details * Retrieves detailed information of a given share such the last price, variation, previous day price, session maximum and minimum, trading volume, opening price... Share news Given a share retrieves the headlines news from different stock market analysts Main Indexes Retrieves the values, their variation and last update time of the main worldwide indexes Best shares of an index Given an index shows the main shares, their values and variations Index History graphic Shows the price historic evolution of a given index Index alerts * Sets an SMS alert which is triggered based on a price variation event Search for a share in all markets Searches share's details in the most important worldwide stock markets Search for a share in an specific market Searches share's details in a given market Non executed orders * Retrieves all the costumer's non executed buy/sell orders Daily orders Retrieves all the costumer's orders of the present day Order details * Shows the details of an order such as the order price, order volume, order date and its status Order edit Edits an order so the price and volume can be changed Cancel order 6

20 Cancels an existing order Alert consult * Retrieves all the SMS alerts set by the user Alert details * Retrieves the details of a SMS alert such the mobile number and the price triggering events Alert edit * Edits a SMS alert so the mobile number and the price triggering events can be changed Alert cancel Cancels a SMS alert 2.2 Data Sources Stock market information and volume are given by each country stock market to financial entities as to any other person or company who may need it. Normally (although this may vary from country to country) there are two different levels of information: 1. Real time data: Normally a fee is needed to get this information 2. Delayed data: Normally this data is provided free of charge. In Spain, for example, the delay in time is about 20 minutes In the first case (real time data), the fee to be paid implies to identify totally the customer that will use the data, which, in DIP terms means that security measures are needed. These measures are not in the scope of the present document 2.3 Operations for application 2 These operations are currently used as Web Services invoked by the Bankinter Mobile Brokerage application. This application is a pioneer java MIDP 2.0 mobile application able to consult a costumer s portfolio, get detailed information from a given company s share including graphics for several periods, retrieve information from more than 25 different stock markets, including main indexes such NASDAQ, XETRA, EUROSTOCKXX, DOW JONES, IBEX35 Moreover, a customer will be able to buy/sell shares in real time, consult the orders introduced in the market, and modify or cancel them. Since it has been launched into the Spanish market in November 2004 almost 1800 Bankinter costumers are trading using this mobile application with peaks of 60 million euro/month. These trading figures represent almost the 2% of the whole transactions performed at the Madrid Stock Market Next paragraphs show a list of atomic operations that currently is working on Bankinter and will be used in application 2. Annex 1 provides a complete list of these operations. 7

21 2.4 SWS Framework VS WS Framework A Web Service is an application that exists in a distributed environment, such as the Internet. A service is made available as reusable functionality through web standards like SOAP, WSDL, UDDI registries. This functionality can be used directly from a client application, aggregated with other services and information, mediated, or converted for presentation WS technology is composed by several components: a WS interface describes the Service. The description is registered in a service registry (UDDI), where the user can look for it. Once he has found the desired service, he can retrieve it from the server where it is published (using an XML-based protocol: SOAP). Figure 2 shows the process to publish, find, and consume a WS over the web: Service registry (UDDI) Publishes Web Service Service Provider (Web server) Finds web service Points to Web Service Points to WS description Stored in Service Requester Communication (SOAP protocol) Web Service Describes WS Web Service Interface Definition (WSDL) Figure 2Web Service architecture Working with WS the user has to find out the service capabilities just by looking to the WS interface definition (WSDL). This definition is not powerful enough, as it defines the service capabilities in terms of its inputs and outputs. It is not sufficient to be automatically managed by machines. Human interaction is crucial to find and invoke these kinds of services. Semantic Web Services are a new type of application. They are self-contained, selfdescribing, semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven automatic way [19] Semantic Web Services are a new type of application. They are self-contained, selfdescribing, semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven automatic way [Arroyo et al. 2004] They are the result of applying WS over the characteristics of the Semantic Web; they form the dynamic view of the Semantic Web. They are semantically self-described automated applications. They make use of explicit machine-understandable semantics, 8

22 which allow them to be automatically invoked by software agents without any intervention of human beings. One of the objectives associated with Semantic Web Services is (semi-) automatic composition, of Web Services; in this case SWS will provide this feature to develop our stock market. 9

23 3 REQUIREMENTS 3.1 Introduction/Objectives The main objective of this prototype is to create a system that allows realizing complex operations based on more simple operations that exist previously. Operations can be implemented and performed using DIP technologies, since it offers tools for service composition and SWS execution. This section provides a list of requirements identified in the analysis done in collaboration of Bankinter and isoco These requirements are split up into the following categories: functional requirements, and non-functional requirements. 3.2 Functional requirements FR1 Web Based Interface. As we do not intend that users would need to install a large amount of software to run the prototype, the requirement claims for a web-based user interface. Stock market application will be used via web-based UI that can be viewed using a standard web browser without installing any additional software. Users will enter their input using natural language in a Web Page text box. FR2 Results in web Page Results will be displayed in a web page. FR3 Dialog Support In case of missing parameters or ambiguity in the user request, an interactive dialog system will complete the goal description. FR4 Spell checking. Integrated spell checking system will allow for wider understanding of user input. FR5 Interface language For any user interaction we will use Spanish language FR6 Request forwarding In case of low user satisfaction on system response, his/her request will be forwarded to an alternative system for further processing. FR7 Signature for selected operations 10

24 Some selected operation would need an electronic signature. FR9 Development of the NLRS A natural language recognition system will be developed in order to interpret Bankinter customer s request. FR10 Web Service Creation As this prototype builds SWS on top of ordinary WS, several WS have to be created to wrap the functionalities implemented in Bankinter in order to serve as an input for the SWS. Several WS are implemented and others will be implemented inside Bankinter. These functionalities are described in section 2 FR11 Composed operations using DIP components for composition In this section we introduce a minimal set of composed operations that the application needs to fulfil in June These operations are based on simple operations described above in section 2. If the stock value belongs to the top five variations, then the system execute some action. The sequence diagram shows the composition. Figure 3: Sequence diagram: The stock value is in the top five variations and next system execute some action -If the volume of some value rises, execute BUY/SELL/ALERT 11

25 Figure 4: Sequence diagram: When volume rise execute buy or sell operation. If the stock value rises and the index belongs to certain set, execute the BUY action 12

26 Figure 5: Sequence diagram: When stock volume rise and belongs to certain set, buy. If the advice of several/all/some/specific brokers/banks is BUY/SELL then execute BUY/SELL 13

27 Figure 6: Sequence diagram If recommendation of some entity is buy or sell then execute. BUY/SELL/ALERT if some news about value X is Y, the values raises more than X%, etc. 14

28 Figure 7: Sequence diagram Send alert when restrictions are fulfilled Alert if Goldman Sachs rating has changed: A+ Figure 8 Sequence diagram: Alert if the opinion of Goldman about some values change SELL/BUY/ALERT in case the value reaches some limit, its volume is greater/lower than X, its deviation is Y 15

29 Figure 9 Sequence diagram Perform operation if stock gain some limit. 3.3 Non functional requirements This section lists the non-functional requirements of the prototype. They describe aspects of the system that are concerned with how well it provides the functional requirements. Next section lists the minimum non-functional requirements that have to be achieved in any application; although some of them might not be relevant for the use case, which is simply implementing a prototype Performance This application should not restrict the number of simultaneous users. The response time should be prompt and will depend on the users Internet connection. However SWS is still an immature technology, a very high performance level in the prototype cannot be assured, but once the basis of the prototype is stated and as the SWS technology matures rapidly these targets should be addressed Accuracy The use case system is meant to be a demonstration prototype. Prototype will operate with real world data to demonstrate to the target audience the full potential of SWS. If any security problems arise it will become necessary to use simulated services with anonymous dummy data, to show the advantages of SWS Scalability As said above, SWS is still an immature technology, a high scalability level in the prototype cannot be assured. For example we don t know the response of discovery component with thousands of services Distributed System, SOA architecture The prototype developed will be based on SOA architecture to achieve loose coupling. Even if this prototype is now being developed for Bankinter, it is easily extensible to other banks and/or financial entities. 16

30 4 ARCHITECTURE AND IMPLEMENTATION In this section we describe the main feature of the prototype. First we describe the overall architecture. 4.1 System architecture To meet the requirements described in the previous sections the following architecture was developed for the Stock market application. In order to identify the necessary components for the prototype it is first necessary to consider the goal and intended use of the prototype. Thus the high level functionality required is: 1. Semantic representation of services using WSMO. 2. Adaptation of natural language messages to WSML format, in order to create WSMO Goal using natural language request. 3. Automatic service discovery that match with a given goal. It is necessary to discover the best WS that fulfils the defined requirements, which are expressed by the user. The discovery component is concerned with finding Web Service descriptions that match the goal specified by the service requester. The discovery component returns a (possibly empty) list of Web Service descriptions. 4. Service composition: It is probable that no WS will completely fulfil the selected goals, and it will therefore be necessary to compose several WS that will achieve that goal. The prototype developed will offer Orchestration [9]. Functionality offered by WS will be obtained by composition of multiple WS, e.g.: in order to execute a BUY operation we need to check the account balance It is probable that no WS will completely fulfil the selected goals, and it will therefore be necessary to compose several WS that will achieve that goal partially 5. Invocation of services. We need invoke WS returned by the discovery component and fulfil a given Goal. The invocation component is responsible for invoking a Semantic a Semantic Web Service able to fulfil the goal. We need invoke SWS returned by the discovery component and fulfil Some components of DIP/WSMX offer these features, therefore the architecture of Stock Market application is based on DIP/WSMX architecture. Figure 10 shows the high level architecture for the prototype including the necessary DIP/WSMX Architecture components. This includes a set of design-time tools to create the semantic descriptions of the services, the WSMX core, communication manager to manage the interaction, discovery component to discover services, choreography and orchestration components to make composition and resources manager to manage storage and the adapter framework to convert to and from WSML to XML. 17

31 Service Requesters Textual interface Web interface Natural Language Component System Interface Administration Framework Interface WSMX Manager WSMX Manager Core Interface Interface Interface Interface Interface Communication Resource Process Choreography Parser Discovery Manager Manager Mediator Orchestration Invoker Receiver Grounding Adapters XML TO WSML WSML TO XML Service Provider Bankinter Web Service 1 Web Service 2... Web Service p Resource Manager Interface WSMO Objects Non WSMO Objects Reasoner Interface Reasoner DIP Components Figure 10 System architecture with DIP components required to develop second application 4.2 Story Board This story board shows how the system handles a request of customers. A user expresses in natural language the operation he/she wants to realize: What is the value for REPSOL stocks? This text is transformed into a formal WSMO goal using the NL component. The goal is sent to WSMX using a entry point realizegoal(goal, OntologyInstance, Preferences):Confirmation, internally WSMX performs next actions: 1. Discover a SWS that fulfils a given goal. To achieve this, WSMX sends a goal to Discovery component using Discovery component returns a set of services. 2. In the next step using a set of services is returned by the Discovery component. WSMX has to select one of them, the service that best fits the user s preferences. This action is performed using the Functional Selector. 3. Once a service is selected, this service must be executed. Finally, the sender component sends a message (invokes) the selected Web Service. 4. These SWS can be composed from atomic WS offered by Bankinter. Once the invocation is finished, WSMX returns the result to the stock market application who invokes the NL component to transform the result back into natural language format in order to be presented to the user. 18

32 Figure 11 Sequence Diagram for the Interaction with the Prototype 4.3 Natural Language Recognition The deployment of a natural language interface is very important in the area of Semantic Web Services supporting business to customer solutions. The long term goal is to free customers from restrictions posed by custom built applications. That means, that the customer is able to formulate whichever goal he wishes to achieve. If currently no web service combination is able to satisfy such a goal, it can be stored as an incentive for businesses to offer the desired functionality. The way to achieve this long term goal is to build interfaces restricted to a well defined domain in the short term, such as is the case of the Broker application. The natural language technology developed by isoco is based on ontologies, which are used to disambiguate a user s query. This makes the technology especially suited to be used within the context of the WSMO framework, which advices that all the resources be based on ontologies. The architecture of the natural language interface is shown in figure X. 19

33 Figure 12 Natural Language Component Architecture The user specifies his goal in natural language. The natural language sentence serves as input to two components. The Semantic Distance component takes as input the query, a domain ontology, which has been developed inside of the DIP WP 10, and descriptions of the generic goals stored in a repository. It then compares the query and the descriptions to choose the generic goal which corresponds to the user s wish. The Knowledge Tagger component annotates the user s query with terms from the domain ontology. This enables to recognize the parameters, which instantiate the generic goal. We acknowledge that it is not possible to require the user to specify all necessary parameters upfront. Therefore, a dialogue support component is used to ask for the missing parameters. The same component is used to ask for the final confirmation of the generated goal, to ensure the proper interpretation of user s wish. 20

34 4.4 DIP Components for implementation This section describes a set of DIP components of architecture that will be used in this prototype Reasoner / Discovery, this component will be provided for technical WP will be used to perform discovery. The WSMX 2 Discovery [12] component is concerned with finding Web Service descriptions that match the goal specified by the service requester. WSMO description of the goal a user wishes to achieve (described in terms of a desired capability with preconditions, assumptions, effects and post-conditions) is matched to the WSMO description of Web Services known to WSMX (described in terms of offered capabilities). The discovery component returns a (possibly empty) list of Web Service descriptions. Orchestration/ Choreography. This component will be provided from technical WP, is necessary to make service composition. A WSMX Choreography [10] defines how to interact with a Web Service in terms of exchange messages the so called communication patterns. A WSMX Orchestration [9] describes how the service makes use of other services in order to achieve its capability Invoker /Receiver. Provided from technical WP, Invoker [15] is used by the execution semantics of WSMX [16]. The invoker receives the WSMO description of the service and the data that the service expects to receive. It is responsible for making the actual invocation of an operation on a service. The WSMX Receiver interface expects the contents of all messages it receives to be expressed in WSML 3 [5]. Each WSML messages may represent a goal to be achieved or be a message corresponding to a choreography or orchestration instance that already exists Process Mediator Mediation Process (Adapter or data mediator: Technical WP provide this component. A WSMX Process Mediator [13] has the role of reconciling the public process heterogeneity that can appear during the invocation of Web Services. That is, ensuring that the public processes of the invoker and the invoked Web Service match. Since both the invoker and the Web Service publish their public processes as choreographies, and the public processes are executed by sending/receiving messages, the Process Mediation Component will deal with reconciliation of message exchange patterns based on choreography. Communication Manager. It is necessary to manage the interaction with the system The CommunicationManager is responsible for dealing with the protocols for sending and receiving messages to and from WSMX. Its external behaviour is accessed through the Invoker and Receiver interfaces. The Communication Manager accepts the message and handles any transport and security protocols used by the message sender

35 The execution semantics of WSMX determine how the WSML [5] message should be handled based on the defined execution semantics of the system [7]. Resource Manager. This component is necessary to manage the persistent storage WSMO objects it will be provided by technical WP. The Resource Manager is the interface for WSMX persistent storage. The component implementing this interface is responsible for storing every data. WSMO4J 4 provides a set of Java interfaces that can be used to represent the domain model defined by WSMO. 4.5 QoS-enabled Discovery As soon as the QoS enabled Discovery is integrated into WSMX, the Stock Market Application will be able to support QoS as a criterion for the discovery and selection of Web Services. Bankinter publishes the advertisements of its services into a WSMO registry. These advertisements include the information of different QoS parameter and the corresponding conditions for achieving that quality level. The example QoS parameters are: The assured availability time of the service, e.g., service is assured to be available 100% during the opening hours of the stock-market. The meantime between failures of this service. The average response time of the service. The number of requests per minute this service could handle. The freshness of the provided information from the stock market, e.g., the price of an index that the service search and return for the user must be at least recent as the real values on the market 5 minutes before. The security level of the service. The conditions for achieving a QoS level could be: The subscription price to use the service. The minimal speed of the network connection The location of the user, i.e., for mobile phone users the services may not be available at certain places. The equipment and software needed in the client machine, etc. The Stock Market application helps the users to find and use the web services which satisfy their requirements more easily. These users requirements include both

36 functional and quality requirements for the services. For example, some users might require Stock Market Information web services to exhibit the following quality criteria: The service is assured to be available 100% during the opening hours of the stock-market until the end of January. At other period, the meantime between failures of this service should be less than 0.05 ms. The average response time of the service should be less than 0.05 ms. The service should accept at least 50,000 requests per minute. The freshness of the provided information is 5 minutes, e.g., the price of an index that the service search and return for the user must be at least recent as the real values on the market 5 minutes before. The transfer data should be encrypted with 256-bit DES standard. A user might also provide other related information about her, which could be used as a condition to search for the services: The maximum subscription price she is willing to pay is 0.5 Euros per hour. She is on vacation on the top of Mont Blanc from now until the end of January. In this case, the task of searching and selecting the best services for this application is QoS-sensitive and is handled by the QoS-enabled Service Discovery Component of EPFL. Specifically, the Stock Market application will formulate a WSMO Goal which consists both functional and QoS requirements and call the unified API of the Discovery Component to get a list of matched services. This call to the unified discovery API will be sent to the functional Service Discovery Component and then to the QoS-enabled Service Discovery Component. The results of the discovery process are a list of matched web service descriptions, ranked by the matching level to the requirements of the user. The user will choose one web service that suits her needs and the Stock Market application will help her to invoke that chosen service. Additionally, the Stock Market application may use the API provided by the Monitoring Module to monitor the various QoS parameters of the invoked web services and report the collected values to the QoS-enabled Discovery Component via its API. These reports will help the Discovery Component to evaluate the real quality level of various services and be able to provide the more accurate values for answering future requests from the users. Bankinter can also query the QoS-enabled Discovery Component directly to know about the actual performance of its services and improves them if necessary. 4.6 Non DIP components for implementation This section describes non DIP components of the architecture that will be used in this prototype Web based interface. Developed in the context of WP10. Stock market application will be used via web-based UI that can be viewed from within a standard web browser without installing additional software. 23

37 Natural Language Recognition Component. This component will be developed inside WP10 based on isoco s expertise in providing applications based on natural language. For this prototype WS are necessary. These Web Services wrap the functionalities implemented in Bankinter in order to serve as an input for the SWS. Several WS are implemented and others will be implemented by Bankinter. 5 CONCLUSION In this deliverable we have shown the overall purpose of the system to be created: to enhance the Stock Market prototype with the use of SWS. The prototype to be created will have the advantages of automatic service discovery, a service composition based on semantics and service invocation. The architecture proposed in this deliverable allows the description and use of SWS that will form an integral part of a Semantically Enabled Service Orientated Architecture. The prototype to be created will be based on WSMO and its four elements: WS, Goals, Mediators and Ontologies. Forthcoming deliverables will illustrate in detail WSMO descriptions (of goals, mediators and WS) and the domain Ontologies to be created to support the overall architecture. The focus of this system is primarily on Bankinter s customers needs in order to make friendly their interaction with the broker application. The design described in this deliverable will be implemented as a prototype in D10.9. REFERENCES [1] Mónica Martínez Montes, José Luís Bas, Sergio Bellido, José Manuel López, Silvestre Losada, Richard Benjamins (2004). Analysis Report on ebanking Business Needs. DIP deliverable D10.1 [2] Martínez Montes M, Bas JL, Bellido S, Corcho O, Losada S (2004) Design and Specification of Application. DIP deliverable D10.2 [3] Corcho O, Losada S, Martínez Montes M, Bas JL, Bellido S, (2004) Financial Ontology. DIP deliverable D10.3. [4] Losada S, Corcho O, Martínez Montes M, Bas JL, Bellido S, (2004) Design and Specification of Application. DIP deliverable D10.4. [5] De Bruinjn et al The Web Service Modeling Language WSML, version 0.2 available at [6] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 1.2 available at [7] M. Zaremba, et al, (2005).. DIP Revised Architecture D 6.5. [8] C. Feier et al: WSMO Primer, version 0.2 available at [9] D. Roman, J Scicluna, Orchestration in WSMO, Working Draft v [10] E.Cimpian, U. Keller, M. Stollberg, and D. Fensel. Choreography in WSMO.DERI Working Draft v01,