presentation 23 comparison of technologies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Presentation 23: Comparison of technologies PowerPoint Presentation
Download Presentation
Presentation 23: Comparison of technologies

Loading in 2 Seconds...

play fullscreen
1 / 16

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

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' - kerry-daniel

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
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
    • 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
  • 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
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:
  • To supplement the course booklet (vol. 1 + 2)
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
7 scenarios
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
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 companies 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!
scenario 7
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