Presentation 23 comparison of technologies
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

Presentation 23: Comparison of technologies PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Presentation 23: Comparison of technologies

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


Outline

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?


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

      • 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

    • 6) A Comparison of Distributed Object Technologies

      • http://www.idi.ntnu.no/~conradi/dif8901/essay2001-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!


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 Java RMI


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 CORBA


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 SOAP


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

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

    • SOAP could be considered – BUT IS LIGHTWEIGHT COMPARED TO CORBA


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!


  • Login