New to Java? We'll help you get started with our revised beginner's tutorial, or our free online textbook.
|
Get the latest Java books |
|
h t t p : / /w w w . j a v a c o f f e e b r e a k . c
o m /
|
Menu Articles Using Java Applets Looking for Java resources? Check out the Java Coffee Break directory! |
Java ProfilesSubrahmanyam AllamarajuSubrahmanyam is a Senior Engineer with BEA Systems. His interest in modeling lead him from his Ph.D. in Electrical Engineering to object-oriented programming, and then to distributed computing and software architecture. In this process, he drifted from his one-time home - the Indian Institute of Technology, to Computervision, and Wipro Infotech, and later to BEA systems. You can find more about his current activities at his hiome http://www.Subrahmanyam.com. In this exclusive interview, he talks with us about the Java 2 Platform Enterprise Edition (J2EE), and web technologies like JSP and ASP. Q: What do you see as being the biggest change affecting the Java community in the last year?A: One of the
most significant changes is in the area of enterprise computing. While
J2EE was introduced in 1998, J2EE began to occupy the center-stage of
enterprise development in 2000. Over the last one year, the basic J2EE
web and and EJB component models became more mature, and address more
application development concerns. Simultaneously, the vendors are
getting down to delivering more robust products. As a result, the focus
of Java developers changed from J2SE to J2EE technologies such as
Servlets, JSP pages, and EJBs. Another interesting development is that
certain concepts such as transactions and security became more
predominant in application development. I consider this a very sensible
and desirable change. Apart
from this, the focus of J2EE is slowly expanding to reach the real
enterprise via the connector API. The area is diverse and the problems
are known to be difficult. J2EE developers should watch out for
exploiting such developments. Q:
How do you find Java stacks up to other programming languages, such as
C++ or scripting languages like ASP that are used to provide quick
interfaces to databases and COM components? I see
two different questions – the first dealing with C++, and the other
dealing with rapid development via scripting. With regards to the first
question, I can only say that, Java is architecturally superior to other
legacy programming languages. The
second question is quite interesting, as it deals with two different
paradigms of application development. Any technology that lends to rapid
development does so at the expense of separation of concerns and
layering. Most of the scripting approaches fall under this category.
This approach may not always be desirable. As an alternative, what I
think important are application environments providing most of the
commonly required infrastructure. J2EE meets this to a fair extent. Such
environments allow rapid development by providing certain layers of
facilities. I think this is a cleaner solution. Q:
For readers unfamiliar with enterprise development, what exactly is the
Java 2 Platform Enterprise Edition? What does it mean for developers? The most
fundamental idea behind J2EE is that it is meant for server-side
development. Server-side development is infrastructure intensive. On the
server side, applications and data are typically distributed. Apart from
this, resources are scarce, as resources are shared across a large
number of clients. There are also the needs for security, transactions,
legacy connectivity etc. What
J2EE addresses is the basic architecture and infrastructure required for
server-side applications. Firstly, it includes a programming model and a
set of APIs. The programming model consists of web (servlet and JSP)
components, and EJB components. These are the basic development units in
J2EE. The J2EE specifies how these components should be implemented. Secondly,
the J2EE specifies a set of commonly required enterprise APIs such as
such as JDBC, JNDI, JMS, JTA etc. These APIs provide a very component
centric integrated set of facilities to access services traditionally
called as middleware. So, as opposed to using a proprietary API for
asynchronous communication between two components, developers can use a
generic API. The obvious advantage is that, most of the logic
implemented in these components is independent of the underlying
implementation. This gives J2EE a flavor of WORA. The
third important aspect of J2EE is its notion of packaging, and
deployment. While software design process breaks down the architecture
into bits and pieces of code, the idea of packaging gives the
flexibility of building applications bottom-up – that is by assembling
components into larger modules and applications. To me, this is a very
important facility, and I think developers should consider this in their
development plans. Q: A
reference implementation of J2EE is available for testing, but what
about deployment of real-life projects? What type of application server
would you recommend? While
reference implementations serve the purpose of validating the specs, I
don’t consider reference implementations as development/deployment
platforms. They are not meant to be so. I look for two basic aspects
from a J2EE application server:
Q: In
recent months there have been a few conflicts over licensing of J2EE and
its direction. What’s your opinion over the licensing of the J2EE
brand? I think
the issue has more or less been settled. Q:
The J2EE platform gives developers a lot of choice, with its wide range
of technologies. How do developers choose RMI vs. CORBA, servlets vs.
JSP? Being a
generic platform for enterprise systems, J2EE offers a wide range of
choices. There are several questions that developers often face – such
as entity vs session, CMP vs BMP, servlets vs JSP, messaging or no
messaging. As J2EE gets richer in infrastructure, the number of choices
is bound to increase. My
approach is that one has to take a very pragmatic view before going for
one or the other. These choices have specific purposes, and one should
consider a mix and match of these choices, leaving enough flexibility
and maintainability in the architecture. While it is tempting to
over-generalize a solution to a specific choice (such as JSP and
sessions beans for all use cases and content), such an approach may not
scale when it comes to maintainability. I would
also like to add that, what J2EE provides are the building blocks and
associated APIs, and not architecture. J2EE is too generic to serve as a
general-purpose architecture. One has still to develop application
specific architectures on top of J2EE. Once the blocks of the
architecture (and a context) are identified, it gets easier to make a
choice between alternatives. Q:
Looking to the future now, where do you see Java heading?
Is there a particular technology that you’re enthusiastic
about? To
answer this question, let me go back to early 1996, when most of the
developer community started experimenting with the Java language. I
still recollect several articles and white papers expressing lot of
ho(y)pe. Ultimately, what survived over the last four years is those
Java technologies/approaches that fuelled mainstream internet-centric
computing. Although I’m personally enthusiastic about wireless and
device centric developments, I think most of challenges and demands are
still in the middle-tier and back-end, particularly in the areas of
inter-business integration, business-to-business integration etc. There
is still some amount of hype here. I expect the existing initiatives to
stabilize, and new initiatives towards standardization in these areas. Q: Subrahmanyam Allamaraju, thank you for your thoughts on the Java 2 Enerprise Edition platform, and related technologies. Subrahmanyam's new book, a collaboration, is "Professional Java Server Programming J2EE Edition", and is published by Wrox Press.Interview Copyright 2000 Wrox Press. Used with permission |
||||
|