안녕하세요 !!!

1. 안녕하세요!!!

2. Challenges with WEB SERVICES Janarbek Matai Tel:010-6874-2268 Mail:janarbek@icu.ac.kr

3. Contents • Motivation • Technical Challenges • Lack of Security at protocol level • Lack of transaction management capabilities • Lack of Universal data definition • Discovery of Services, Interoperability, Execution of Composite Services.

4. Motivation WebServiceDescriptions Publish (UDDI) Find (UDDI) ServiceRegistry WSDL WSDL ServiceRequester ServiceProvider Call (SOAP) WebService Why WS are not popular?

5. Still problems not yet solved…!!! • Lack of Security at protocol level • Lack of transaction management capabilities • Lack of Universal data definition • Discovery of Web services • Inter-operability of Services • Execution of Composed Service • Service Portfolio challenges

6. Who are they? Albert Einstein Tim Berners Lee May be, you think you can not beat Einstein, But you can still be scientist like Tim Berners Lee.

7. Web Service Security IssuesChallenge #1

8. Lack of Security at protocol level Theory: This thing has 4 wheel drive But we only take it to the Mall Practice: In this environment we need 4 wheel drive Web: Firewalls, SSL Web Services: Firewalls, SSL

9. Why Web Services Security is a Challenge • HTTP • SOAP APIs (dozens of methods for hackers) • Web Services are more complex than Web • Security must be “End-to-End”

10. Lack of security • The most critical issue limiting the widespread of WS • Without Security, Web Services are Dead on Arrival

11. Web Service TransactionChallenge #2

12. What is a transaction? • A transaction is the basic logical unit of execution in an information system. A transaction is a sequence of operations that must be executed as a whole, taking a consistent (& correct) database state into another consistent (& correct) database state;

13. For example. Database in a consistent state Database in a consistent state Transfer £500 Account A Fred Bloggs £1000 Account A Fred Bloggs £500 Account B Sue Smith £0 Account B Sue Smith £500 begin Transaction end Transaction

14. ACID Characteristics A. Atomicity: a transaction is an atomic unit of processing and it is either performed entirely or not at all (Commit, Rollback) C. Consistency Preservation: a transaction's correct execution must take the database from one correct state to another I. Isolation/Independence: Each transaction is unaware of other ones executing concurrently. D. Durability (or Permanency): The changes which have been made persist, even if there are system failures.

15. Transaction State A transaction must be in one of the following states: –Active: while the transaction is executing. –Partially committed: after the final statement has been executed. –Failed: after the discovery that normal execution can no longer proceed. –Aborted: after the transaction has been rolled back. –Committed: after successful completion.

16. Transaction Models in WS • ACID transaction -Commit, Rollback, not suitable for all WS • Long running action - over a long duration • Business process transaction -heterogeneous transaction domains together into a single business-to-business transaction. • OASIS-BTP: HP, Sun BEA, Oracle and others - does not address transaction interoperability • WS-C/T: IBM, Microsoft and BEA -Not yet real world implemention

17. However, • None of these protocols has not yet been finalized and there is not overwhelming agreement between the various Web Services tool vendors on a standard.

18. Why WS Transaction is a challenge? • Current mainstream Web services standards do not provide a mechanism for handling synchronization across multiple enterprise applications. • For example, Cannot be committed or rolled back at atomic units if they span multiple services.

19. Storage Supplier Services PC Build and Delivery Services Transportation Casing, End-User peripherals Services Motherboard etc.. Supplier Services PC build example.

20. SOAP SOAP SOAP SOAP SOAP Application Message Transaction Protocol Message WS Transaction

21. Activity External Peripheral Supply Service Storage Supply Service Transaction Coordinator Motherboard Service

22. Tx ID Create Transaction Create Transaction Tx ID

23. Tx ID Tx ID Tx ID Purchase m/board etc. Purchase m/board etc. Enrol Enrol

24. Tx ID Tx ID Tx ID Buy peripherals Buy peripherals Enrol Enrol

25. Tx ID Tx ID Tx ID Enrol Buy disks Buy disks Enrol

26. Prepare Prepare Prepare Tx ID Tx ID Prepare Prepare Prepare

27. Commit Commit VoteCommit Commit Tx ID Commit Commit

28. Commit Commit Tx ID Commit Commit

29. Success Tx ID Success

30. Or…

31. Prepare Prepare Prepare Tx ID Tx ID Prepare Prepare Prepare

