Cpp In Soa


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cpp In Soa

  1. 1. C++ In SOA Nandika Jayawardana Tech Lead, WSO2, Inc nandika@wso2.com
  2. 2. Introduction to SOA in C++ ● In this presentation we will look in to the implementation of SOA using Web Services in the C/C++ world from a native Web Services Stack's point of View.
  3. 3. Why use C++ ● C++ is still widely used in the industry due to ● Performance advantage of the native code ● Flexibility available from object oriented language ● Tight control over memory and CPU
  4. 4. Typical applications that use C++ ● Applications which require high performance and the ability to handle large volumes of data ● Financial Market Applications ● Large E-Commerce applications ● Banking Applications ● Telecommunication Systems ● Data Base Systems ● Applications which require tight control over memory and CPU ● Operating Systems (C/C++) ● Embedded Systems
  5. 5. Some Use cases ● A legacy C++ system which has been performing useful work for a long time. This has remained isolated while all other systems in the organization evolved and connected together. ● Need to integrate this system with other applications to use its functionality in a broader perspective. ● Options ● Rewrite the system ( Costly ) ● Integrate using EAI ● Integrate using a native Web Services Stack
  6. 6. Some Use Cases SAP .NET Legacy System Secure, Reliable, Binary J2EE Web Services CICS Java
  7. 7. Some Use cases ● A high performance application is used in an organization (Telecommunication, Banking ) ● Need to provide new products and services using the system on a regular basis to keep up with market competition ● Difficult to keep changing, adding new functionality to the existing system ● Does a better way exist to cater for the new requirements without the hassle of change or loosing the performance ?
  8. 8. Some Use cases ● I need my embedded system (camera, car, printer, robot, ... ) to be able to talk to external systems which are running heterogeneous hardware and software
  9. 9. SOA ● Decomposing business function into reusable, independent components which communicate using standard protocols with messages and semantics defined by contracts. ● SOA is an Enterprise Architecture ● The application using a service should be independent of the location and implementation of any services it uses
  10. 10. SOA
  11. 11. Why SOA ● SOA simplifies connecting systems ● Integration is driven by number of factors ● Straight-through-processing ● Handling web transactions without manual intervention, leading to greater scalability ● Mergers and De-mergers ● The increasing change in organizational structure is making loosely-coupled connections more important ● Partnerships ● Outsourcing ● Time to Value
  12. 12. Native Web Services Stack ● What would you look from a native web services stack to solve the above stated problems ? ● Support for Basic Web Services Standards ● Tooling for WSDL ● Portability ● Performance / Low memory foot print ● Security ● Ability to handle binary data ● Interoperability ● Asynchronous communication
  13. 13. Basic Web Service Standards ● SOAP 1.1 , 1.2 ● WSDL (Web Services Description Language) ● XML Schema ● HTTP <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header/> <soap:Body> <getProductDetails xmlns="http://warehouse.example.com/ws"> <productID>827635</productID> </getProductDetails> </soap:Body> </soap:Envelope>
  14. 14. Working with WSDL ● WSDL (Web Service Description Language) ● defines a service contract ● Focuses on: ● What the messages are ● Schema ● How they flow (in, in-out, etc) ● Message Exchange Pattern ● Where they are ● Endpoint URLs
  15. 15. Working with WSDL ● WSDL is complex ● WSDL is intended to be machine readable and machine processable ● Typical approaches to building services and clients using WSDL ● Code Generation ( Common) ● Dynamic Invocation ( Rare )
  16. 16. Code Generation Stub <wsdl/> Code Generation Tool document Skeleton
  17. 17. Advantages of Code Generation ● All complex details of mappings between C++ types and XML schema types are handled by the generated code. ● The developer deals with C++ types ● Quickly develop services and clients ● Faster than the dynamic invocation technique ● Developer can concentrate on his business logic
  18. 18. Working with WSDL in WSF/C++ ● Comes with built in Code Generation tool. ● Generates Client Stubs, Service Skeletons, Service descriptors and Build scripts. ● Generating a Service Skeleton Linux: sh WSDL2CPP.sh -uri calculator.wsdl -ss -sd -d adb -u Windows: WSDL2CPP.bat -uri calculator.wsdl -ss -sd -d adb -u ● Generating a Client Stub Linux: sh WSDL2CPP.sh -uri calculator.wsdl -d adb -u Windows WSDL2CPP.bat -uri calculator.wsdl -d adb -u
  19. 19. How to adapt a C++ Application as Web Services
  20. 20. Using WSF/C++ ● Supports multiple platforms ● Linux ● Windows ● Solaris
  21. 21. Portability ● My legacy application is running on platform 'X'. Does your Web Service stack run on it ? ● It can boil down to multitude of issues ● Differences in operating system versions ● Differences in build tool versions, compiler versions ● Dependency problems
  22. 22. Performance ● Performance is a broad area. Usually Performance means response time. In another way, how many requests can the server handle per second ● However, performance depends on the system's hardware as well as load on the system ● Does the performance stay constant or does it degrade over time ● How does the performance vary with the size of the messages, load of the system
  23. 23. Low Memory Foot Print ● Some servers take large amount of memory just to start up ● How much memory does it require to run efficiently ( Important in embedded systems) ● Does the memory usage stay constant while handling large xml messages, large binary content
  24. 24. Security ● Important, confidential data need to be exchanged between parties. ● Transport Level security ● Message Level Security
  25. 25. Security Terminology ● Confidentiality ● The assurance that the message has not been read by anyone other than the intended reader ● Integrity ● The assurance that data is complete and accurate ● Non-repudiation ● Prevent denial of action ● unforgeable evidence ● Authentication ● The verification of a claimed identity
  26. 26. Transport Level Security ● Achieved by using HTTPS ● Provides confidentiality through encryption ● Provides integrity through digital signature ● Service authenticate to client via certificates ● Client can authenticate to the service via certificates / basic, digest authentication
  27. 27. Transport Level Security HTTPS Client Service Is it really what you want ?
  28. 28. Transport Level Security vs Message Level Security
  29. 29. Message Level Security ● Achieved using WS-Security ● Authentication with UsernameToken ● Provides confidentiality through encryption ● Provides integrity and non-repudiation through digital signature
  30. 30. Security with WSF/C++ ● Supports Both transport Level security and Message Level Security ● Security is configured using WS-Security Policy ● Client is configured by specifying the policy configuration. ● Service is configured for security by the deployment script ● Eg ServiceClient sc(client_repo, end_point); sc.engageModule(“rampart”); sc.setPolicy(new NeethiPolicy(security_policy_file));
  31. 31. Handling binary data ● “Attachments” ● Video, Images, Documents, ... ● There are two ways to transfer binary data in SOAP ● By Value (Encoded text of data within the xml) ● base64 – 4/3x original size ● hex – 2x original size ● Reference ● pointer to outside the XML ● MTOM/XOP ● Standardised approach to transfer binary data
  32. 32. Attachment handling with WSF/C++ ● Supports ● Base64 ● MTOM and SwA ● Support for caching large attachments ● Class DataHandler which handles binary content // Enable mtom in the options object. options->setEnableMTOM(true); // Create a Data Handler with the image OMDataHandler * data_handler = new OMDataHandler(image_file_name, "image/jpeg"); // Create OMText with Data Handler OMText * child3 = new OMText(child2, data_handler);
  33. 33. Interoperability ● The ability of two or more systems or components to exchange information and to use the information that has been exchanged ● Achieved by adherence to the specifications and regular testing against other systems ● Interoperability with the major SOA players guarantees that you services will be accessible by other products and your clients will be able to talk to other services
  34. 34. WSF/C++ and Interoperability ● Interoperability tested with .Net, Axis2 and other Java Web Services Stacks ● Has been tested with data types (Complex, Simple) as well as advanced features such as XOP/MTOM, WS-Security, WS-RM
  35. 35. WSF/C++ ● SOAP 1.1 and SOAP 1.2 ● WS-Addressing ● 1.0 ● submission ● MTOM and SwA ● Support for caching large attachments ● WS-Security ● Base security standards mean that messages can be protected using Encryption, Authentication and Signature ● Including WS-SecureConversation and WS-Trust ● WSDL2CPP Code Generation tool ● Supports generating client stubs, service skeletons, build scripts and deployment scripts
  36. 36. WSF/C++ ● WS-Policy and WS-Security Policy ● Enables using industry standard XML to configure security ● SSL Enabled Transport Layer ● WS-Reliable Messaging 1.0, 1.1 and WS-RMPolicy ● Enables reliability between platforms including message resending, duplicate detection and persistence ● Full REST support (GET, PUT, DELETE, POST) with custom URI Mapping ● Enables mapping a REST API easily and naturally ● Useful tools ● Tcpmon ● wsclient
  37. 37. Q&A