Thursday, December 6, 2007
From .Net to Java
mso-border-alt:outset gray .75pt'>
Service/Feature
.NET
J2EE
GUI
SWING / AWT
Web GUI
ASP/ASP.NET
JSP
Web Scripting
ISAPI, HttpHandler
Server Side Business Logic Component
Serviced Component (COM+)
EJB Session Beans
Server Side Data Component
Server components with DB logic
EJB BMP Entity Beans with DB Logic
Naming
ADSI
JNDI
Remote Invocation
.NET Remoting
RMI / RMI-IIOP
Data Access
ADO.NET
JDBC, SQL/J
Messaging
MSMQ
JMS
Transactions
COM+ / MTS
JTA
Highlights
of the migration strategy
ASP.NET
COM+ (.NET Enterprise Service)
-> ADO.NET
1.
Presentation tier migration
a) JSP -> ASP.NET (sample code snippets) :-
JSP
Scriptlet
:-
<!--
<%for (int i=0
out .println(i+"<
}
%>
ASP
.NET scriptlet
<!--Scriptlet--
for(
i<3; i++){
Response.Write(i
+"<br>"); }
%>
JSP
Expression :-
<%=new
java.math.BigDecimal
ASP
.NET Expression :-
<%=
JSP
Declaration :-
<%!
public String foo(){
return "foo";
}
%>
ASP
.NET Declaration :-
<script runat="server"
public virtual System.String
{
return "foo";
}
</script
b) Implicit objects :-
mso-border-alt:outset gray .75pt'>
JSP
ASP .NET
application
Application
session
Session
request
Request
response
Response
out
c) Cookies :-
Creating
a cookie and setting its expiry time.
Code
in J2EE :-
<%
Cookie userCookie = new Cookie("user",
"uid123");
userCookie.setMaxAge(60*60*24*365); // 1 year
response.addCookie(userCookie);
%>
Code
in .NET :-
<%
System.Web.HttpCookie userCookie
= new System.Web.HttpCookie
System.DateTime dateTime =
System.TimeSpan timeSpan =
60*60*24*365); // 1 year
cookie.Expires = dateTime.Add(
Response.Cookies.Add(userCookie);
%>
d) Beans :-
Java
code :-
public class bean1 {
private String text = "Hello";
public bean1 (){
}
public String getText() {
return this.text;
}
public String setText(String text) {
this.text = text;
}
}
C#
Code :-
using
System;
public class
bean1
{
virtual public
{
get
{
return
}
set
{
this.text =
}
}
private System.String
text = "Hello";
public bean1()
{
}
}
e) converting Servlets
to ASP .NET code behind :-
Servlet sample code :-
import
javax.servlet.*;
import javax.servlet.http.*;
public class SimpleServlet extends
public void doGet(HttpServletRequest
request,
HttpServletResponse response)
throws ServletException,
java.io.IOException {
response.setContentType("text/html");
java.io.PrintWriter out = response.getWriter();
out.println("<html><body>");
out.println("Simple Servlet
Body");
out.println("</body></html>");
out.close();
}
}
ASP
.NET Code Behind sample :-
using
System;
using System.Web;
using System.Web.UI;
public class
{
private void
System.EventArgs
{
Response.ContentType="text/html";
Response.Write("<html><body>");
Response.Write("Simple Servlet
Body");
Response.Write("</body></html>");
}
}
f) Tag Library :-
mso-border-alt:outset gray .75pt'>
JSP
ASP .NET
Tag Handler Class
ASP.NET Web User Controls
JSP Tag Library Descriptor
ASP.NET Web Custom Control
JSP taglib
Directive
JSP
tag lib Sample code :-
<!- JSP -->
<!- the source file is specified in the TLD-->
<%@ taglib uri="
<tags:sample />
ASP
.NET tag lib Sample code :-
<!- ASP .Net -->
<%@ Register TagPrefix="tags"
TagName="sample" src="
<tags:Sample
g) Converting Java Applets to .NET Winforms
control
Applet
code :-
package HelloWorldPackage;
public class HelloWorld extends Applet
{
public void paint(Graphics g) {
g.drawString(getParameter("parameter1"),
25, 25);
}
public void init() {}
public void start() {}
public void stop() {}
}
.NET
Winforms code :-
namespace
HelloWorldPackage
{
public class
{
String parameter1;
bool
public HelloWorld()
{
init();
}
protected override
void OnPaint(
{
e.Graphics.DrawString(parameter1,Font,
}
public void
init()
{
this.GotFocus +=
this.LostFocus +=
}
}
2.
Business tier migration
Migrating
EJB to .NET Serviced Component
a) EJB code :- (Session bean)
public class TellerBean implements
public void ejbCreate() {}
public void ejbRemove() throws
RemoteException {}
public void ejbActivate() throws RemoteException
{}
public void ejbPassivate() throws RemoteException
{}
public String getData()
}
.NET
code :- (serviced component corresponding to the java session bean)
[Transaction(
public class
{
public void
Create() {}
virtual public
{ get{...} }
protected override
void Activate(){}
protected override
void Deactivate(){ }
protected void
Remove
{
this.Deactivate();
this.Dispose();
}
}
b) EJB Code :- (Entity Bean)
public
class AccountEntity implements EntityBean
{
private string accountID;
private int balance;
public get_accountID() { ... };
public get_balance() { ... };
public set_balance(int
amount) { ... };
}
public class AccountProcess implements
public AccountEntity[] Inquiry() { ... };
public void Insert(AccountEntity account) {
string strQuery = "SELECT * FROM
...
};
public void Update(AccountEntity account) { ...
};
public void Delete(string accountID) { ... };
}
.NET
Code :- (serviced component corresponding to the java entity bean)
[
public
{
private string
private
public AccountID {
public Balance { get{...};
set {...}; }
}
// dsAccount.xsd
public class
dsAccount : System.Data.DataSet
{
...
}
public class
{
public dsAccount
Inquiry() { ... };
public void
Insert(AccountEntity account)
{
DBAgent.ExecuteNonQuery("sp_getAccount",
paramArray, ...);
...
};
public void
Insert(string accountID,
int balance, ...
){ ... }; // Alternative
}
Create Procedure sp_getAccount ( @accountID
char(8), @balance
c) Business Client Tier
Java
Code :-
<%
try{
Context ctx = new InitialContext();
Object ref = ctx.lookup("TellerHome");
tellerHome = (TellerHome)
PortableRemoteObject.narrow(ref,
TellerHome.class);
teller = tellerHome.create();
out.println(teller.getData());
}
catch(Exception ex) {
out.println(ex.getMessage());
}
%>
.NET
Code :-
<%
myPackage.TellerBean teller = new myPackage.TellerBean
Response.Write(teller.Data);
%>
3) Data
tier migration :-
a) Database connection :-
Java
:- (JDBC)
dbUrl = "jdbc:odbc:ADOTEST";
conn = DriverManager.getConnection(
.NET
(
Catalog=Master;"
System.Data.OleDb.OleDbConnection temp_Connection;
temp_Connection = new
System.Data.OleDb.OleDbConnection(dbUrl);
temp_Connection.Open();
conn = temp_Connection;
b) Statement object :-
Java
:- (JDBC)
Statement
s = conn.createStatement
createTableBooks = "SELECT count(
authors";
ResultSet rs =
.NET
(
System.Data.OleDb.OleDbCommand
createTableBooks = "SELECT count(
authors";
ls.CommandText = createTableBooks;
System.Data.OleDb.OleDbDataReader rs
= s.ExecuteReader();
Web Services and J2EE
If you would like to learn how to use SOAP, WSDL, and the Web services stack
with J2EE, this article gets you off to a good start. It is excerpted from
chapter 7 of the book Building Web Services with Java: Making sense of XML,
SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams;
ISBN: 0672326418).
example scenario, the SkatesTown technical team has
been working in Java for a while and recently has been looking at moving some
of the Java applications that run on their server into the J2EE platform.
They've heard that it's secure, transactional, managed, scalable, and
robust—all the things they want for their business applications. But they're
also interested in Web services, and they want to be able to create services
easily. So, they've decided to build a sample application called
value in using J2EE to implement their Web services.
J2EE Overview
Edition (J2EE) is the platform for building enterprise applications in Java.
J2EE standardizes the services, programming model, and deployment for
applications so that developers can build solutions that can be used on a
variety of application servers. J2EE has a number of application models:
- Thin-client/browser-based applications use
Pages (JSPs). - Thick/managed application clients use RMI-IIOP
to communicate with server-based Enterprise JavaBeans (EJB) components. - Messaging applications use the Java Message
Service to act on messages in queues or from subscriptions.
now add service-based applications, which offer services over SOAP/HTTP to
clients.
framework that supports high quality of service (QoS).
In other words, J2EE lets you build transactional, secure, reliable
applications that are available across a cluster of highly available servers. A
J2EE application server provides a wide variety of capabilities including the
following:
management—Thread
management, pooling, caching, and cluster support
management and validation, authentication, and access control
databases, transactional management systems, connectors to Enterprise
Resource Planning (ERP) systems, and messaging systems
transactional access to databases, and distributed transactions
administration—Deployment,
configuration, and administration tools
provided through the concept of a container.
Containers
logical entity in a J2EE server. Containers are entities that have contracts
with the components that are deployed into a server—but they also help you
understand the way a J2EE system works. Components are deployed to a container,
and the container manages the execution of those components as needed. The
container provides isolation by intercepting calls to the
threads, security, and transactions between components. The container also
provides a useful abstraction between components and the resources they use.
component uses a database, the programmer uses a resource reference
(resource ref) to link to the database. Then the deployment engineer can
configure the actual database that maps to the reference. So, the code that is
written and compiled isn't hard-coded to a specific database.
used for JMS destinations, URLs and URIs, and other
EJB components in the same or different applications. Later in the chapter,
you'll see an example of an ejb-ref that virtualizes
access to another EJB.
Web Services and
J2EE -
JavaBeans
(Page 2 of 4 )
the EJB component. This is the programming model for writing and deploying
business logic into an application server. EJBs
provide a component model for creating business applications. EJB components
are mainly focused on aspects such business logic, as well as database and
legacy server access, transactions, security, and threading—in other words, how
you build core business services in a Java environment.
complex because they were designed to layer over ordinary Java. For each
component, there are multiple .java
user has an Integrated Development Environment (IDE) that shows each component
as a whole as well as the individual class files for that component. However,
in the examples later in this book, we simply use a text editor and basic tools
for portability.
model allows you to structure the business logic into discrete connected
components. EJB applications are loosely coupled, with well-defined interfaces.
styles:
that are instantiated on behalf of a user and last no longer than the time
the client program remains active and running (a session).
mapped into an underlying database or persistent store (for
example, a bank account, purchase order, telephone number, or email
address). Each instance must have a unique key under which it is stored
and retrieved.
usually a one-way, asynchronous JMS message, but also including
messages from other systems such as SAP R/3 or PeopleSoft coming through a
connector.
distinction: between local and remote EJBs. Local
whereas remote EJBs are callable across a network
over distributed networking protocols (such as RMI-IIOP).
thought of as having distinct parts—for example:
- The part that deals with the long-term storage
of data in a database or other persistent backend (local entity beans) - The part that provides business logic
(stateless local session beans) - The part that provides the interface with thick
clients or a graphical interface layer (stateless or stateful
remote session beans) - The graphical Web interface (
- The part that deals with messaging—sending and
receiving messages from other systems (message-driven beans)
J2EE application model is a component model that provides the right component
types to support solid business applications.
EJB Lifecycle
J2EE that's very important to Web services is the lifecycle of an EJB.
Components have well-defined lifecycles—they're instantiated, persisted, and
destroyed. EJBs define a "home" factory for
creating and managing the lifecycle of components. EJBs
can be divided into those with no real lifecycle and those with a lifecycle.
Note - The Open Grid Services Infrastructure (OGSI) offers a model of
services that have lifecycles. This is a point of debate around
Service-Oriented Architecture—whether services have lifecycles like objects or
whether they're stateless.
beans
are session beans with no real lifecycle—the container instantiates a pool of
these as needed. Although there are multiple instances of the component, each
instance is interchangeable with any other, because they have no state that
differs from method call to method call.
(MDBs) have no lifecycle either. They are
instantiated and pooled by the container—so they are always available.
parameters in the create(
color:#333333'>) method (part of the home interface). The instance of an SFSB
contains state information specific to that client, and therefore it must
either be explicitly destroyed or timed out by the container (otherwise the
number would grow until the system's capacity was used up).
file system, or other persistent storage. They must be either created or found
using a key. Because they're kept in a persistent datastore,
the objects have a very extended lifetime—unlike
these object instances remain available until they're explicitly deleted,
surviving reboots, crashes, system migrations, and so on. Another difference
with SFSBs is that many clients can talk to one
entity bean instance.
model of services matches the model of stateless session beans and
involves all distributed interaction with the EJB application taking place
through a façade of stateless session beans and MDBs.
This model most closely fits today's services infrastructure.
WS-Addressing (http://www-106.ibm.com/developerworks/library/ specification/
ways of doing it without these technologies (such as adding a key to the end of
the address URL), but they aren't standardized. Apache Axis has recently added
support for WS-Addressing, but it isn't supported in Apache Axis or in the J2EE
specification at the time of this writing.
Note - Apache SOAP supports this approach. See
http
dive deeper into J2EE support for Web services, the only supported components
that can be accessed as Web services are servlets,
stateless session beans, and MDBs. For more information
about stateful services, see Chapter 8, "Web
Services and Stateful Resources."
Web Services and
J2EE - Roles: Development, Assembly, and Deployment
(Page 3 of 4 )
useful aspects of J2EE is the way the architecture was designed from the start
with ordinary people in mind. Early Web systems were often created from many
different technologies, so the developer had to be good at programming in
multiple languages and systems as well as understand the network, the database
connections, system administration, and so on. For example, many of the early
dynamic Web technologies mixed HTML with the programming language in a single
file. This meant that a graphic designer couldn't modify the look and feel
without risking breaking the logic—with the result the programmer frequently
did the layout and HTML/Web design, or spent valuable time cutting and pasting
HTML into their code.
clearly separates roles such as Web programmer, business logic
programmer, deployment engineer, and administrator. To achieve this separation,
there are clear contracts between the components and the infrastructure. For
example, JSPs allow the HTML and page design to be
separate from the business logic.
important roles: the assembler and the deployment engineer. Both are like
systems integrators. Like a brick layer, the assembler pulls together a set of
components to create an application. Then the deployment engineer comes and
wires and connects everything, like an electrician and plumber rolled into one.
The mortar, solder, and cabling that keep it all together are called deployment
descriptors.
descriptors (DDs) are XML files that capture
information about components and applications. They help resolve aspects left
undefined by the programmer, such as resolving references, setting policies,
and linking to other components.
shows a sample DD for an EJB:
version="1.0"?>
the same approach has been applied to the Web services support in J2EE 1.4,
where a new DD—webservices.xml
file is effectively the Java Standards version of the Axis WSDD file.
Web Services and
J2EE - Benefits of Using Web Services with J2EE
(Page 4 of 4 )
high-quality, reliable, secure infrastructure for building complex Web and
business applications. Web services started more simply with no inherent
security, reliability, or transactions, but these are now being added using the
open and flexible model that SOAP and Web services offer.
using Web services with J2EE to provide simple interoperable access to existing
J2EE applications—for example, creating a C/C++/C# or VB.NET client to an EJB
application. Before SOAP and Web services, this was possible but very complex.
J2EE uses a distributed object model called RMI-IIOP, which bridges the Java
object model and the CORBA (IIOP) protocol. Accessing J2EE components from
outside Java used to require either bridge technology or complicated logic to
access the components using IIOP from C or C++. This was typically a painful
process. SOAP and Web services make this scenario much more appealing, and a
number of companies are using the SOAP approach in their systems today.
services? In other words, why would you write a J2EE application and
server to create Web services? The answer, as usual, depends on the individual
circumstances. Many small applications will work fine with the Java Axis
approach. As the complexity and requirements on the application scale up,
having a managed J2EE environment in which to run components becomes more
appropriate. In particular, the benefits increase as you start to connect to
databases, messaging systems, and other enterprise systems.
Security
that a J2EE application server brings is security. Because the individual
methods (operations) of an EJB can be secured, and because J2EE has end-to-end
security, you can use either HTTPS or WS-Security to authenticate users and
then offer them services and/or operations with
fine-grained access control. For example, a single service may have bid
and cancel operations, and a J2EE application server can be configured
with one group of ordinary users who can bid, and then another group of
tightly integrated into the Java runtime, these security models extend to the
Web services space, and so the access controls are applied to incoming SOAP
requests as well, based on the configuration and administration of the
Services.")
Transaction Control Across
Distributed Resources
J2EE application server offers is transaction control across distributed
resources. Even if you aren't using WS-AtomicTransaction
and WS-Coordination (see Chapter 11, "Web Services Transactions"),
you may wish to ensure that the backend resources you're communicating with are
kept in sync with each other and are transactional. For example, you may wish
to have a database log of Web service transactions held in an Oracle or DB2 RDB
and then use a JMS system to send messages internally to a legacy system. The
J2EE server can make the database log entry and send the message in the same
unit of work. That way, even if the HTTP connection fails and the SOAP response
message sent to the client fails, your server has a log of what happened.
Although it doesn't offer full end-to-end transactionality,
this type of architecture has been used extensively in Web-based systems to
provide a higher level of robustness at the application level.
Container Managed Persistence
programming model for building business applications—including the tools and
technology to map your objects into databases (entity beans)—and a reliable,
scalable infrastructure for running those applications. As soon as the
application moves beyond the simplicity of a sample or first proof of concept,
users find that the learning curve and extra complexity of a J2EE solution is
repaid in the savings in time and effort that the model offers.
sample application, the J2EE application server will automatically save the
state of the objects we create using a feature called Container Managed
Persistence (CMP). This means that instead of having to write database
logic and SQL statements, we can write fairly straightforward Java objects and
have the container generate the SQL and take care of all the database reads,
writes, and updates. This approach makes it quick and easy to build a Web
service application with a database at its heart. And, this support is
independent of which database server is used.
next week for the continuation of this article.
Subscribe to Posts [Atom]