1. Welcome Presented by Thierry KIKI & David SCHNEIDER

2. Project objectives Introduction on MilGate Embedded HTTP Servers HTML Generation Client tools Web Services Description Interoperability Tests Conclusion Questions

3. Find a good way to generate on the fly HTML pages within the MilGate which providing a web browser access. Survey and evaluate different embedded HTTP servers running on Linux and/or VxWorks for the MilGate.

4. Survey and evaluate different client frameworks and describe their compatibilities with the Web Services. Describe the flow of information from the KEYMILE files which describes the internal structure through the embedded HTTP Server to the MileGate Define the web service and the necessary transformation. Implement a prototype using the web service (MMI).

5. IP-based multi-service next-generation access platform Combines broadband access, telephony and data interfaces Migrate your telecommunications network to the NGN high quality Triple Play, broadband business services and traditional telephony and data services at the same time core unit & 20 other units example: 960 xDSL or 456 COMBO

6. Embedded system VxWorks, C++ PowerPC ~400MHz 256MB RAM, 128MB flash memory

8. Selectives criteria of servers Poll → One process for all requests Multi-thread → each request has its process OS → Support at least an embedded linux Language → C/C++, Python, Perl… Memory footprint → Memory usage while the app. is running → How often the source code is updated Release date → How often the source code is updated Popularity → many forums (ways) to solve an array of problems

9. Security → Degree of protection offers by the server Requiered fields AuthentificationHTTPS (SSL or NanoSSL)OpenSSL Dynamic Content → Technologies used to generate informations dynamically CGI / FastCGISSI / SSJC / C++ Common functionality → Other valuable fields CompressionChunkingIPv6 & DocumentationSession / Cookies

10. Server classification credits Classification of compared servers HTTP server classification

11. We performed a feasibility study and suggested a manner for the implementation. The suggestion contains: Problem analysis Functional design Discovery mechanism GUI prototype Generation of the files Reaction on modifications No client installation needed !

12. Frameworks functionalities

13. Evaluated frameworks Metro : Java API (JAX-WS) & tools for WS (SUN) java implemention of SUN API JAX-WS (Apache Group) CXF : java implemention of SUN API JAX-WS (Apache Group) Axis2 : C & java implementation (Apache Group) Open Source technology company devoted to WS WSO2 : Open Source technology company devoted to WS Key contributor for Apache web services project Provides several implementations of WSF : C, C++, PHP, PERL, JAVA …

14. Evaluated frameworks WCF: Microsoft API in.Net for building SOA WCF: Microsoft API in.Net for building SOA We briefly considered for : gSOAP (C++)NuSOAP, Pear SOAP (PHP) PySOAP (Python) SOAP::Lite (Perl)

15. Evaluated frameworks Unavoidable frameworks Microsoft Apache Glassfish

16. Principle Performed work Further development / Suggestions

17. W3C definition public interfaces and bindings are defined and described using XML interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols Basic components of Web Service Architecture Communication Service Description Directory Service  SOAP  WSDL  optional, not used

18. The new parts added to the WSDL file are: Fault type Declaration of headers Integration of faults and headers into operation’s WS-Transfer “soapAction” for operation’s Automatic binding of the headers into the SOAP messages wsdl:service element with the Endpoint References  XSLT

19. New discover message just for MO’s Use of relationships for operations Adaptation of notification mechanism Meta constraints for invocation of operations Many other possibilities as advertisement of new endpoints operational status of resource customized requests and more..need to be analyzed carefully!

20. Web services ↔ SOAP interoperability The encoding type will always be UTF-8. Avoid «NULL» attributes in the SOAP Headers WS Interoperability Organization (WS ► I) WS►I Tools WS ► I Profiles Basic Profile V1.1Simple SOAP Binding Profile V1.0 WS-MonitorWS-Validator

21. WS►I Tools Interoperability testing tools 1.1

22. Test definition Use WS-I tools for testing interoperability Send a SetLabel and Receive a GetLabel Verify the usage of WS-Management Test of the xFer module (WS-transfer) Generate java classes from WSDL file Convert WSDL 1.1 to 2.0 with WSO2 tools

23. Test Validation Use WS-I tools for testing interoperability : Not Performed Send a SetLabel and Receive a GetLabel : successful Verify the usage of WS-Management : successful* Test of the xFer module (WS-transfer) : successful Generate java classes from WSDL file : failed Convert WSDL 1.1 to 2.0 with WSO2 tools : failed

24. Benefit of the project What needs to be improved in the future…

25. ?

26. Evaluated frameworks General features → Overview Data binding → How to access XML Encoding table → Encoding mechanism associates to XML → Data transfer protocol Transport → Data transfer protocol WS-Concepts → Web services concepts supported