32. Cancel Commit VoteCancel Commit Tx ID Commit Commit

33. Cancel Tx ID Cancel Cancel

34. Failed Tx ID Failed

35. Limitations of Current Transaction • Traditional transactions are good for “short”-duration activities. • Seconds, minutes, … • Resources must remain locked for the duration of the transaction. • Early release of resources may cause cascade-rollback. • Coordinator failure may leave resources locked for extended periods. • Implicit assumption of trust

36. Limitations of Current Transaction • Traditional transactions implicitly assume: • Closely coupled environment. • All entities involved in a transaction span a LAN, for example. • Short-duration activities. • Must be able to cope with resources being locked for periods • Therefore, do not work well in either: • Loosely coupled environments; • Long duration activities. • Web Services are loosely coupled. • B2B activities may be long in duration.

37. Transactions and Web Services • Business-to-business interactions may be complex. • Involving many parties. • Spanning many different organisations. • Potentially lasting for hours or days. • e.g., the process of ordering and delivering parts for a computer which may involve different suppliers, and may only be considered to have completed once the parts are delivered to their final destination. • B2B participants cannot afford to lock resources exclusively on behalf of an individual indefinitely. • Potential for denial of service. • Rules out the use of atomic transactions.

38. Could Existing Solutions be Applied? • In a word, no. • World is composed of closely coupled environments glued together by loosely coupled infrastructure. • We already have the closely coupled world tied up • EJB, CORBA, COM (DTC & MTS) • Even if closely coupled solutions could be tailored for Web Services they would have problems • Firewalls! • Current protocols do not penetrate firewalls, even though many fine firewall products exist. • One company’s protocol may not interoperate with its partners’. • Web Services architecture is radically different from traditional component architectures.

39. Lack of Universal data definitionChallenge #3 • Purpose of WS: • Platform, language independent • Standardization • Application-to-Application • ….

40. Lack of Universal data definition • Web Services rely on XML Schemas for standardizing data formats • There are no universal standards for representation of data • Companies create their own data formats (DTD/XSD)

41. Discovery of Web services for developers and consumersChallenge #4 • Key word based search • Services could be searched for in UDDI registries by providing keywords describing the service needs. • UDDI uses the classification of services, to provide efficient searches. • As searching UDDI is based on keywords and classifications, the resulting services might not match the service requirements • Ontology based search • If services are described using ontologies, then searching based on ontologies could yield better results.

42. Inter-operability of ServicesChallenge#5 • Structural and Semantic heterogeneity existing between different Web services are needed to be resolved. • Structural heterogeneity • Need to handle data mapping, for propagating data from one service to another • How to automate this data mapping ? • Semantic heterogeneity • Need to understand the meaning of the terms employed in the interface descriptions of the services and resolve the differences

43. Execution of Composed ServiceChallenge #6 • A composed process can be enacted in two ways • 1. Centralized manner • controller based Execution • has the disadvantage of having a single controller coordinating the entire process Execution e.g., eFlow system • 2. Distributed manner • There is no controller involved, execution is based on coordination of service providers • complex to implement

44. Challenge #7 Challenge #7 will be emerge after solving above problems.

45. Summary • Lack of Security, Transaction are most challenging problems limiting the widespread of Web Services • Existing or traditional solutions are not enough! • There is not yet Universal data definition • Discovery of Web services for developers and consumers • Inter-operability of Services • Execution of Composed Service

46. But don’t forget… • Web Services will be the next generation of WEB.

47. References: • [1] S.Chatterjee, J. Wabber, “Developing Enterprise WS An Architect’s Guide”, Prentice Hall. • [2] Sami Bihiri and Olivier Perrin, Ensuring Required Failure Atomicity of Composite WebServices, VandoeuvrelesNancy Cedex,France, 2005. • [3] Luis Felipe Cabrera, “Web Services Atomic Transaction”, Microsoft • [4] A. Nagy and Sanjiva Weerawarana, “Web Services: Why and How”, IBM T.J. Watson Research Center 2002 • [5] E. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, \Simple Object Access Protocol (SOAP) 1.1", May 2000. Available at http://www.w3.org/TR/SOAP . • [6] D. Bunting et al. Web Services Transaction Management (WS-TXM) Version 1.0. Arjuna, Fujitsu,IONA, Oracle, and Sun, July 28, 2003.

48. Thank You!!!