axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Brunsmann <>
Subject Re: Architecture consideration
Date Fri, 13 Apr 2001 14:58:17 GMT
Yuhichi Nakamura <> wrote: 

> Do you mean that enterprise integration should be carried out with xml-rpc?
> EJB and xml-rpc plays diffirent roles.  I do not understand the final
> statement.

You're right. To use a terminology envisioned a couple of years ago. In
the intranet a EJB container makes sense. If you need to communicate
to your extranet partners (nowadays called B2B) a loosely coupling
is reasonable (xml-rpc). And then xml-rpc could be forwarded to EJBs
or servlets.

> I agree that EJB has not been used so much, but it will spread soon I
> assume.

IIRC I saw the first EJB 0.9 something over 4 years ago. I didn't understand
it. Than came spec 1.0 and 1.1. I understood more of it. Now it's 4 years
later and the spec tries to solve some design issues in the 2.0 spec with
performance and bloat with entity beans. The 2.0 spec is over 600 hundred
pages. How many IT people do have time to read and understand this. If you
want to work with a technology you have to understand the basics. In case
of EJB it's all J2EE underlying technology: JNDI, RMI, JDBC, RMI/IIOP;
have I forgotten something? If you know all of them, then you are tight to
a particular language: Java. Let's face it: in the last 40 years of software 
technology there was an evolution of programming languages. Do you think
Java is the end in the evolution of programming languages? Sometimes people
don't want to get caught in the arms of one programming languages which is
controlled by one company. For example: why do I have to annotate some
Java methods with transactional declarative attributes in XML files? Why
am I not able to do this in Java code? The class file spec isn't flexible. 
I'm interested in the moment when generic type (aka templates) will be in
the java grammar.

For me the most important design issue is: simplicity. XML-RPC is simple.
You read the spec and you understand it. If you read the SOAP spec,
you don't understand it. It's not a specification because it leaves so
many questions unanswered. How many did understand the WSDL spec?
For endpoint communication WSDL was invented for using chains of messages
for B2B. Without understanding much of that kind of business I'm asking
myself if this will ever be doable by machines without any interference
of human beings. 

> (Many people assume like IBM, SUN,....)  Oh, I think that IBM WebSphere
> Commerce Suite is developed on top of EJB.  It could be a only real EJB
> application
> in the world :-)

Having big companies behind a technology is great. But you also need the
developers who understand and use the technology. One design promise for
EJB was to be a help for the developer. I recently saw an attempt to 
write a EJB class which should form as a parent class for other EJBs. This
basic parent EJB should run in WebSphere, Suns J2EE reference implementation
and WebLogic. The code looked horrible since it must took into account
different implementations. Although they promised to implement a specification.
For example: the processing of environment variables which was given to
the bean via the deployment descriptor is different in all three implemenations.
Did I hear something like portability? Does this help a developer?
How do test EJBs effectivly in a extreme programming environment
where you should test every small change where most application servers
doesn't support automatic reloading of changed EJBs?
> >Summing up:
> >1. sharing code should be no problem.
> >2. Relying only on J2EE and EJBs would be a huge mistake
> If "and" here were emphasized, I would agree.  Relying on J2EE should be
> ok as long as we provide servlet-only configuration.

I agree. I think it's perfect if both servlet approaches (EJB and non-EJB)
are supported.

It's easter holiday in germany today, so I was very offtopic. Sorry. Now
I'm B2B (back to business).


Do You Yahoo!?
Gesendet von Yahoo! Mail -

View raw message