Presentation 23: Comparison of technologies. Ingeniørhøjskolen i Århus Slide 2 af 16 Goals of this lesson After this 1x35 lessons you will have –Discussed

Presentation 23:Comparison of technologies

Ingeniørhøjskolen i ÅrhusSlide 2 af 16

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


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?


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)


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 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 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)

• 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 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” –

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 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• 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


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


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


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


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


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!


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


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!


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

Documents

Presentation 23: Comparison of technologies. Ingeniørhøjskolen i Århus Slide 2 af 16 Goals of this lesson After this 1x35 lessons you will have –Discussed