Presentation 23: Comparison of technologies

1. Presentation 23:Comparison of technologies

2. Goals of this lesson • After this 1x35 lessons you will have • Discussed the different Middleware technologies • And be in a position to better decide when to use which technology • For the final exams – you should be able to differentiate between Java RMI, SOAP, CORBA & .NET Remoting. DCOM is not curriculum, but may be considered

3. Outline • Discussion in plenum • Pro’s and Con’s of each Middleware technology • When to use which? • Important that you form your own opinion • Do NOT use mine • After discussion • Articles of interest (feel free to supplement) • Findings • Pro’s and Con’s • 7 scenarios – when to use?

4. Articles of interest • The following articles could be of interest to you: • 1) Java RMI & CORBA A comparison of two competing technologies • http://www.javacoffeebreak.com/articles/rmi_corba/ • 2) Distributed object alternatives: DCOM and RMI • http://www.javaworld.com/javaworld/jw-10-1997/jw-10-corbajava.html#sidebar1 • 3) Web Services/SOAP and CORBA (critic of SOAP) • http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html • 4) .NET from the Enterprise Perspective: SOAP • http://java.oreilly.com/news/soap_0900.html • 5) Comparision of CORBA and Java RMI Based on Performance Analysis: • http://lisa.uni-mb.si/~juric/CompCorbaRmi.pdf • To supplement the course booklet (vol. 1 + 2)

5. Pro’s Portable across many platforms (heterogen) [1] Requieres only Java skills – no need to learn IDL’s (uses the build-in java interfaces) No need for buying and installing an ORB – uses the JDK Can introduce new code to foreign JVMs (Class Loading) [1] Regarded as ”easier to learn” than CORBA -> ”CORBA light” Performance on pure Java systems is comparable to CORBA systems [5] Distributed Garbage Collection [6] Some services Naming, activation Con’s Tied only to platforms with Java support [1] (but: RMI over IIOP and JNI) Security threats with remote code execution, and limitations on functionality enforced by security restrictions [1] Learning curve for developers that have no RMI experience is comparable with CORBA [1] Can only operate with Java systems - no support for legacy systems written in C++, Ada, Fortran, Cobol, and others (including future languages) [1] Does not implement many services and facilities as do CORBA – need to use EJB or other frameworks [6] Pro’s and Con’s of Java RMI

6. Pro’s With IDL, the interface is clearly separated from implementation, and developers can create different implementations based on the same interface. [1] Widespread support for heterogenous systems – platform and programming languages [Emmerich] Implements many services and facilities – that other technologies do not have (e.g. Java RMI, SOAP do not) Persistence, transactions, security, naming, activation etc CORBA supports primitive data types, and a wide range of data structures, as parameters [1] CORBA is ideally suited to use with legacy systems, and to ensure that applications written now will be accessible in the future. [1] CORBA is an easy way to link objects and systems together [1] Dynamic Invocation possible [6] Con’s Describing services require the use of an interface definition language (IDL) which must be learned. Implementing or using services require an IDL mapping to your required language - writing one for a language that isn't supported would take a large amount of work. [1] Need to ”buy” (open source is availlable), and install an ORB IDL to language mapping tools create code stubs based on the interface - some tools may not integrate new changes with existing code [1]. CORBA does not support the transfer of objects, or code. [1] The future is uncertain - if CORBA fails to achieve sufficient adoption by industry, then CORBA implementations become the legacy systems. [1] Some training is still required, and CORBA specifications are still in a state of flux. [1] CORBA Services and facilities are hard to learn, thus diminishing the advantages here Often rather large footprint – though scaled down versions do exsit (footprints belov 90 KB) Pro’s and Con’s of CORBA

