G53ELC JAVA & .NET (BC vs. IL)
Microsoft .NET Framework Vs. Java G53ELC  The Common Language Infrastructure CLI and Microsoft .NET Framework languages like C# and VB share various similarities with Sun Microsystems’s JVM and Java.  These are virtual machine models which conceal the computer hardware details on which their programs run. The other similarity is that both of these frameworks make use of their own intermediate byte-code.  Microsoft naming theirs Common Intermediate Language and Sun naming theirs as Java bytecode.
Java and C#.NET G53ELC hello.java hello.cs javac csc hello.class hello.exe 9E8E 9E8E Java bytecode Common Intermediate Language (CIL) > java hello > hello.exe assembly these run in different virtual machines
Common Intermediate Language G53ELC  Common Intermediate Language formerly called MSIL is the lowest-level human-readable programming language defined by the Common Language Infrastructure (CLI) specification and is used by the .NET Framework and Mono.  Languages which target a CLI-compatible runtime environment compile to CIL, which is assembled into an object code that has a bytecode-style format.  CIL is an object-oriented assembly language, and is entirely stack-based. Its bytecode is translated into native code or executed by a virtual machine.
Bytecode G53ELC  Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter.  Bytecodes are compact numeric codes, constants, and references which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects.  They therefore allow much better performance than direct interpretation of source code.
Java Byte Code and MSIL  Java byte code (or JVML) is the low-level languageG53ELC of the JVM.  MSIL (or CIL or IL) is the low-level language of the .NET Common Language Runtime (CLR).  Superficially, the two languages look very similar. MSIL: JVML: iload 1 ldloc.1 iload 2 ldloc.2 iadd add istore 3 stloc.3
Cont.. G53ELC  One difference is that MSIL is designed only for JIT compilation.  The generic add instruction would require an interpreter to track the data type of the top of stack element, which would be prohibitively expensive.
Bytecode & MSIL contains… G53ELC  Load and store  Arithmetic and logic  Type conversion  Object creation and manipulation  Operand stack management  Control transfer  Method invocation and return
The execution engines G53ELC  The Bytecode and MSIL is interpreted by virtual machines…  JVM for Java Bytecode  CLR for MSIL
Java virtual machine (JVM) G53ELC  A Java virtual machine is software that is implemented on virtual and non-virtual hardware and on standard operating systems.  A JVM provides an environment in which Java bytecode can be executed, enabling such features as automated exception handling,
Java Run-Time System G53ELC Just-in- time Compiler Byte Class Hardware Code Loader Verifier Java Interpreter Runtime
JVM Architecture G53ELC
A Bytecode Example public class X { public static void G53ELC main(java.lang.String[]); public static void Code: main(String[] args) { 0: iconst_1 add(1, 2); 1: iconst_2 } //Method add:(II)I 2: invokestatic #2; 5: pop public static int 6: return add(int a, int b) { return a+b; public static int add(int,int); } Code: } 0: iload_0 1: iload_1 2: iadd 3: ireturn
Common Language Runtime G53ELC  CLR sits on top of OS to provide a virtual environment for hosting managed applications  What is CLR similar to in Java?  Java Virtual Machine (JVM)  CLR loads modules containing executable and executes their code
G53ELC  Code might be managed or unmanaged  In either case the CLR determines what to do with it  Managed Code consists of instructions written in a pseudo-machine language called common intermediate language, or IL.  IL instructions are just-in-time (JIT) compiled into native machine code at run time
Compiling and executing managed code G53ELC Compilation Microsoft Source Language Intermediate Code Compiler Language (MSIL) The first time each method is called Native JIT Code Compiler Execution
Common Language Runtime G53ELC
G53ELC
Architecture G53ELC
Programming model G53ELC CIL & Source Compiler Metadata Code Common Language Runtime Class Class Loader Execution Engine Lib JIT Compiler Managed Execution native Code
C# Code  using System; G53ELC namespace Swapping { class Swap { int a, b, c; public void Get() { Console.WriteLine("Enter 2 no"); this.a = Convert.ToInt32(Console.ReadLine()); this.b = Convert.ToInt32(Console.ReadLine()); } public void Show() { this.c = this.a; this.a = this.b; this.b = this.c; Console.WriteLine("After Swapping a={0} b={1}", this.a, this.b); } } }
G53ELC
G53ELC
G53ELC
CLR vs JVM G53ELC VB Managed Lots of other C# .Net C/C++ Languages Java MSIL Byte Codes CLR JRE (JVM) CTS GC Security GC Security Runtime Services Runtime Services Windows OS Mac Win Unix Linux Both are „middle layers‟ between an intermediate language & the underlying OS 25
JVM vs. CLR  JVM designed for platform independence G53ELC  Single language: Java (?)  A separate JVM for each OS & device  CLR designed for language independence  Multiple languages for development  C++, VB, C#, (J#)  APL, COBOL, Eiffel, Forth, Fortran, Haskel, SML, Mercury, Mondrian, Oberon, Pascal, Perl, Python, RPG, Scheme, SmallScript, … 26
G53ELC  Impressive usage of formal methods and programming language research during development  Impressive extensions for generics and support for functional languages underway  Underlying OS: Windows (?)
JVM vs. CLR at a glance G53ELC JVM CLR Managed execution X X environment Garbage Collection X X Metadata and Byte code X X Platform-abstraction class X X library Runtime-level security X X Runs across hardware X ? platforms 28
A typical .NET Enterprise Solution G53ELC IIS on W2k Server Browser .NET SQL ASP managed Server .NET component Windows Client 29
A typical J2EE Enterprise Solution G53ELC Java App Server DB Browser Servlet Server EJB JSP Java Client 30
Web services G53ELC  Web services are typically application programming interfaces (API) or Web APIs that are accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system hosting the requested services.  An application that exists in a distributed environment, such as the Internet.  A Web service accepts a request, performs its function based on the request, and returns a response.
Advantages of Web service G53ELC  Not based on a programming language: Java, .Net, C, C++, Python, Perl, …  Not based on a programming data model: objects vs non-objects environments.  Based on web technologies  Do not need huge framework of memory.  Basic usage is b-to-b ,remote controlled devices ,etc.
Web services application G53ELC Can use Web Services to integrate across departments, agencies, to companies, etc.
Web service Architecture G53ELC An architecture view based on SOAP, WSDL, and UDDI.
WS built on existing standards G53ELC  Extensible Markup Language (XML)  The HTTP (Hypertext Transfer Protocol) standard is allowing more systems to communicate with one another.  SOAP (Simple Object Access Protocol) (built on XML) standardizes the messaging capability on different systems.  UDDI (Universal Description,Discovery, and Integration ) standardizes the publishing and finding of Web services.  WSDL (Web Services Description Language ) standardizes the description of Web services so providers and requesters are speaking the same language.
Web Services technology 3 major Web services toolkits being used widely, G53ELC  .NET Web services: Developed by Microsoft and is an integral part of the complete .NET framework. Integrated and easy to use with Visual Studio .NET. services are hosted on IIS web servers.  Java Web services: Sun’s Web service implementation for the Java community. Comes bundled in a complete Java Web services Development Pack (JWSDP Ver 1.3) including Tomcat web server.  Apache Axis: Initially developed by IBM and donated to the Apache group. One of the earliest and stable Web service implementation. Runs on Apache Web servers.
A Web Service example in Java G53ELC HTTP Server Servlet engine (e.g. Apache Tomcat) Any class Any class processing Any class processing Any class the incoming processing the incoming processing SOAP-aware Sending requests the incoming requests requests, (“businessincoming the logic” requests Servlet (“business logic” requests (e.g. Apache Axis) getting (“business logic” (“business logic” results
Usual principles of Java toolkits  Writing server is easier than writing clients (butG53ELC only regarding the toolkit, not the business logic)  Servers may be written independently on the used toolkit  Always test interoperability with a non-Java client (because of data serialization and de-serialization)  Steps:  write your service implementation  make all your classes available to the toolkit  deploy your service (usually done just once)  restart the whole servlet engine  test it with a client request
hello/HelloWorld.java package hello; G53ELC public interface HelloWorld { String getHelloMessage(); void setHelloMessage (String newHello); } hello/HelloWorldService.java package hello; public class HelloWorldService implements HelloWorld { String message = "Hello, world!"; public String getHelloMessage() { return message; } public void setHelloMessage (String newMessage) { message = newMessage; } }
import org.apache.axis.client.*; HelloWorldClient.java public class HelloWorldClient { public static void main (String [] args) { try { G53ELC // prepare the call (the same for all called methods) Call call = (Call) new Service().createCall(); call.setTargetEndpointAddress (new java.net.URL("http://localhost:8080/axis/services/Hello")); // call "get message" if (args.length == 0) { call.setOperationName ("getHelloMessage"); String result = (String) call.invoke ( new Object [] {} ); System.out.println (result); System.exit (0); } // call "set message" and afterwards "get message" call.setMaintainSession (true); // TRY also without this line... call.setOperationName ("setHelloMessage"); call.invoke ( new Object [] { args[0] } ); call.setOperationName ("getHelloMessage"); System.out.println (call.invoke ( new Object [] {} )); } catch (Exception e) { System.err.println ("ERROR:n" + e.toString()); } }
Generated for HelloWorld 1. Make an instance of this G53ELC HelloWorldService implements 2. Use it to make an instance of this HelloWorldServiceLocator getHello() HelloWorld 3. Call methods on this proxy object implements HelloSoapBindingStub
HelloWorldClientFromStubs.java public class HelloWorldClientFromStubs { G53ELC public static void main (String [] args) { try { // prepare the calls (the same for all called methods) hello.generated.HelloWorldService service = new hello.generated.HelloWorldServiceLocator(); hello.generated.HelloWorld myHelloProxy = service.getHello(); // call "get message" if (args.length == 0) { String result = myHelloProxy.getHelloMessage() System.out.println (result); System.exit (0); } // call "set message" and afterwards "get message” myHelloProxy.setHelloMessage (args[0]); System.out.println (myHelloProxy.getHelloMessage()); } catch (Exception e) { System.err.println ("ERROR:n" + e.toString()); } } }
Java vs .Net Solutions G53ELC  Both multi-tiered, similar computing technologies  Both support “standards”  Both offer different tools & ways to achieve the same goal.  A lot of parallelism can be seen. 43
G53ELC Java .Net
.NET vs. Java: standard libraries G53ELC  .NET Framework class library  Defined by Microsoft  Somewhat Windows-oriented  Organized into a hierarchy of namespaces  J2SE, J2EE  Defined by Sun and the Java Community Process  Not bound to any operating system  Defined as packages and interfaces
Class Libraries G53ELC
The TMC Petshop Performance Case Study G53ELC  Java Pet Store is Sun’s primary blueprint application for J2EE  Source: http://java.sun.com/j2ee/blueprints  Illustrates best coding practices for J2EE  Ships as a sample application in IBM Websphere, Oracle Application Server 9i, Sun iPlanet, and BEA WebLogic 47
 The .NET Petshop is a port of the J2EE Java Pet Store to G53ELC .NET  Source: http://www.gotdotnet.com/compare  Implements the same functionality as Java Pet Store  Illustrates best coding practices for .NET Framework  In the TMC Petshop Performance Case Study, The Middleware Company implemented both the Java Pet Store and the .Net Petshop.  The J2EE version ran on two different application servers  All versions used the same hardware and OS
Java Pet Store Components  The Storefront presents the main user interfaceG53ELC in a Web front-end. Customers use the Storefront to place orders for pets.  The Order Processing Center (OPC) receives orders from the Storefront.  The Supplier fulfills orders from the OPC from inventory and invoices the OPC.  The Admin presents the administrator interface in a JFC/Swing front-end. Administrators use the Admin to examine pending orders and approve or deny them. 49
Java Pet Store vs. .Net Pet Shop G53ELC 50
Porting Java Pet Store to .NET 15500 14,273 Lines of Code Required G53ELC 14000 .NET Petshop 11500 Java Pet Store 9000 7500 5,891 5,404 4,410 5000 2,865 2,566 2500 710 761 412 74 Total Lines User Middle Tier Data Tier Configuration of Code Interface 51
TMC Pages per Second G53ELC 52
TMC Max Supported Users G53ELC 53
G53ELC
A Comparison .NET or J2EE? G53ELC  Which is best?  In what way?  For what purpose?  Performance  Cost  Developer time
Application Platforms Today G53ELC Browser Web Services Local Other Apps Apps Apps Apps GUI Transaction Web Data More Services Services Scripting Access Standard Library Runtime Environment Operating System
The .NET Framework G53ELC Browser Web Services Local Other Apps Apps Apps Apps Windows Enterprise ASP.NET ADO.NET More Forms Services .NET Framework Class Library Common Language Runtime Windows
The Competition- The Java Environment G53ELC Browser Web Services Local Other Apps Apps Apps Apps Swing Enterprise JavaServer JDBC More JavaBeans Pages Standard Java Packages Java Virtual Machine (VM) Windows, Solaris, Linux, others
But!  .NET IS COMPELLING! G53ELC  It has everything an enterprise architecture needs  It is fast  It is simpler to use than J2EE to develop  It has features that J2EE does not –  eg web forms  It is ahead of the game in my opinion
.Net Needs Less Code G53ELC
Runtime Statistics G53ELC  .NET ran 28 times faster that J2EE  Supported 7.6 times more concurrent users  Used ¼ the CPU cycles for the same load  Do not believe these statistics!  Picked to show MS in best possible light  But it .NET is probably more efficient
Reference G53ELC  Unix Internal- Urash Vahalia  Operating Systems-William Stallings
G53ELC 63

Java vs .net

  • 1.
    G53ELC JAVA & .NET(BC vs. IL)
  • 2.
    Microsoft .NET FrameworkVs. Java G53ELC  The Common Language Infrastructure CLI and Microsoft .NET Framework languages like C# and VB share various similarities with Sun Microsystems’s JVM and Java.  These are virtual machine models which conceal the computer hardware details on which their programs run. The other similarity is that both of these frameworks make use of their own intermediate byte-code.  Microsoft naming theirs Common Intermediate Language and Sun naming theirs as Java bytecode.
  • 3.
    Java and C#.NET G53ELC hello.java hello.cs javac csc hello.class hello.exe 9E8E 9E8E Java bytecode Common Intermediate Language (CIL) > java hello > hello.exe assembly these run in different virtual machines
  • 4.
    Common Intermediate Language G53ELC  Common Intermediate Language formerly called MSIL is the lowest-level human-readable programming language defined by the Common Language Infrastructure (CLI) specification and is used by the .NET Framework and Mono.  Languages which target a CLI-compatible runtime environment compile to CIL, which is assembled into an object code that has a bytecode-style format.  CIL is an object-oriented assembly language, and is entirely stack-based. Its bytecode is translated into native code or executed by a virtual machine.
  • 5.
    Bytecode G53ELC  Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter.  Bytecodes are compact numeric codes, constants, and references which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects.  They therefore allow much better performance than direct interpretation of source code.
  • 6.
    Java Byte Codeand MSIL  Java byte code (or JVML) is the low-level languageG53ELC of the JVM.  MSIL (or CIL or IL) is the low-level language of the .NET Common Language Runtime (CLR).  Superficially, the two languages look very similar. MSIL: JVML: iload 1 ldloc.1 iload 2 ldloc.2 iadd add istore 3 stloc.3
  • 7.
    Cont.. G53ELC  One difference is that MSIL is designed only for JIT compilation.  The generic add instruction would require an interpreter to track the data type of the top of stack element, which would be prohibitively expensive.
  • 8.
    Bytecode & MSILcontains… G53ELC  Load and store  Arithmetic and logic  Type conversion  Object creation and manipulation  Operand stack management  Control transfer  Method invocation and return
  • 9.
    The execution engines G53ELC  The Bytecode and MSIL is interpreted by virtual machines…  JVM for Java Bytecode  CLR for MSIL
  • 10.
    Java virtual machine(JVM) G53ELC  A Java virtual machine is software that is implemented on virtual and non-virtual hardware and on standard operating systems.  A JVM provides an environment in which Java bytecode can be executed, enabling such features as automated exception handling,
  • 11.
    Java Run-Time System G53ELC Just-in- time Compiler Byte Class Hardware Code Loader Verifier Java Interpreter Runtime
  • 12.
  • 13.
    A Bytecode Example publicclass X { public static void G53ELC main(java.lang.String[]); public static void Code: main(String[] args) { 0: iconst_1 add(1, 2); 1: iconst_2 } //Method add:(II)I 2: invokestatic #2; 5: pop public static int 6: return add(int a, int b) { return a+b; public static int add(int,int); } Code: } 0: iload_0 1: iload_1 2: iadd 3: ireturn
  • 14.
    Common Language Runtime G53ELC  CLR sits on top of OS to provide a virtual environment for hosting managed applications  What is CLR similar to in Java?  Java Virtual Machine (JVM)  CLR loads modules containing executable and executes their code
  • 15.
    G53ELC  Code mightbe managed or unmanaged  In either case the CLR determines what to do with it  Managed Code consists of instructions written in a pseudo-machine language called common intermediate language, or IL.  IL instructions are just-in-time (JIT) compiled into native machine code at run time
  • 16.
    Compiling and executing managed code G53ELC Compilation Microsoft Source Language Intermediate Code Compiler Language (MSIL) The first time each method is called Native JIT Code Compiler Execution
  • 17.
  • 18.
  • 19.
  • 20.
    Programming model G53ELC CIL & Source Compiler Metadata Code Common Language Runtime Class Class Loader Execution Engine Lib JIT Compiler Managed Execution native Code
  • 21.
    C# Code  using System; G53ELC namespace Swapping { class Swap { int a, b, c; public void Get() { Console.WriteLine("Enter 2 no"); this.a = Convert.ToInt32(Console.ReadLine()); this.b = Convert.ToInt32(Console.ReadLine()); } public void Show() { this.c = this.a; this.a = this.b; this.b = this.c; Console.WriteLine("After Swapping a={0} b={1}", this.a, this.b); } } }
  • 22.
  • 23.
  • 24.
  • 25.
    CLR vs JVM G53ELC VB Managed Lots of other C# .Net C/C++ Languages Java MSIL Byte Codes CLR JRE (JVM) CTS GC Security GC Security Runtime Services Runtime Services Windows OS Mac Win Unix Linux Both are „middle layers‟ between an intermediate language & the underlying OS 25
  • 26.
    JVM vs. CLR  JVM designed for platform independence G53ELC  Single language: Java (?)  A separate JVM for each OS & device  CLR designed for language independence  Multiple languages for development  C++, VB, C#, (J#)  APL, COBOL, Eiffel, Forth, Fortran, Haskel, SML, Mercury, Mondrian, Oberon, Pascal, Perl, Python, RPG, Scheme, SmallScript, … 26
  • 27.
    G53ELC  Impressive usage of formal methods and programming language research during development  Impressive extensions for generics and support for functional languages underway  Underlying OS: Windows (?)
  • 28.
    JVM vs. CLRat a glance G53ELC JVM CLR Managed execution X X environment Garbage Collection X X Metadata and Byte code X X Platform-abstraction class X X library Runtime-level security X X Runs across hardware X ? platforms 28
  • 29.
    A typical .NET Enterprise Solution G53ELC IIS on W2k Server Browser .NET SQL ASP managed Server .NET component Windows Client 29
  • 30.
    A typical J2EE Enterprise Solution G53ELC Java App Server DB Browser Servlet Server EJB JSP Java Client 30
  • 31.
    Web services G53ELC  Web services are typically application programming interfaces (API) or Web APIs that are accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system hosting the requested services.  An application that exists in a distributed environment, such as the Internet.  A Web service accepts a request, performs its function based on the request, and returns a response.
  • 32.
    Advantages of Webservice G53ELC  Not based on a programming language: Java, .Net, C, C++, Python, Perl, …  Not based on a programming data model: objects vs non-objects environments.  Based on web technologies  Do not need huge framework of memory.  Basic usage is b-to-b ,remote controlled devices ,etc.
  • 33.
    Web services application G53ELC Can use Web Services to integrate across departments, agencies, to companies, etc.
  • 34.
    Web service Architecture G53ELC An architecture view based on SOAP, WSDL, and UDDI.
  • 35.
    WS built onexisting standards G53ELC  Extensible Markup Language (XML)  The HTTP (Hypertext Transfer Protocol) standard is allowing more systems to communicate with one another.  SOAP (Simple Object Access Protocol) (built on XML) standardizes the messaging capability on different systems.  UDDI (Universal Description,Discovery, and Integration ) standardizes the publishing and finding of Web services.  WSDL (Web Services Description Language ) standardizes the description of Web services so providers and requesters are speaking the same language.
  • 36.
    Web Services technology 3major Web services toolkits being used widely, G53ELC  .NET Web services: Developed by Microsoft and is an integral part of the complete .NET framework. Integrated and easy to use with Visual Studio .NET. services are hosted on IIS web servers.  Java Web services: Sun’s Web service implementation for the Java community. Comes bundled in a complete Java Web services Development Pack (JWSDP Ver 1.3) including Tomcat web server.  Apache Axis: Initially developed by IBM and donated to the Apache group. One of the earliest and stable Web service implementation. Runs on Apache Web servers.
  • 37.
    A Web Serviceexample in Java G53ELC HTTP Server Servlet engine (e.g. Apache Tomcat) Any class Any class processing Any class processing Any class the incoming processing the incoming processing SOAP-aware Sending requests the incoming requests requests, (“businessincoming the logic” requests Servlet (“business logic” requests (e.g. Apache Axis) getting (“business logic” (“business logic” results
  • 38.
    Usual principles ofJava toolkits  Writing server is easier than writing clients (butG53ELC only regarding the toolkit, not the business logic)  Servers may be written independently on the used toolkit  Always test interoperability with a non-Java client (because of data serialization and de-serialization)  Steps:  write your service implementation  make all your classes available to the toolkit  deploy your service (usually done just once)  restart the whole servlet engine  test it with a client request
  • 39.
    hello/HelloWorld.java package hello; G53ELC public interface HelloWorld { String getHelloMessage(); void setHelloMessage (String newHello); } hello/HelloWorldService.java package hello; public class HelloWorldService implements HelloWorld { String message = "Hello, world!"; public String getHelloMessage() { return message; } public void setHelloMessage (String newMessage) { message = newMessage; } }
  • 40.
    import org.apache.axis.client.*; HelloWorldClient.java public class HelloWorldClient { public static void main (String [] args) { try { G53ELC // prepare the call (the same for all called methods) Call call = (Call) new Service().createCall(); call.setTargetEndpointAddress (new java.net.URL("http://localhost:8080/axis/services/Hello")); // call "get message" if (args.length == 0) { call.setOperationName ("getHelloMessage"); String result = (String) call.invoke ( new Object [] {} ); System.out.println (result); System.exit (0); } // call "set message" and afterwards "get message" call.setMaintainSession (true); // TRY also without this line... call.setOperationName ("setHelloMessage"); call.invoke ( new Object [] { args[0] } ); call.setOperationName ("getHelloMessage"); System.out.println (call.invoke ( new Object [] {} )); } catch (Exception e) { System.err.println ("ERROR:n" + e.toString()); } }
  • 41.
    Generated for HelloWorld 1. Make an instance of this G53ELC HelloWorldService implements 2. Use it to make an instance of this HelloWorldServiceLocator getHello() HelloWorld 3. Call methods on this proxy object implements HelloSoapBindingStub
  • 42.
    HelloWorldClientFromStubs.java public class HelloWorldClientFromStubs{ G53ELC public static void main (String [] args) { try { // prepare the calls (the same for all called methods) hello.generated.HelloWorldService service = new hello.generated.HelloWorldServiceLocator(); hello.generated.HelloWorld myHelloProxy = service.getHello(); // call "get message" if (args.length == 0) { String result = myHelloProxy.getHelloMessage() System.out.println (result); System.exit (0); } // call "set message" and afterwards "get message” myHelloProxy.setHelloMessage (args[0]); System.out.println (myHelloProxy.getHelloMessage()); } catch (Exception e) { System.err.println ("ERROR:n" + e.toString()); } } }
  • 43.
    Java vs .NetSolutions G53ELC  Both multi-tiered, similar computing technologies  Both support “standards”  Both offer different tools & ways to achieve the same goal.  A lot of parallelism can be seen. 43
  • 44.
  • 45.
    .NET vs. Java: standard libraries G53ELC  .NET Framework class library  Defined by Microsoft  Somewhat Windows-oriented  Organized into a hierarchy of namespaces  J2SE, J2EE  Defined by Sun and the Java Community Process  Not bound to any operating system  Defined as packages and interfaces
  • 46.
  • 47.
    The TMC Petshop Performance Case Study G53ELC  Java Pet Store is Sun’s primary blueprint application for J2EE  Source: http://java.sun.com/j2ee/blueprints  Illustrates best coding practices for J2EE  Ships as a sample application in IBM Websphere, Oracle Application Server 9i, Sun iPlanet, and BEA WebLogic 47
  • 48.
    The .NET Petshop is a port of the J2EE Java Pet Store to G53ELC .NET  Source: http://www.gotdotnet.com/compare  Implements the same functionality as Java Pet Store  Illustrates best coding practices for .NET Framework  In the TMC Petshop Performance Case Study, The Middleware Company implemented both the Java Pet Store and the .Net Petshop.  The J2EE version ran on two different application servers  All versions used the same hardware and OS
  • 49.
    Java Pet StoreComponents  The Storefront presents the main user interfaceG53ELC in a Web front-end. Customers use the Storefront to place orders for pets.  The Order Processing Center (OPC) receives orders from the Storefront.  The Supplier fulfills orders from the OPC from inventory and invoices the OPC.  The Admin presents the administrator interface in a JFC/Swing front-end. Administrators use the Admin to examine pending orders and approve or deny them. 49
  • 50.
    Java Pet Storevs. .Net Pet Shop G53ELC 50
  • 51.
    Porting Java PetStore to .NET 15500 14,273 Lines of Code Required G53ELC 14000 .NET Petshop 11500 Java Pet Store 9000 7500 5,891 5,404 4,410 5000 2,865 2,566 2500 710 761 412 74 Total Lines User Middle Tier Data Tier Configuration of Code Interface 51
  • 52.
    TMC Pages perSecond G53ELC 52
  • 53.
    TMC Max SupportedUsers G53ELC 53
  • 54.
  • 55.
    A Comparison .NETor J2EE? G53ELC  Which is best?  In what way?  For what purpose?  Performance  Cost  Developer time
  • 56.
    Application Platforms Today G53ELC Browser Web Services Local Other Apps Apps Apps Apps GUI Transaction Web Data More Services Services Scripting Access Standard Library Runtime Environment Operating System
  • 57.
    The .NET Framework G53ELC Browser Web Services Local Other Apps Apps Apps Apps Windows Enterprise ASP.NET ADO.NET More Forms Services .NET Framework Class Library Common Language Runtime Windows
  • 58.
    The Competition- The Java Environment G53ELC Browser Web Services Local Other Apps Apps Apps Apps Swing Enterprise JavaServer JDBC More JavaBeans Pages Standard Java Packages Java Virtual Machine (VM) Windows, Solaris, Linux, others
  • 59.
    But!  .NET IS COMPELLING! G53ELC  It has everything an enterprise architecture needs  It is fast  It is simpler to use than J2EE to develop  It has features that J2EE does not –  eg web forms  It is ahead of the game in my opinion
  • 60.
    .Net Needs LessCode G53ELC
  • 61.
    Runtime Statistics G53ELC  .NET ran 28 times faster that J2EE  Supported 7.6 times more concurrent users  Used ¼ the CPU cycles for the same load  Do not believe these statistics!  Picked to show MS in best possible light  But it .NET is probably more efficient
  • 62.
    Reference G53ELC  Unix Internal- Urash Vahalia  Operating Systems-William Stallings
  • 63.