Web services are becoming popular as a system integration solution for distributed applications.
They allow for publishing, finding and binding of distributed software components over a Wide Area Network like the Internet and are platform and operating system independent.
In a traditional scenario, ontologies are defined and published by a consortium or enterprise group for each application discourse. These specifications can later be implemented by many web service providers.Eje: Procesamiento distribuido y paraleloRed de Universidades con Carreras en Informática (RedUNCI

Coppo, Ricardo

Delrieux, Claudio

Servicio de Difusión de la Creación Intelectual

Towards Collaborative Applications using WebServicesRicardo Coppo Claudio DelrieuxDepartamento de Ing. Ele´ctrica y ComputadorasUniversidad Nacional del Sur, Bah´ıa Blanca, ARGENTINAe-mail: rcoppo@bblanca.com.ar, claudio@acm.org1 IntroductionWeb services are becoming popular as a system integration solution for distributed ap-plications. They allow for publishing, ﬁnding and binding of distributed software compo-nents over a Wide Area Network like the Internet and are platform and operating systemindependent.In a traditional scenario, ontologies are deﬁned and published by a consortium or enter-prise group for each application discourse. These speciﬁcations can later be implementedby many web service providers.Consider an institutional service that could be deﬁned by the countries governmentor board of education. Each participating college or university could later implementthe service on a local basis. Users would discover the available services in a directorythrough some kind of search facility and develop front-end applications. Receiving thedata in a standardized format allows the information of each participating institution tobe integrated into existing applications without disrupting the normal look and feel thateach user experiences on his own terminal.Collaborative applications require a diﬀerent approach. Each prospective user is ex-pected to download, process and return results to a centralized agent, collaborating withher participation to the accomplishment of a much larger goal and beneﬁting from theresults that other members supply. The collaborative eﬀort becomes a massively paral-lel human and computational processing resource devoted to the resolution of complexproblems in small segments.2 Collaborative actorsThree proﬁles can be deﬁned for the actors participating in the collaborative eﬀort: thecollaborative participant or member, the collaborative server and the end-user client.2.1 The collaborative participantThis user type will typically receive prepackaged software to interact with the collaborativeserver, download data segments to be processed, and upload results obtained on hermachine.Simple collaborative applications will only request the use of raw computing powerfrom this kind of user, downloading to the participant’s machine data segments and har-vesting results as fast as the local computer can produce. The collaborative prepackagedsoftware would probably run in a back-ground or idle cycle stealing processing mode soas not to disrupt local processing.In a more complex scenario more human interaction and decision making would berequired from the collaborative member. Applications using image processing, fotoin-terpretation and classiﬁcation algorithms are typical examples. In these cases, humanintelligence and expertise might be needed to solve the problem at hand. This will makethe participants participation a long running process for the server while these decisionsare being taken.The prepackaged software can or may require third party programs to be installed onthe local machine to do their work. The collaborative can now take advantage of highcost licensed software installed on the client’s machine without infringement to softwarecopyright law.On occasions experienced software developers may want to write their own interfacesfor the collaborative server. The use of web services as a common communication mecha-nism allows them to access the server in a programmatic way in a platform and operatingsystem independent manner. Most development packages now include special tools toconnect and use web services.2.2 The collaborative serverThe collaborative server is responsible for the control of long duration processing threads.Each user, as she logs in creates a new business process workﬂow and begins interactingwith the raw data in a controlled manner. The workﬂow state is serialized to a specialdatabase. As the process advances from state to state the workﬂow description determinespossible alternatives, timeouts and error processing.The server will maintain the original data bank and serve requests for partial datasegments of the raw data. Once the results are received from the collaborative participantsthey are stored in a ﬁnal data store.An operational console should allow the collaborative controller to visualize the amountof open ﬂows, their present processing state and provide options to kill or release unﬁn-ished threads.Other objectives for the server include information security procedures such as uservalidation, data encryption, and database administration.Figure 1: BPEL Architecture2.3 End-user clientNot all potential users will want to participate in the processing of the raw data. Mostwill only want the ﬁnished results to be available for their own personal use.These users can be considered as end-user clients and may wish to receive the in-formation through diﬀerent channels. Typical clients will want a web page interface butmore advanced users will wish to develop their own applications. Delivering the processedinformation through web services will greatly enhance its usability.3 Workflow LanguagesLong running workﬂows that require state serialization have been common in businessapplications that move information over enterprise boundaries. (Consider for example ainvoice procedure that requires credit checks for the buyer, supplier stock availability, andshipping requests).These processes can be modeled with diﬀerent languages and have been recently up-dated to include web services as a possible means of interaction.Both IBM and Microsoft have deﬁned workﬂow languages based on XML. Their indi-vidual eﬀorts have been united in BPEL4WS - Business Process Execution Language forWeb Services. Many DBMS vendors have incorporated BPEL4WS as extensions to theircore products.Using BPEL4WS the collaborative developer can specify the workﬂow, with its errorsand exceptions in a standard language. He can specify the workﬂow using a visual editorand submit the resulting XML ﬁle directly to the collaborative server.On the server, a BBEL engine keeps track of the open ﬂows and their present state.If a user tries to break out of the ﬂow either by an intent to access unauthorized servicesor by not following the correct sequence the engine will abort the ﬂow.The BPEL engine delivers console output to the collaborative controller and interfaceswith other web services available over the network or with local programs when necessary.The BPEL engine is an abstract concept and may itself be implemented over a hostof real machines if it must sustain high workloads or a great number of users.References[1] Arsanjani et al., “Web Services: Promises and Comprimises”,Queue, pp 49-58,March 2003.[2] Cauldwell P., Chawla R. et al., “Professional XML Web Services”, Wrox Press Ltd.,London, 2001.[3] Cerami E., “Web Services Essentials”, O’Reilly, New York, 2002.[4] Erl T., “Service Oriented Architecture: A Field Guid to Integrating XML and WebServices”, Prentice Hall PTR, 2004.[5] Fremantle S., Weerawarana, Khalaf R., “Enterprise Services”, CACM, 45:10, pag.77-82, October 2002.[6] Gibbins N., Harris S., Shadbolt N., “Agent-based Semantic Web Services”, Proceed-ings of the 12th WWW, Budapest, Hungr´ıa, pag. 710-717, May 2003.[7] Gottschalk K., Graham S., Kreger H., et al., “Introduction to Web Services Archi-tecture”, IBM Systems Journal, 41(2), pag. 170-177, 2002.[8] IBM, Microsoft, et al., “Business Process Execution Language for Web Services”,version 1.1, 2003.[9] Kleijnen S., Raju S., “An Open Web Service Architecture”, Queue, pag 39-46, Marzo2003.[10] Leyman, F., et al. “Web Services Flow Language” International Business Corpora-tion (IBM), Software Communications Department, Route 100, Building 1, Somers,NY 10589, USA, May 2001.[11] Newcomer E., “Understanding Web Services: XML, WSDL, SOAP, and UDDI”,Addison-Wesley Professional, 2002.[12] Siegel J.,“Achieving Interoperability for Integration of Heterogeneous COTS Geo-graphic Information Systems”, Proceedings of ACM GIS 2002, McLean, Virginia,EEUU, pag. 162-167, 2002.[13] Thatte, S., “XLANG - Web Services for Business Process Design”, Microsoft Cor-poration, 2001.[14] Visser, Ubbo, “Intelligent Information Integration for the Semantic Web”, Springer-Verlag Berlin Heidelberg, 2004.[15] W3C “Web Services Architecture”, W3C Working Group Note 11 February2004, Editors: David Booth, Hugo Haas, Francis McCabe, Eric Newcomer,Michael Champion, Chris Ferris David Orchard, World Wide Web Consortium,http://www.w3.org/TR/ws-arch/, 2004.[16] WfMC, “Workflow Management Coalition Workflow Standard Process DefinitionInterface - XML Process Definition Language”, Workﬂow Management Coalition,2436 N.Federal Highway #374, Lighthouse Point, FL 33064, USA, Document #WFMC-TC-1025, Version 2.0, 2005.[17] Yin J., et al., “Engineering Server-Driven Consistency for Large Scale DynamicWeb Services”, Proceedings of the 10th international conference on WWW, HongKong, pag. 45-57, Mayo 2001.[18] Zeng L., Benatallah B., Dumas M., “Quality Driven Web Services Composition”Proceedings of the 12th International conference on WWW, Budapest, Hungr´ıa,pag. 411-421, Mayo 2003.

Towards collaborative applications using web services

http://sedici.unlp.edu.ar/bitstream/handle/10915/20765/Documento_completo.pdf?sequence=1

Towards collaborative applications using web services

Abstract

Similar works

Full text

Available Versions

Servicio de Difusión de la Creación Intelectual