7. Pro’s ”Hype” technology – all great vendors support SOAP, including Microsoft, SUN, IBM, Oracle, HP … [3] Widespread support for heterogenous systems – platform and programming languages Widespread tool support [3] XML easy to interpret Easy to use with some systems and tools (Microsoft extremely easy) [3] Developers ”believe” it is easy to use – as opposed to CORBA Relativly ”small footprint” – WingFoot API for J2ME – 32 KB Simpel communication model – using HTTP port 80 Same receipt for success as HTML and HTTP on the WWW Con’s Maybe the ”hype” will wear of [1], [3], [6] Very slow – everything needs to be parsed [3] – use of XML results in huge overhead Use of XML far off from programming languages [3] As Java RMI, SOAP and Web services are much less rich on features than CORBA – need to roll your own servcies – or use others SOAP is a ”young” technology year 2000 Problems with port 80 – security risks [3] Not always the best technology wins (as with HTML) Pro’s and Con’s of SOAP

8. Pro’s Pure Microsoft technology – good choice for companys dealing only in a Windows world[6] Absolutly free [2] DCOM supports multiple (heterogenous) programming languages – supported by C++, Visual Basic, Delphi etc [6] Many services as in CORBA Persistence, transactions, security, naming, activation etc. Dynamic Invocation of objects (as in COBRA) [6] Automatic garbage collection (pinging) [6] Con’s Pure Microsoft technology – bad choice for companys dealing not only in a Windows world[6] Runs only on a Windows platform – attempts on migrating to other platforms not successful [6] Low support of DCOM in industry – no hype [2] Consider hard to learn by many Component oriented – not object oriented Pro’s and Con’s of DCOM

9. 7 scenarios • In the following I present 7 scenarios • It is up to you to decide which technology to use – and we may debate it during the presentation

10. Scenario 1 • Server program to be written in Java and run on UNIX servers • Clients to run on primarely Windows machines – written in C++ • Clients communicate via LAN internally in the company • Which technology? • CORBA seems the most appropriate • SOAP could be considered – BUT IS LIGHTWEIGHT COMPARED TO CORBA

11. Scenario 2 • Need for exposing a few data from an exsisting legacy application running on a UNIX platform which was written in Java • Data is to be delivered to several client programs running on different operating systems: Mac, Windows and Linux, and written in different programming languages – using uncontrolled firewalls in different locations • Many different small software companies are the targets, skills unknown • Which technology? • SOAP seems the most appropriate • CORBA could be considered

12. Scenario 3 • A system is being designed: • Server: Java program running on a UNIX server • Client: Java program running on Windows and LINUX • Client option: possible client J2ME on mobile phones • Which technology? • Java RMI seems the most appropriate • Support for RMI on J2ME not fully implemented • CORBA is possible – opening up for other clients • No CORBA support on J2ME yet • SOAP support for J2ME – kSOAP and WingFoot … • Would support other types of client in the future

13. Scenario 4 • A system is being designed: • Server running on a LINUX platform – Java language • Client – Windows XP PC written in C++ • Client – Windows CE Smartphone edition (C++) • Client – Symbian J2ME mobile phone • Client – LIAB (Linux in a Box) – optional • Problem: communicating via GSM – high latency • Which technology: • Maybe CORBA sounds best, but SOAP is the only supported by the Symbian J2ME (WingFoot, kSOAP) • SOAP Works on the .NET CF for SmartPhone!

14. Scenario 5 • A system is being designed: • Server running Windows 2000 written in C++ • Implementing accounting, employee records, planning scedules etc. • Planned clients include: • An accounting program written in Delphi • A phonebook program written in ASP.NET (VB Script) • An employee update & planning program written in C# • Which technology? • COM is obvious for the pure Microsoft platform • CORBA is possible • SOAP is possible

15. Scenario 6 • A small company has just made a killer application offering other developers access to: • Searching the Web • Sending and recieving mails and SMS messages • All for free – using sponsporship as a sole income • They want other companys to incoporate the functions they have into their own programs – and devices • All kinds of technologies possible here!!! • Which technology? • SOAP is obviously suited for this. Every small company can integrate, and no trouble with firewalls!

16. Scenario 7 • A company has just made a networked temperature surveillance unit. Main core is a microprocessor with a socket and HTTP stack – and 16 KB of available memory • The unit is to plug-in into any conceivable type of data-collection system – amongst others ethernet-based PC-servers • First customer is using an existing CORBA-based PC server for management • What advice on middleware would you give them? • simple socket programming, TCP/UD, seems appropriate – no room for middleware, no need for middleware