Web Services Directory based on Peer-to-Peer Technology

1. Web Services Directory based on Peer-to-Peer Technology Joachim Götze, Markus Hillenbrand, and Paul Müller Euromicro 2006Cavtat, Aug 29 – Sep 1, 2006 Markus HillenbrandUniversity of Kaiserslautern, Germany Integrated Communication Systems Lab Email: hillenbr@informatik.uni-kl.de Markus Hillenbrand, AG ICSY, University of Kaiserslautern

2. Outline • Motivation • Related Work • Venice • Architecture • Management Services • VoIP Services • Information Brokering in Venice • Directory Service • Information Broker • Implementation • Conclusion & Outlook Markus Hillenbrand, AG ICSY, University of Kaiserslautern

3. Motivation • Directory service is a core component in SOA • Drawbacks of current solutions: • Centralization • Up-to-dateness • Censorship • Incompatibility • Our Solution: P2P Markus Hillenbrand, AG ICSY, University of Kaiserslautern

4. Related Work • UDDI • Business registry • Weak up-to-dateness • Not globally available anymore • P2P based re-implementations of UDDI • [2] Florian Forster, Hermann de Meer: Discovery of Web Services with a P2P Network • [3] Discovery of WebServices with Gnutella • [4] Wolfgang Hoschek: A United Peer-to-Peer Database Framework and its Application for Scalable Service Discovery • [5] Ludwig Mittermeier and Roy Oberhauser: Ad-hoc-Web-Services with P2P-Technology Markus Hillenbrand, AG ICSY, University of Kaiserslautern

5. Venice • New architectural approach for VoIP using Web services and Peer-to-Peer • Key architectural aspects • All VoIP providers act autonomously, but have to work together • Supplementary services and their interoperability are the assets of a VoIP provider • Customers are no computer specialists and urge for easy-to-install, easy-to-update, and easy-to-use software. • Key implementation aspects • Move as much code as possible from the client to the servers (i.e. Web services) • Every supplementary service is a Web service Markus Hillenbrand, AG ICSY, University of Kaiserslautern

6. The Venice Architecture Markus Hillenbrand, AG ICSY, University of Kaiserslautern

7. The Venice Architecture Markus Hillenbrand, AG ICSY, University of Kaiserslautern

8. The Venice Architecture • Management Services: • Domain Information Service • Single Sign-on Service • Software Deployment Service • Information Broker • Metering, Accounting & Billing • Feature Interaction Manager • Basic VoIP Services: • VoIP Service • H.323 • SIP • Supplementary Services: • CFU, CFBY, CFNR • CLIP, CLIR, COLP, COLR • CCNR, CCBY, TCS • 3PTY, VM, … Markus Hillenbrand, AG ICSY, University of Kaiserslautern

9. Information Brokering in Venice P2P Markus Hillenbrand, AG ICSY, University of Kaiserslautern

10. Information Brokering in Venice • Many distributed services • From a lot of service providers • No central control • Avoid manual service registration • Retrieve necessary data from services • Allow for temporary unavailability • Search for arbitrary data • Meta data about users (status, personal details, etc.) • Other VoIP related data sets (audio files, etc.) • Seamless integration into SOA • Access to directory via Web service • P2P communication model between directories Markus Hillenbrand, AG ICSY, University of Kaiserslautern

11. Directory Service • Availability • Centralization means single point of failure • P2P means scalability and robustness • Replicated IB improve availability • Fast information retrieval • Mainly local interaction (e.g. VoIP and supplementary services) • Caching strategy for remote data • Transparent usage of P2P • Encapsulate P2P in a Web service • No need for opening P2P ports on all service hosts • Local registration of services • Deployment of a service also registers it with the IB • Service can instantly be found by others • Set of available services always up-to-date • Temporarily unavailable services known to the IB Markus Hillenbrand, AG ICSY, University of Kaiserslautern

12. Information Broker • Extension of the service directory functionality • To broker arbitrary data (i.e. application dependant) • Online status of users and/or services • Meta data about • Users • Services • Providers • Application specific data • Audio files (e.g. voice messages) • Images (e.g. MMS) • Videos (e.g. video messages) • Software (service deployment) Markus Hillenbrand, AG ICSY, University of Kaiserslautern

13. Implementation • Based on JXTA • Fully integrated into the Venice framework • Example: • Deploy service (A) • Advertise service (A) • Use service (B) • Request 3rd party service (B) • Search for service (B) • Communicate via P2P (A-B) • Cache and return data (B) • Use service (B) Markus Hillenbrand, AG ICSY, University of Kaiserslautern

14. Conclusion & Outlook • SOA = many services & many providers • Directory service is a core component • Venice Information Broker implements • A service directory • A broker for arbitrary data • Outlook: • Improve caching strategy according to dependability meta data • Have a look at other P2P technology like OpenDHT Markus Hillenbrand, AG ICSY, University of Kaiserslautern