Enterprise%20Component%20Comparison:%20An%20Examination%20Of%20J2EE,%20CORBA,%20And%20.NET

1
Enterprise Component ComparisonAn 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
srf04001_at_engr.uconn.edu phil.griffith_at_gmail.com uc
onnfrank_at_yahoo.com
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
Advantages Disadvantages
Data is in the correct format when it is received from the ORB. This saves time from having to parse XML. Data cannot be read by humans alone. Because it is in the correct/digital format.
Standard specification, which is Defined by the OMG. 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.
Readable Interface Descriptions. SOAP wsdl files are difficult to read through. Does not directly support .NET.
Supports various events, i.e. transaction, notification, security services. Cannot transport some types of documents easily, such as .pdf or .doc files.
9
CORBA WS
Web Services
Advantages Disadvantages
Ready-made to travel over the internet because it uses the http protocol. Congestion at Port 80.
Data is easy to read in XML format Many competing SOAP standards.
Supports .NET Difficult to encode polymorphism.
Supported by IBM and Microsoft. No standard specification.
Can transport attachments without problems. No event services.
Slower performancedata needs to be parsed
WSDL files are not easy to read.
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

• CORBAs 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, Thats 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 isnt CORBA
  Compliant?
• What About Security Policies on a System?
  Sometime This System Can Be Accessed, Sometimes
  it Cant 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 DomainGroup of Objects That Do
  Not Communicate With Other Objects.
• To Communicate Between Domains, There Must Be a
  Bridge.
• Some Terms
• In-Line BridgingAll the Domains Are Within One
  ORB.
• Request Level BridgingDomains Are Not Within One
  ORB. (More Interesting Than In-Line Bridging)
• DIIDynamic Invocation InterfaceCan Invoke
  Methods on Objects Without Knowing What the
  Target Interfaces Are at Compile Time.
• DSIDynamic Skeleton InterfaceServers Dont 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

Enterprise Information Server
Client Side
Middle Tiers
Web Application Servers JSP, Servlets, HTML, XML
RDBMS, ERP, Legacy Apps
EJB Server, JNDI, JMS, JavaMail
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 Cant Be
  Expressed Through Declarative Security

23
Define Security Role

• Definition of Security Role Defined Within the
  Deployment Descriptor of an EAR
• ltassembly-descriptorgt
• ltsecurity-rolegt
• ltdescriptiongt
• This role is for tellers
• lt/descriptiongt
• ltrole-namegtTellerlt/role-namegt
• lt/security-rolegt
• ltassembly-descriptorgt

24
Role Access To EJB

• EJB methods can be associated with
  method-permission elements in EJB module
  deployment descriptors
• ltmethod-permissiongt
• ltrole-namegtTellerlt/role-namegt
• ltmethodgt
• ltejb-namegtAccountBeanlt/ejb-namegt
• ltmethod-namegtgetBalancelt/method-namegt
• lt/methodgt
• lt/method-permissiongt

SourceEnterprise Java Security
25
Role Access To Web Resources

• Access to web resource URIs can be specified by
  security-constraint elements in web module
  deployment descriptors
• ltsecurity-constraintgt
• ltweb-resource-collectiongt
• ltweb-resource-namegt
• Account servlet protected area
• lt/web-resource-namegt
• lturl-patterngt/finance/accountlt/url-patterngt
• lthttp-methodgtGETlt/http-methodgt
• lt/web-resource-collectiongt
• ltauth-constraintgt
• ltdescriptiongtTeller can access the
  URIslt/descriptiongt
• ltrole-namegtTellerlt/role-namegt
• lt/auth-constraintgt
• lt/security-constraintgt

SourceEnterprise 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 URIs 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
• ltlogin-configgt
• ltauth-methodgtBASIClt/auth-methodgt
• ltrealm-namegtSampleAppRealmlt/realm-namegt
• lt/login-configgt

31
Form-based Authentication

• ltlogin-configgt
• ltauth-methodgtFORMlt/auth-methodgt
• ltform-login-configgt
• ltform-login-pagegt/login.htmllt/form-login-pagegt
• ltform-error-pagegt/login_fail.htmllt/form-error-p
  agegt
• lt/form-login-configgt
• lt/login-configgt
• 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)

• ltlogin-configgt
• ltauth-methodgtCLIENT-CERTlt/auth-methodgt
• lt/login-configgt
• 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 its 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

• ltuser-data-constraintgt
• lttransport-guaranteegtCONFIDENTIALlt/transport-guar
  anteegt
• lt/user-data-constraintgt
• 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
  lttransport-guaranteegt element in the
  ltuser-data-constraintgt descriptor
• ltsecurity-constraintsgt
• ltweb-resource-collectiongt
• ltweb-resource-namegtReservationServletlt/web-resou
  rce-namegt
• lturl-patterngt/travel/reservelt/url-patterngt
• lt/web-resource-collectiongt
• ltuser-data-constraintgt
• lttransport-guaranteegt
• CONFIDENTIAL
• lt/transport-guaranteegt
• lt/user-data-constraintgt
• ltsecurity-constraintsgt

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
Principals
X.509 updatePermission
Joe Smith 000-11-4444 123321
38
JAAS Architecture
Application
LoginContext
RdbmsLoginModule
JndiLoginModule
LoginModules
LDAP Server
RDBMS
NT Authentication
Kerberos Authentication
Biometric Authentication
39
Authentication Steps

• App Creates LoginContext object and passes
  CallBackHandler
• Reads JAAS configuration file to determine which
  LoginModules 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 LoginModules 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 RMIs ease of
  use with CORBAs 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
  Users Permissions for an Application, Based on
  the Users 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 - Insuring 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 users 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_TinLic_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_TinLic_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. Wasnt 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 /lcs /oStockQuotes.cs /nStock
  c\CSE333\stockquotes.wsdl
• Output StockQuotes.cs a C source code file.
• Options
• \l language CS, VB, JS, or VJS
• \o output file name
• \n 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?