|
http://in.geocities.com/rsramsam/axis4.htm |
ACCESSSING EJB-WEBSERVICE
FROM DOTNET PLATFORM
(published in DeveloperIQ..February-2005)
R.S.RAMASWAMY
Corporate desktops & LANS mostly use Microsoft Windows platform. This has
been the reality since 1985 , for the past twenty years. It is none too easy
for Office personnel who have been used to Microsoft Productivity software to
switch over to another platform…..not even to another product
in Windows platform, as it leads to operational inefficiency and delays. There were reports that some European
Municipal Administration made the bold change to a different platform , only to
scamper back ‘home' within a month,
after burning its fingers, because of
inefficient operations due to unfamiliar environment.. Sun is reported to have had a runaway success
with its Java Desktop offering , designed to be exactly like Windows Office,
in
In the 1980's, when Microsoft refrained
from offering its own Application software, they used to insist rightly on
standard layout & and 'Look & Feel'
for all products applying for Microsoft logo. .Productivity is a matter
of habit and practice and multitude of layouts leads to waste of time. Finally,
to ensure total compliance, they
themselves took over the entire
field of Productivity software. Standards emerge ,preferably by co-operation , failing which, by compulsion. English language is a case in
point. It was forced on a subject nation but
Each language and each platform is
meant for doing certain things wonderfully
well but may not be suitable for all jobs. When Java language was
designed, the creators made the most important
decision to model the syntax of the new language on already existing and
popular languages C/ C++, though Java language itself was not based on C/C++
but on an earlier language 'Smalltalk'.
This decision ensured that programmers would not be side-tracked into the syntactical
problems and would learn to appreciate the unique and wonderful features of the new language. Too radical
departure from familiar syntax would have resulted in programmers ignoring the new language. This is said to
be the reason why Smalltalk failed.
From the 'familiar' to the
'new', was, correctly, the motto. This
was one of the major factors in the instant success of Java in 1996. DotNet
platform's C# , closely follows the
syntax of Java , and unlike Java, gives
seamless integration of C/C++ code and
even assembly language within C, with C#.
Though ,we can call native code in Java using JNI, it is far from the
recommended practice. The primary purpose of Java language's creation was to
have a compiled language , which would
be platform-independent, and JNI (Java Native Interface)would go against
that purpose. Similarly, the primary purpose of DotNet , atleast originally,
was to develop a Framework for the following
requirements.
a) It
should be language-independent
b) It should be based
on public standards like XML, & SOAP, so
that windows can
talk to Unix.
Thus, DotNet
platform was designed from the groundup for participation in XML WebService.
We need to differentiate between DotNet
platform and C# language. DotNet
platform should not be confused with either C# or VB.net. It is possible to use
even Java in DotNet as J#. Also
COBOL.net and Python.net!( with varying degrees of success).
DotNet applications can be either Desktop or
Web/Enterprise oriented. For the latter category, we have ASP.Net and
its webforms technology. J2ee Programmers who have experience in equivalent
JavaServerFaces (JSF) technology are very few and they would agree that
ASP.net's webforms technology is far friendlier and elegant, if they had ever
tried it.
The aim of developing C# was as follows:
a) It should have the
clean and elegant syntax of Java and its
modern features
like automatic garbage collection and
absence of pointers.
b) But , it should
also enable seamless integration with native
code, if required.
c) It should work
within DotNet Framework.
These are decisive advantages if we consider
Windows platform.
But, Extranet and Internet servers are Unix
machines, predominantly. In Enterprise Applications, typically involving
Extranet(B2B) and Internet exchanges ,
the platform-independence of Java( independence from
different versions of Unix ?) was found to be most welcome, along with
its automatic garbage collection & pointer-less security and robustness.
Java, consequently won almost instant & universal acceptance in server-side
by the corporate world, which however
retained Windows for desktops and
LANS & Intranets. For inter-operability, neither
CORBA, nor EJB nor COM+, could be the solution because they were using
dedicated ports, used binary data transmission and special protocols.
Given this situation, Microsoft realised early, that the solution was XML webservice as a bridge between Windows & Unix
worlds and designed the DotNet Framework accordingly. The same realization dawned on Java camp also and J2EE1.4 focuses
on this requirement. Apache Software
Foundation, created Axis, a SAX-based and advanced implementation of SOAP, to
make this transition, very easy, to implement.
Thus, at present, the most pressing and
farsighted need in
“***With all of the money entering the enterprise application integration (EAI) space, ignoring
interoperability between these two platforms borders on negligence.
This fact is driven home by the
Gartner Group's prediction that by the end of
2005, 90 percent of medium and
large companies will be using a mixture of Java and Microsoft technologies........
J2EE and .Net both will be
important platforms for the next few
years at least, if not longer (I still have many friends involved in
COBOL development). Knowing how to integrate the two platforms smoothly and reliably adds value to the
enterprise by capitalizing
on existing investments and
realizing reuse***."
To
the above quote, we need only to add that there is yet another world, that of
Perl/Php/Python. Python has been around
since 1990, nearly five years earlier than Java. It is a language which has
CORBA language binding, thereby enabling it to be a CORBA player, with all the
privileges thereof! However, it had not gained much acceptance in Corporate
world, as CORBA was very difficult to implement. The
main question is not that of the language but availability of Enterprise
CONTAINER, which would enable the programmer to concentrate on the business
logic rather than on System-level plumbing code.Now that DotNet running
on COM+ in Microsoft machines, offers possibility for Python to be used in
DotNet, it is gaining ground in US.
Secondly, there are any number of
medium-level web applications, which may not require the usual insistence on
built-in Security,Transaction management,Resource pooling etc associated with
COM+ and EJB containers. Or, the designers provide these features by
themselves. In such cases, the third world of Scripting languages also would
join the XML Webservice world. Budding programmers
would do well to familiarize themselves with all the three worlds and integrate
them.
-----------------------------
In
very simple cases, we can just expose our querybean as webservice in Axis. Just
copy querybean.java as querybean.jws in
axis folder of tomcat4\webapps.
And
we can get the wsdl file by running tomcat4 and giving URL in browser as :
'http://localhost:8080/
axis/querybean.jws?wsdl
(as illustrated HERE)
But
"EJBs are at the heart of what J2EE is all about; In fact,whenever developers
think of J2EE ,they usually think of EJB".That is why we should
concentrate on exposing an EJB as web-service rather than a simple Javabean.
---
So, we will
develop a simple EJB and deploy it as an XML WebService using AXIS.
We will then access this webservice by using
ASP.net client as
well as standalone C# client. During, experimentation, it was found that
accessing this asp.net program through a WAP device was simple and clean, because ASP.net, automatically adjusts
the output format , according to the client browser calling it.. .More on that,
later.
Continued in PART-2