Presentation 23 Comparison of technologies Goals of

Presentation 23: Comparison of technologies

Goals of this lesson • After this 1 x 35 lessons you will have – Discussed the different Middleware technologies – And be in a position to better decide when to use which technology Slide 2 af 15 Ingeniørhøjskolen i Århus

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 • 6 scenarios – when to use? Slide 3 af 15 Ingeniørhøjskolen i Århus

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#sidebar 1 – 3) Web Services/SOAP and CORBA (critic of SOAP) • http: //www. xs 4 all. 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/Comp. Corba. Rmi. pdf – 6) A Comparison of Distributed Object Technologies • http: //www. idi. ntnu. no/~conradi/dif 8901/essay 2001 -calle. doc • Read this article, at least – if you do not have time to read them all. This discusses all technologies • To supplement Emmerich and the articles you already recieved! Slide 4 af 15 Ingeniørhøjskolen i Århus

Pro’s and Con’s of Java RMI • • Pro’s – Portable across many platforms (heterogen) [1] – Requieres only Java skills – no need to learn IDL’s (uses the buildin 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 Slide 5 af 15 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] Ingeniørhøjskolen i Århus

Pro’s and Con’s of CORBA • • 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) • – – Con’s – – – 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] – – – Slide 6 af 15 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) Ingeniørhøjskolen i Århus

Pro’s and Con’s of SOAP • • 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” – Wing. Foot API for J 2 ME – 32 KB – Simpel communication model – using HTTP port 80 – Same receipt for success as HTML and HTTP on the WWW Slide 7 af 15 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) Ingeniørhøjskolen i Århus

Pro’s and Con’s of DCOM • 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 • Con’s • Persistence, transactions, security, naming, activation etc. – Dynamic Invocation of objects (as in COBRA) [6] – Automatic garbage collection (pinging) [6] Slide 8 af 15 – 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 Ingeniørhøjskolen i Århus

6 scenarios • In the following I present 6 scenarios • It is up to you to decide which technology to use – and we may debate it during the presentation Slide 9 af 15 Ingeniørhøjskolen i Århus

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 Slide 10 af 15 Ingeniørhøjskolen i Århus

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 companys are the targets, skills unknown • Which technology? – SOAP seems the most appropriate – CORBA could be considered Slide 11 af 15 Ingeniørhøjskolen i Århus

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 J 2 ME on mobile phones • Which technology? – Java RMI seems the most appropriate • Support for RMI on J 2 ME not fully implemented – CORBA is possible – opening up for other clients • No CORBA support on J 2 ME yet – SOAP support for J 2 ME – k. SOAP and Wing. Foot … • Would support other types of client in the future Slide 12 af 15 Ingeniørhøjskolen i Århus

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 J 2 ME 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 J 2 ME (Wing. Foot, k. SOAP) – SOAP Works on the. NET CF for Smart. Phone! Slide 13 af 15 Ingeniørhøjskolen i Århus

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 Slide 14 af 15 Ingeniørhøjskolen i Århus

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! Slide 15 af 15 Ingeniørhøjskolen i Århus