1. CORBA AND SOAP Unmesh Kulkarni i2 Group Ashish V. Tendulkar Directory Database integration group (www.eusersolutions.com) Persistent Systems Pvt. Ltd. Pune (www.pspl.co.in)

2. OUTLINE Introduction to middleware CORBA Concepts Problem Domain SOAP Synergies Conclusion

3. What is Middleware?  Glue for Components  Sits Between OS and Applications  Distributed Object Services  CORBA, COM, DCE, Java/RMI …  XML?

4. CORBA - Objectives  OS Independence  Language Independence  Remote Methods  Static/Dynamic Invocations  Distributed Services

5. Interoperability Standardization of –  Binary Formats : in-memory  API’s : Programming Support  IDL, Type Libraries, File Formats  Data Representation – CDR/NDR  Transfer Protocol

6. CORBA provides.. The PRO’s :  IDL  Stub-skeleton generators  Services API’s  CDR  IIOP And The CON’s  Complexity  Vendor dependency  Costly - large volumes  Behavior marshalling  Internet / Firewalls  COM-CORBA Inter- operability

7. The problem.. Client App. Proxy Server Server Application Server Firewall

8. Implications  Industry not shifted completely to either one  Vendor specific  Lack of interoperability  Require high-tech runtime environment

9. Why XML?  Simple text markup language  Platform, language and vendor agnostic  Easily extensible  Capable of solving interoperability problem

10. Why HTTP?  Ubiquitous  Supported by every web browser and server  Effective technology for transferring text, graphics and other information

11. XML + HTTP = SOAP  HTTP is used for transport  XML as encoding scheme  Endpoint HTTP based URL for the target  Object mapping: implementation specific

12. SOAP call anatomy

13. SOAP Component HTTP Headers SOAP method name SOAP Envelope SOAP Header SOAP Body Call element Object Endpoint ID Method/Interface ID Extension Headers Parameter Data

14. Uses of SOAP  SOAP greatly simplifies data exchange in B2B application over extranet  Enables web site to integrate services from other sites  Remote scripting more prevalent with SOAP  Non-browser client could seamlessly access a service across web

15. Example Message POST /string_server/Object17 HTTP/1.1 Host: 209.110.197.2 Content-Type: text/xml Content-Length: 152 SOAPMethodName: urn:strings-com:IString#reverse Hello, World

16. Example Response 200 OK Content-Type: text/xml Content-Length: 162 dlroW,olleH

17.  IOR : Object Reference  Interface Name /Method Name  Method Invocation with Parameters  POST/ObjectUR I HTTP/1.1  SOAP:MethodNa me  SOAP:Envelope  SOAP:Header  SOAP:Body  SOAP:CallEleme nt CORBA vs SOAP

18. Advantages  Simplest Data Representation  Hardware/Language Neutral  No Vendor Dependencies  Simple and Human-readable  Typing Flexibility  Firewall Issues

19. Then Why Not XML?  Distribution Support  Resource location, control and management  Services – Transactions, Events, Security etc.  Error Handling  Non-text data  Quality of Service – Reliability  Efficiency (Redundancy Elimination)

20. XML With CORBA  XML – Structure  CORBA – Infrastructure  XMI – Metadata Interchange  XML Interfaces – Components accepting/emitting XML documents

21. XML With CORBA…. Examples :  XMI – Exchange of UML models between Design tools and repositories  Persistent storage of components in IDE’s:  JavaBean Persistence  Resilience to versioning of libraries/VM’s  Defaults/Redundancy elimination

22. Synergy

23. Conclusion  SOAP is platform independent, language neutral protocol  SOAP does not replace COM and CORBA  SOAP works in place of DCOM and IIOP  SOAP does not pose huge security risks  Supports interoperation between different vendor specific implementations