Your SlideShare is downloading. ×
DOCFIN.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

DOCFIN.ppt

404
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
404
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Enterprise Component Comparison: An Examination Of J2EE, CORBA, And .NET presented by Seth Freeman, Phil Griffith and Frank Manni Semester Project- Final Presentation CSE333 – Distributed Component Systems (FALL 2005) Instructor Prof. Steven A. Demurjian Department of Computer Science and Engineering University of Connecticut [email_address] [email_address] [email_address]
  • 2. Outline Of Presentation
    • Introduction
    • Project Description
    • CORBA Material
    • J2EE Material
    • .NET Material
    • Analysis
    • Conclusion
  • 3. Project Description
    • Compare and Contrast the 3 Technologies J2EE, .NET, and CORBA.
    • Evaluate the Three in These Four Areas:
      • Database Connectivity
      • Security
      • Web Services
      • Interoperability
    • GOAL: To Analyze Which Areas in J2EE or .NET is Better Suited to Be Used for Application Development. Also to Determine in Which Areas CORBA Can Be Beneficial.
  • 4. Project Scope
    • Database Connectivity
      • Determine Components Involved.
      • Examine the Underlying Functionality of Establishing a Connection to a Database.
      • In the End We Will Also Compare the Performance of J2EE and .NET in Updating and Querying a Real World Database .
    • Web Services
      • Analyze the Techniques to Develop and Deploy Web Services for the Three Technologies.
      • Observe the Ease of Use
      • Determine the Support of Each for Web Services.
  • 5. Project Scope
    • Security
      • The Goal Here is to Determine the Built-in Capabilities of Authorization, Authentication, and Encryption.
      • Then Analyze the Functionality of These Primitives Within the Framework.
    • Interoperability
      • The Final Part of the Project is to Investigate the Middleware Interoperability of .NET/J2EE and CORBA Components.
      • More Specifically the Focus Will Be on Remoting in .NET vs. RMI (J2EE).
      • And Also Observe How Components Interact With Heterogeneous Components.
  • 6. CORBA (In Brief) Common Object Request Broker Architecture
  • 7. CORBA DB
    • CORBA and Databases
  • 8. CORBA WS
    • Similar Functionality
    CORBA Cannot transport some types of documents easily, such as .pdf or .doc files. Supports various events, i.e. transaction, notification, security services. Does not directly support .NET. Readable Interface Descriptions. SOAP wsdl files are difficult to read through. Protocol(IIOP)does not easily transport over the internet. This limits the scope of where CORBA can be used. ORB must be present on all machines, or elaborate coding is required to workaround. Standard specification, which is Defined by the OMG. Data cannot be read by humans alone. Because it is in the correct/digital format. Data is in the correct format when it is received from the ORB. This saves time from having to parse XML. Disadvantages Advantages
  • 9. CORBA WS Web Services
    • WSDL files are not easy to read.
    • Slower performance—data needs to be parsed
    • No event services.
    • Can transport attachments without problems.
    • No standard specification.
    • Supported by IBM and Microsoft.
    • Difficult to encode polymorphism.
    • Supports .NET
    • Many competing SOAP standards.
    • Data is easy to read in XML format
    • Congestion at Port 80.
    • Ready-made to travel over the internet because it uses the http protocol.
    Disadvantages Advantages
  • 10. CORBA Security
    • Security Within CORBA
    • CORBA Gives Administrators, Developers, Etc the Ability to Add Security to the System.
    • Developed a Specification of What Makes a CORBA Application Secure.
    • CORBA, Being Distributed, Has More Areas That Are Vulnerable to Attacks, and Therefore Has More Areas That Need to Be Made Secure
    • Not Going to Go Over All of Them--Already Went Over Them in Class.
    • Focus on Security Service Protocol (SECP)—Communication Between Objects/Clients and the ORB
  • 11. CORBA Security
    • CORBA ORBs Communicate by Using the GIOP (General Inter-Orb Protocol). This Protocol Defines the Format of the Messages That Are Passed Over the ORB to and From the Client and Object. When GIOP Runs Over TCP/IP it is a Part of IIOP. SECP Will Be Another Layer Below the GIOP That Adds Security to Message Transportation.
    • SECP Will Transport GIOP Messages Security
    • SECP is Still in Progress. Its Status is “Approved.”
  • 12. CORBA Security Three Parts to SECP: 1) Circuit Establishment--Creating a Secure, Bidirectional Connection Between a Client and Target. 2) Context Establishment -- Allowing Both a Client and Target to Set up Security Contexts, and Based off the Specified Security Context of the Client and the Target, Certain Behaviors May Take Place. 3) Message Transport-- Final Phase of the SECP, and This Phase Securely Transports the Messages and Then Destroys the Contexts.
  • 13. CORBA Interoperability
    • CORBA’s Whole Focus Is Interoperability!
    • We All Know What Corba is Now, So We See How Using an IDL, We Can Create a Client in One Software Platform That Can Access a Target Object Through the ORB.
    • So, That’s it, Right? This Part is Done.
  • 14. CORBA Interoperability
    • Wrong! There Are Other Types of Interoperability.
    • What About From One ORB to Another ORB?
    • What About From One System That is CORBA Compliant to a Legacy System That isn’t CORBA Compliant?
    • What About Security Policies on a System? Sometime This System Can Be Accessed, Sometimes it Can’t Be.
    • So, There Are Also Implementational and Administrative Types of Interoperability.
    • How Can We Handle This?
  • 15. CORBA Interoperability
    • With a Specification, of Course!
    • CORBA Interoperability Architecture
    • CORBA Defines a Domain—Group of Objects That Do Not Communicate With Other Objects.
    • To Communicate Between Domains, There Must Be a Bridge.
    • Some Terms:
    • In-Line Bridging—All the Domains Are Within One ORB.
    • Request Level Bridging—Domains Are Not Within One ORB. (More Interesting Than In-Line Bridging)
    • DII—Dynamic Invocation Interface—Can Invoke Methods on Objects Without Knowing What the Target Interfaces Are at Compile Time.
    • DSI—Dynamic Skeleton Interface—Servers Don’t Know the Types of the Objects They Are Going to Access Ahead of Run Time.
  • 16. CORBA Interoperability
    • Request Level Bridging:
    • 1) The Client ORB Simulates That the Server ORB and the Bridge Are Actually Part of Its Own Object. The Client Requests This Object Using the Dynamic Skeletal Interface (DSI).
    • 2) The DSI, Using the Bridge, Translates the Requests.
    • 3) The DSI Invokes the Request Through DII of the Server. Any Results Are Passed Back.
    • Note: To Do This, the Bridge Must Have Access to the Interface Repository, or Have Pre-defined Knowledge of the Object Specifications. Also, the Standard Method for Transferring This Information is GIOP.
  • 17. J2EE Environment
    • N-tier architecture
    Client Side Web Application Servers: JSP, Servlets, HTML, XML Enterprise Information Server EJB Server, JNDI, JMS, JavaMail Middle Tiers RDBMS, ERP, Legacy Apps Source: Enterprise Java Security
  • 18. J2EE Enterprise Archive
    • J2EE Application code is contained within an Enterprise Archive (EAR) that consists of
      • EJB Module (JAR File)
      • Web Module (WAR File)
      • Application Client Module (JAR File)
      • Utilities
      • Deployment Descriptor File (XML document)
        • Specifies contents of EAR, deployment instructions, security settings to be enforced by runtime environment
        • Each WAR, JAR also contain deployment descriptor
      • Each module is run in a container which is the interface b/w the module and outside world
  • 19. EJB Modules
    • Reside in EJB Containers
      • Provide interface b/w the EJB and app server which EJB resides
    • EJB can be accessed
      • via RMI-IIOP
      • via JMS
      • via Web Service over SOAP
    • Three types of beans
      • Entity, Session and Message-Driven
  • 20. Web Modules
    • An Application that can be accessed over the Web
    • Consists of Servlets, JSP Pages, HTML
    • Stored in WAR files
    • Java Servlets
      • platform-independent server side software
      • run in a servlet or Web container
      • Web container is responsible for servlet creation, deletion
      • Java code with HTML
    • Java Server Pages
      • Used to generate and display dynamic content on the Web
      • JSP are translated into Servlets at run-time at first request
      • HTML with Java code
  • 21. JDBC
    • J2EE Applications Interact With Databases Through Java Database Connectivity (JDBC) API
    • JDBC Supports Four Types of Drivers
      • JDBC-ODBC Bridge
      • Native-API Partly Java Bridge
      • JDBC-NET Pure Java Driver
      • Native-protocol Pure Driver Java
    • Drivers Return a Connection Object Which Represents a Connection to the Database
    • Statement Objects Contain Methods to Pass SQL Statements to Database and Return Results
    • ResultSet Objects Contain the Results of SQL Queries
      • Scrollable, Updateable, Holdable
  • 22. J2EE Security
    • J2EE Provides Declarative and Programmatic Security
    • Declarative Security
      • Security Constraints Are Specified in Deployment Descriptors
      • At Run-time the Container Uses Security Policy Configured Specified in Deployment Descriptors to Enforce Authorization
      • Allows Better Application Portability
    • Programmatic Security
      • Security Is Hard-coded Into Application Code
      • Harder to Maintain
      • Used to Enforce Constraints That Can’t Be Expressed Through Declarative Security
  • 23. Define Security Role
    • Definition of Security Role Defined Within the Deployment Descriptor of an EAR
    • <assembly-descriptor>
    • <security-role>
    • <description>
    • This role is for tellers
    • </description>
    • <role-name>Teller</role-name>
    • </security-role>
    • <assembly-descriptor>
  • 24. Role Access To EJB
    • EJB methods can be associated with method-permission elements in EJB module deployment descriptors
    • <method-permission>
    • <role-name>Teller</role-name>
    • <method>
    • <ejb-name>AccountBean</ejb-name>
    • <method-name>getBalance</method-name>
    • </method>
    • </method-permission>
    Source:Enterprise Java Security
  • 25. Role Access To Web Resources
    • Access to web resource URI’s can be specified by security-constraint elements in web module deployment descriptors
    • <security-constraint>
    • <web-resource-collection>
    • <web-resource-name>
    • Account servlet protected area
    • </web-resource-name>
    • <url-pattern>/finance/account</url-pattern>
    • <http-method>GET</http-method>
    • </web-resource-collection>
    • <auth-constraint>
    • <description>Teller can access the URIs</description>
    • <role-name>Teller</role-name>
    • </auth-constraint>
    • </security-constraint>
    Source:Enterprise Java Security
  • 26. Mapping Principals To Roles
    • Mapping of Principals to Security Roles is done by the Deployer
    • If calling principal is in one of the security roles authorized to access method, then calling Principal is allowed access
      • To the URI for Web Resources
      • To the EJB method for EJB
  • 27. Declarative Security Policies
    • Security Policies associated with URI’s and EJB include
      • Login-configurations associated with URI
        • Form-based logins
      • Authorization policies associated with URIs and EJB based on security roles
      • Principal-delegation policies that apply to Web Apps and EJB
      • Connection policies associated with JCA connectors that dictate how apps access EIS in a secure manner
  • 28. Login Configurations
    • J2EE security authenticates a principal based on the authentication policy of the resource the principal has requested
    • J2EE Application Server is responsible for authenticating users
    • The authentication method is specified through the auth-method element in the login-config descriptor
    • Three types of authentication
      • HTTP authentication
      • Form-based authentication
      • Certificate-based authentication
  • 29. HTTP Authentication
    • User must provide userID and password pair, typically as part of HTTP header
    • Done as follows
      • WAS issues HTTP unauthorized client error (401) and a WWW_Authenticate HTTP header
      • Web browser pops up dialog window
      • User enters id and password
      • Information is sent to Web Server
      • WAS extracts info, authenticates user
  • 30. HTTP Authentication (Cont)
    • With HTTP authentication a Realm must be specified
      • Determines scope of security data
      • Used in HTTP 401 challenge to inform user of the name of the application domain
    • Two types
      • Basic: userID and password passed as cleartext
      • Digest: userID and hash value of password are sent
    • <login-config>
    • <auth-method>BASIC</auth-method>
    • <realm-name>SampleAppRealm</realm-name>
    • </login-config>
  • 31. Form-based Authentication
    • <login-config>
    • <auth-method>FORM</auth-method>
    • <form-login-config>
    • <form-login-page>/login.html</form-login-page>
    • <form-error-page>/login_fail.html</form-error-page>
    • </form-login-config>
    • </login-config>
    • When client requests protected resource, server redirects the client to an HTML form to obtain userID and password
    • If authentication fails, user is redirected to error page
  • 32. Certificate-based (X.509)
    • <login-config>
    • <auth-method>CLIENT-CERT</auth-method>
    • </login-config>
    • Web Server must be configured to perform mutual authentication over SSL
    • Client must make request over HTTPS
      • Otherwise server will redirect the client over HTTPS
    • Client must present certificate to establish a connection
    • If SSL connection is made, server knows the client has presented it’s own certificate and no one else
    • Client certificate is then mapped to a principal that has been assigned 0 or more security roles
  • 33. Creating Secure Channel
    • <user-data-constraint>
    • <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    • </user-data-constraint>
    • Specifies the request to a URI resource should be initiated over HTTPS
  • 34. User-Data Constraints
    • There are times we want to specify communication must be done over SSL
    • This can be done by setting the <transport-guarantee> element in the <user-data-constraint> descriptor
    • <security-constraints>
    • <web-resource-collection>
    • <web-resource-name>ReservationServlet</web-resource-name>
    • <url-pattern>/travel/reserve</url-pattern>
    • </web-resource-collection>
    • <user-data-constraint>
    • <transport-guarantee>
    • CONFIDENTIAL
    • </transport-guarantee>
    • </user-data-constraint>
    • <security-constraints>
  • 35. Programmatic Security
    • How to obtain Subject and Principal information programmatically?
    • EJB methods in interface javax.ejb.EJBContext
      • isCallerInRole( )
        • Test whether current caller has been assigned security role
      • getCallerPrincipal( )
        • Obtain Principal object representing the current caller
    • Servlet/JSP methods in interface javax.servlet.http.HttpServletRequest
      • isUserInRole( )
        • Returns true if current caller is assigned security role
      • getUserPrincipal( )
        • return Principal object representing the current authenticated user
      • getRemoteUser( )
        • Return the name of the authenticated user, null otherwise
  • 36. Programmatic Security with JAAS
    • Java Authentication and Authorization Service
      • Provided in javax.security.auth package
      • Developed to provide role-based authentication, to supplement code-based authentication
      • Uses Pluggable Authentication Modules (PAMs)
      • Requires authentication and authorization routines to be explicitly called
  • 37. JAAS Authentication
    • Determines the Subject of the user (or service) making the request
      • Each Subject is associated with identities or principals
      • Each Subject can have attributes or credentials
    Subject Credentials X.509 updatePermission … Principals Joe Smith 000-11-4444 123321
  • 38. JAAS Architecture Application LoginContext LDAP Server JndiLoginModule RdbmsLoginModule RDBMS NT Authentication Kerberos Authentication Biometric Authentication LoginModules
  • 39. Authentication Steps
    • App Creates LoginContext object and passes CallBackHandler
      • Reads JAAS configuration file to determine which LoginModule s to load
    • App Calls LoginContext login( ) method
      • Calls the login( ) methods of each LoginModule
      • Each login( ) method performs authentication, possibly using the CallBackHandler to get input from user
        • Each LoginModule is specified as Required or Optional
        • Overall authentication succeeds only if all Required LoginModule s succeed
    • App obtains the Subject by calling LoginContext getSubject( )
    • App obtains the Principals by calling Subject getPrinciples( )
  • 40. JAAS Authorization
    • By default, all J2EE resources within a WAS are accessible unless they are explicitly protected
    • JAAS Enforces Principal-Based Authorization
      • access to resources are based on the current Principal
    • Steps include:
    • Associate a Subject (and Principals) with a thread of execution
      • Use the Subject.doAs( ) or Subject.doAsPrivileged( ) methods that execute some privileged code
    • Update Security Policy Files
      • Specify grant entries that describe codeSources and/or Principals authorized to perform Privileged Actions
  • 41. Benefits/Limitations Of JAAS
    • JAAS compliments the security features of J2SE
    • Multiple authentication mechanisms can be “stacked” upon each other and easily configured through configuration file
    • Supports vendor-neutral authentication mechanisms
    • JAAS is not equally supported by J2EE Application Servers
  • 42. Web Service Clients
    • Three ways for a client to invoke a Web Services methods are
      • Static stubs
      • Dynamic proxy
      • Dynamic invocation interface (DII)
    • Static Stubs (Generated Stubs) are created at development time
    • Dynamic Proxy – stub classes are created at runtime
    • Dynamic Invocation Interface – Client can call web services which it has no Service Definition Interface or stubs
  • 43. J2EE Interoperability
    • Interoperability is primarily achieved through RMI and Java IDL
    • RMI allows J2EE Applications to communicate with remote Java Applications
        • uses the Java Remote Messaging Protocol (JRMP)
      • Allows for Objects to be call-by-value since objects can be serialized and sent across network
    • Java IDL Allows J2EE Apps to communicate with objects in other languages
        • uses the CORBA-standard Internet Inter-Orb Protocol (IIOP)
        • Only supports call-by-reference
  • 44. Best of Both Worlds: RMI-IIOP
    • RMI over IIOP (RMI-IIOP) combines RMI’s ease of use with CORBA’s interoperability
    • Jointly developed by IBM and Sun
    • Uses IIOP as the communication protocol
    • Allows developers to write remote interfaces in Java, that can be implemented in Java, or any other CORBA compliant language
    • Supports call-by-reference and call-by-value
  • 45. .NET ADO.NET
    • ADO.NET is the New Database Technology of the .NET Platform.
    • ADO is a Language Independent Model That is the Major Benefit of Microsoft's Universal Data Access Strategy.
    • .NET Includes Data Providers for Several Types of Databases Including Oracle, OLE, and SQL Server.
    • The Underlying Technique of ADO.NET is the Dataset Which Promotes a Disconnected Technique Where Data Will be Represented in Local Memory.
  • 46. ADO.NET
    • The DataAdapter is Responsible for Filling in the Data Set Object With Data and Schema Information. The DataAdapter Works in Conjunction With the DataReader Class to Fill the DataSet Object.
    • The DataReader Class Can Only Read From a Database. The Object Contains One Row of Data. Must Reconnect to Get the Subsequent Rows.
    • The DataSet Is Broken Down Into 2 Subcomponents the DataTable Class and a Collection of Relationships for the Corresponding Tables.
  • 47. .NET Web Services
    • Microsoft Makes Use of XML (Over the SOAP and HTTP Protocols) in its .NET Framework for Implementing Web Services. The Main Reason is That With XML the Client Does Not Need to Know the Language the Web Services Are Implemented in.
    • .NET has a command line tool to generate source code from a WSDL into a specified language (VB.NET or C#). The source code can be added to a project and instantiating an object will enable the use of the web service.
    • There Are 4 Components in the .Net Infrastructure That Allow Clients to Find and Use Web Services.
      • Directory
      • Discovery
      • Description
      • Wire format
  • 48. .NET Security
    • There Are 5 Security Facets in .NET
      • Code-Based Access Control - Giving Permission at the Code Level to Access Resources
      • Role-Based Access Control – Security Enforcing a User’s Permissions for an Application, Based on the User’s Role.
      • Secure Code Verification and Execution - Analyzing the MSIL and Insuring the Executing Code Is Behaving.
      • Secure Communication – Insuring That Data Is Being Passed in a Secure Manner Both Locally or Remotely to Avoid Message Tampering.
      • Secure Code and Data Protection - I nsuring That Code Has Been No Unauthorized Changes by Utilizing Cryptographic Solutions and Signatures.
    • The Focus Will Be on Authorization, Authentication, and Cryptography in RBAC and Secure Code Execution.
  • 49. .NET Security
    • Authentication - .NET supports several different methods for authentication to determine credentials.
      • Windows based- Use of Principal and Identity Objects in conjunction with technologies like IIS pr Certificates to verify identity.
        • Identity - similar to a user account contains Name, IsAuthenticated, and AuthenticatedType.
        • Principal – is associated with an identity and is a list of roles for the identity.
      • Form based- Using web based HTML form to verify identity. Then using cookies in ASP.NET the information can be used in the future.
      • Passport - Microsoft specific technology and supported directly in ASP.NET. Similar to form based authentication. Uses a central server to check a user’s credentials.
  • 50. .NET Security
    • Authorization - There are two ways to use authorization in .NET using Security demands or Principals.
      • Security demands : Places a restriction on an entire class or methods within a class. Limits the use of class based on full trust or partial trust users.
      • Principals : They are very similar to security demands as you can place restrictions on classes or methods. After defining roles for them the principal object can use the IsInRole() method to see the status of the current user.
  • 51. .NET Security
    • Encryption - .NET does encryption through via streaming objects (file stream).
      • .NET uses the Windows CryptoAPI.
        • Algorithms
        • Hashing
        • Signatures
      • Streaming objects can simply be sent to encryption objects to be encrypted.
      • The encrypted object can be streamed elsewhere to a network socket for example.
  • 52. .NET Interoperability
    • Interoperability can be achieved through remote communication in .NET.
    • CORBA protocols are not innately supported in the .NET Framework.
    • However third party products and open source projects are available / are in development:
      • Janeva (Borland product)
      • IIOP.NET (open source -available)
      • Remoting.NET (open source - never finished)
      • Microsoft .NET and J2EE interoperability tool kit (Microsoft product)
  • 53. .NET Remote Communication
    • .NET can achieve interoperability between objects in different application domains through remote communication. The goal of remoting is to allow the ability to enable communication between objects regardless of the protocols or formats being used on both side.
    • To accomplish inter process communication there needs to be:
      • A remote object on the server side that will listen for requests.
      • There are 2 proxies created on the client side the TransparentProxy and the RealProxy that make requests.
        • The RealProxy is the object that transmits the method call to the server machine.
        • The TransparentProxy is an object that contains a list of all classes and methods.
  • 54. .NET Remote Communication
    • There are two ways to access a remote object:
      • Copy the remote object onto the client machine
        • Able to access private Data
        • Waste of bandwidth and memory for large classes when not all of the methods are needed.
      • Use object references on the client side
        • Limits the class exposure
        • Only the method call, arguments, return values, and exceptions are sent making efficient use of bandwidth.
    • Both ways are supported in .NET but the second one is preferred.
  • 55. .NET Remote Communication
    • Remote Communication is done through Channels.
      • HTTP Channel – More interoperable better for Internet
      • TCP Channel – Better performance better for LAN
      • Custom Channel - mix and match properties.
    • Two Serialization formats supported by .NET
      • Binary- converts data to binary (faster, default in TCP)
      • SOAP- converts data into XML string (more interoperable, default in HTTP)
      • Each channel had a default formatter but .NET allows for either formatter to be used in either channel.
    • Remote Object
      • Needs to inherit MarshalByRefObject class.
      • Designer Selects Lifetime of Object Single Call (stateless), Singleton (maintains state), and Client Activated (client invokes and destroys object).
  • 56. Analysis
    • Database Connectivity
    • Security
    • Interoperability
    • Web Services
  • 57. Database- Small Result Set
    • Query: SELECT Lic_License_Number, Org_Name,Lic_Class,Lic_Status,Lic_Cancel_Date,Lic_License_Date,Org_TIN,Org_Status FROM csg.Organization, csg.License WHERE Org_Tin=Lic_Tin and Lic_Tin_Type = 'O' and lower(Org_Name) like '%aetna%'
    • Java time averaged over 10 trials: 453 ms
    • .NET time averaged over 10 trials: 843ms
    • Result Set Size is 4
    • After testing a similar query in an Access database the query time averaged 63ms for .NET. The average time for the Java program was 16ms.
  • 58. Database- Large Result Set
    • Query: SELECT Lic_License_Number, Org_Name,Lic_Class,Lic_Status,Lic_Cancel_Date,Lic_License_Date,Org_TIN,Org_Status FROM csg.Organization, csg.License WHERE Org_Tin=Lic_Tin and Lic_Tin_Type = 'O' and lower(Org_Name) like '%a%'
    • Java time averaged over 10 trials: 5834 ms
    • .NET time averaged over 10 trials: 6653ms
    • Result Size is 17113
    • The time discrepancy is less severe. Wasn’t able to duplicate the query in access due to replicating 17,000 entries.
  • 59. .NET Security Example
    • Security Application Tests Authentication and Authorization Using Windows Based Authentication
      • Uses the Identity Object Which Stored  My Windows Account Information.  
    • After Authentication I Used the Principal Object to Define the Permissions for a Method. 
    • The Principal Object Contained Only the Role Administrator. 
    • If the Current User Is Not the Admin the Method Could Not Be Executed.  This Means That the Current User Does Not Have Authorization to Invoke the Secure Method. 
    • This Is Tested With the Executing Thread's Current Principal Property.  
  • 60. .NET Remoting / J2EE RMI
    • Steps in .NET
      • Make a remote object that inherits the MarshalRefObject class and create a .dll file of the remote object by creating a class library project.
      • Then create two applications a Client and Server.
      • Used a TCP Channel which by default uses binary serialization.
    • Steps in RMI
      • Create interface that extends java.rmi.Remote
      • Create implementation class
      • Run rmic tool to generate stubs and skeletons
      • Create Server app that binds remote object
      • Run Client app
  • 61. Interoperability
    • RMI in J2EE and Remoting in .NET Are Both Simple to Implement
    • Both Allow For Customization of the Transport Protocol
      • Remoting Can Be Done Over TCP/HTTP, or Over Custom Channels
      • RMI Can Be Configured Using SocketFactories and CustomSockets
    • Advantage of RMI in J2EE
      • Multiple Language Support Through CORBA
    • Advantages of Remoting in .NET
      • Highly Customizable- Can Customize the Way Data is Marshalled
  • 62. CORBA Interoperability
    • After Four Hours in the Computer Lab yesterday with Visibroker…
    • Created an IDL (Yes)
    • Created Java Classes from IDL (Yes)
    • Added Functionality to those classes (Yes)
    • Got the Object Running on an ORB (No)
    • Successfully invoked the Object (No)
    • Problem: Lack of Example Documentation
    • Switching to TAO, another CORBA ORB with clear examples.
  • 63. CORBA IDL
    • //HelloWorld.idl
    • module com {
    • module wiley {
    • module compbooks {
    • module brose {
    • module chapter4 {
    • module simple {
    • module helloWorld {
    • interface GoodDay {
    • string hello();
    • };
    • };};};};};};};
  • 64. Create J2EE Web Service
    • Perform the following tasks:
    • Develop web service endpoint Interface
      • Must extend java.remote.Remote interface
      • Methods must throw java.rmi.RemoteException (or a subclass)
    • Implement the Web Service Interface
    • Write the configuration file “config.xml”
    • Run wscompile tool to generate . wsdl file and mapping.xml file
    • Package the service in a WAR and deploy it in a J2EE Web Server
  • 65. Create .NET Web Service
    • Used the built in WSDL tool (WSDL.exe) provided by Microsoft .NET.
    • Command: WSDL /l:cs /o:StockQuotes.cs /n:Stock c:CSE333stockquotes.wsdl
    • Output : StockQuotes.cs – a C# source code file.
    • Options:
      • l language CS, VB, JS, or VJS
      • o output file name
      • namespace of output class
      • Others: Protocol (SOAP or HTTP), Server - generate an abstract class, and other proxy infromation.
    • The next step is to add the source code to the project to allow the web service to be consumed.
    • Instantiated an object and was able to use methods like getMarketIndex and getStockQuote(String sq).
  • 66. Conclusion
    • Database Connectivity
      • From Our Analysis J2EE Outperformed .NET
      • Applications Heavily Reliant on DB Should Use J2EE
    • Security
      • J2EE and .NET Offer Similar Functionality
      • CORBA is a Metamodel
    • Interoperability
      • RMI and Remoting Both Have Advantages
      • CORBA Is Necessary for Distributed or Heterogeneous Environments
    • Web Services
      • J2EE and .NET Offer the Same Support
      • CORBA Is Better for Large-scale Business Apps
      • Web Services Better for Small Internet Apps
  • 67. Questions?
    • Any Questions?