1 / 16

Presentation 23: Comparison of technologies

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Presentation 23:Comparison of technologies

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

  3. 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?

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

  5. 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

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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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!

  14. 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

  15. 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!

  16. 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

More Related