Presentation 23 comparison of technologies
1 / 15

Presentation 23: Comparison of technologies - PowerPoint PPT Presentation

  • Uploaded on

Presentation 23: Comparison of technologies. 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. Outline. Discussion in plenum

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Presentation 23: Comparison of technologies' - randi

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Presentation 23 comparison of technologies

Presentation 23:Comparison of technologies

Goals of this lesson
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


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

Articles of interest
Articles of interest

  • The following articles could be of interest to you:

    • 1) Java RMI & CORBA A comparison of two competing technologies


    • 2) Distributed object alternatives: DCOM and RMI


    • 3) Web Services/SOAP and CORBA (critic of SOAP)


    • 4) .NET from the Enterprise Perspective: SOAP


    • 5) Comparision of CORBA and Java RMI Based on Performance Analysis:


    • 6) A Comparison of Distributed Object Technologies


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

Pro s and con s of java rmi


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


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

Pro s and con s of corba


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]


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

Pro s and con s of soap


”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


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

Pro s and con s of dcom


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]


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

6 scenarios
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

Scenario 1
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


Scenario 2
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

Scenario 3
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
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
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
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!