Google: Please replace Servlets with EJB's in RPC
Tazly
JavaScript and Java.
But the RPC mechanism really isn't that well thought out. The problem
is that it uses servlets. Servlets are old, but great at handling
sessions and HTTP-interface stuff. However all thats done transparently
by GWT, so I'm left with a RPC call that I need to handle from within a
Servlet (of all things). What should I do with that Servlet? Setting
HTTP headers and serializing is allready done nicely for me by GWT.
Basicly I have no use of the Servlet interface. If I mess too much
around with the Servlet I might even screw things up with the
Java-JavaScript communication, which really should be hidden from me.
What I _DO_ need is a way to pass on the RPC call to business code,
which - running java - is usually an EJB layer. Of course I can look up
the EJB from my Servlet and call a business method there. That method
would be identical to the RPC method I have in my Servlet. So, using
that approach I end up with an extra layer (the Servlet) with
absolutely no work to do - just passing stuff through to the EJB layer.
Thats unnecesary!
What google should do is this: Change the RemoteService from being a
Servlet to being a Stateless Session Bean. The RPC communication should
either be a WebService directly to the SessionBean or if thats too
slow, another approch is a hidden ControllerServlet to bridge the call
from client to backend.
Comments are welcome.
- Rune Larsen
mP
merely an implementation detail. There is no need to touch any of the
stuff thats not related to your interface.
In fact I myself think the best approach is to merely delegate from the
servlet to the real implementation. This only requires a handful lines
of code. Perhaps the reason you wish to be in ejb land is the overly
verbose process of delegating from the servlet to an ejb. Ejb is a
horrible thing most of the time, detraccting ffrom developers from
solving the business problem with unnecessary clutter just to work with
JNDI, catching countless exceptions and so on. At least frameworks like
Spring helps us to address many of these nasties.
Why or how do webservices add value to the rpc ? Is there any need to
slow things down, add more config files (WSDL etc) ? THere is no need
for an xml format between what is essentially two parts of a
distributed application. Webservices are more suited for communication
between separate distinct applications.
If *YOU* need ejbs then please dont impose such limitations on all of
us, and add the required code to your own customised Servlet - the code
is RpcServiceSerrvlet available. Servlets are the simplest thing
required to implement a service on the server - aka KISS and so are
more than appropriate.
Joseph Ottinger
There is no need to worry about the servlet portion of a RPC. Its
merely an implementation detail. There is no need to touch any of the
stuff thats not related to your interface.
In fact I myself think the best approach is to merely delegate from the
servlet to the real implementation. This only requires a handful lines
of code. Perhaps the reason you wish to be in ejb land is the overly
verbose process of delegating from the servlet to an ejb. Ejb is a
horrible thing most of the time, detraccting ffrom developers from
solving the business problem with unnecessary clutter just to work with
JNDI, catching countless exceptions and so on. At least frameworks like
Spring helps us to address many of these nasties.
Yikes! EJB is a horrible thing most of the time? There's a glove and you've just thrown it down. :)
Let's get the valid criticisms out of the way, first. EJB is verbose, yes. But there's a very valid business problem to solve with them, and I'd challenge you to find a way to elegantly work around them - even with Spring, which is *just* as verbose if you replicate what an EJB does. The difference is that Spring puts *all* of the configuration on the developer, whereas EJB is meant to be configured by a deployer, who presumably knows specifically what production configuration is needed. (And yes, I know, a deployer can override the spring XML configuration with a production version... but then you're right back at what people whine about with EJB.)
EJB is not a "light" technology as Spring is. No doubt there - but you're doing a good job of throwing the baby out with the bathwater. Plus, EJB3 addresses most of the criticisms aimed at EJB 2.1 and earlier, including the verbose deployment/build process.
I'm just as guilty of assuming things about peoples' needs as anyone else is, but hopefully I've learned enough to not say that "X s inappropriate for you" without sufficient knowledge of "you" and "X." Even Rod says that EJB has a valid purpose, but that people overused it, and I entirely agree with him.
Why or how do webservices add value to the rpc ? Is there any need to
slow things down, add more config files (WSDL etc) ? THere is no need
for an xml format between what is essentially two parts of a
distributed application. Webservices are more suited for communication
between separate distinct applications.
If *YOU* need ejbs then please dont impose such limitations on all of
us, and add the required code to your own customised Servlet - the code
is RpcServiceSerrvlet available. Servlets are the simplest thing
required to implement a service on the server - aka KISS and so are
more than appropriate.
I agree here - it's not difficult to make the RPC a proxy for the EJBs, and that's probably an appropriate architecture in any event.
ash
to respond to some of your statements.
> But the RPC mechanism really isn't that well thought out. The problem
i actually believe the opposite. i think gwt-rpc is very well thought
out, in fact i have not come across anything else that parallels its
simplicity, features and weight. it has the lightness of xml-rpc,
richer than hessian with polymorphic-rpc and a transparent dynamic
proxy created at compile time via the factory for trivial invocation.
the only thing that most jee guys in this group would change is make
the rpc server more pluggable. see the spring the GwtHandler
implementation by george (refer
http://groups.google.com/group/Google-Web-Toolkit/browse_frm/thread/174451f1874c6388/221ac23bce91e5dd?lnk=gst&q=gwthandler&rnum=2#221ac23bce91e5dd)
> is that it uses servlets. Servlets are old, but great at handling
> sessions and HTTP-interface stuff. However all thats done transparently
> by GWT, so I'm left with a RPC call that I need to handle from within a
> Servlet (of all things). What should I do with that Servlet? Setting
> HTTP headers and serializing is allready done nicely for me by GWT.
the current implementation requires that the rpc impl be a servlet.
some of us who are anal (incl. me) about separating concerns have
implemented various server-side extensions. however, i suspect the gwt
community has a smallish server-side java sub-community. there are many
folks here that are doing stuff with xml-rpc and json-rpc; remember
gwt-rpc is currently the only java-server-side component in gwt.
> Basicly I have no use of the Servlet interface. If I mess too much
> around with the Servlet I might even screw things up with the
> Java-JavaScript communication, which really should be hidden from me.
then abstract yourself from it using something like the GwtHandler
extension.
> What I _DO_ need is a way to pass on the RPC call to business code,
r u sure the server side is _all_ pure business logic?
> which - running java - is usually an EJB layer. Of course I can look up
> the EJB from my Servlet and call a business method there. That method
> would be identical to the RPC method I have in my Servlet. So, using
> that approach I end up with an extra layer (the Servlet) with
> absolutely no work to do - just passing stuff through to the EJB layer.
> Thats unnecesary!
first u need to eliminate ejb from this discussion. you and your
project just happen to be wrapping your business logic in ejbs for
various reasons which we need not get into. you could have restated
your issue as "just passing stuff through to the next _layer_".
had u stated your issue like that, i and others would have probably
shared your same experiences without getting into an ejb religous
debate.
however, as i use gwt-rpc more and more, i feel like im discovering a
new sweet-spot for it.
my first set of gwt-rpc looked and smelt like other web-services, just
a different implementation. but after a while i started to detect a
cohesive relationship between some of my client-side controllers and
their associated server-side controller (ie. gwt-rpc impl).
it has taken some time but i now feel that my early gwt applications
did far too much on the client. i find myself now attempting to strike
the balance between client and server responsibilities. playing with zk
and also looking at gwt-jsf has helped to make this clearer.
what im noticing is that if your gwt-rpcs exist to serve your views/and
your view controllers, then you will discover that their interface and
responsibility is different from the business service interface. hence,
it is no longer just passing things through to the next layer.
> What google should do is this: Change the RemoteService from being a
> Servlet to being a Stateless Session Bean. The RPC communication should
> either be a WebService directly to the SessionBean or if thats too
> slow, another approch is a hidden ControllerServlet to bridge the call
> from client to backend.
gwt has introduced a level of simplicity to java that is frankly
refreshing and sensible. the gwt engineers since the initial release
have, and will need to continue to be extremely mindful of the software
mass that they add to gwt. it is very impressive to see how they add
such rich features with minimal/no server-side bindings and no
client-side dependencies.
imho the gwt design principles should be published, promoted and
embraced as these principles are what is separating it from the rest of
the field. i believe the team are engineering gwt in such a way that
promotes 3rd party to add the weight and dependencies (eg. spring
integration) if required.
sure, the current RPC server-side implementation needs some more
evolution and maturity, but it does not need server-side weight and
software mass.
rgds ash
http://www.gworks.com.au
Eric
First and foremost, I don't want to be forced into using an EJB
architecture... which is not appropriate in all cases. Today, we are
developing applications that use Spring as a lightweight container.
Second, I would not want to require that all deployment environments
have an EJB container. Today, we deploy on a standard Tomcat image,
which has no EJB container. I've used EJBs, and as an architect, I'd
like to be able to choose when to use them and when not to.
When using EJBs to implement your business services, I would suggest
you look at your business service design independently from your user
interface (GWT) services. The GWT service is not necessarily a simple
pass-through. It may do a lot more than you expect. We have found that
we often wind up calling multiple business service methods from the GWT
service. Our goal is to make one client-to-server invocation "per
screen".... and to do this, it is often necessary to hit more than one
business service from the GWT service.
-eric
br...@google.com
doc pointers...
ash wrote:
> however, as i use gwt-rpc more and more, i feel like im discovering a
> new sweet-spot for it.
> my first set of gwt-rpc looked and smelt like other web-services, just
> a different implementation. but after a while i started to detect a
> cohesive relationship between some of my client-side controllers and
> their associated server-side controller (ie. gwt-rpc impl).
> [...snip...]
> what im noticing is that if your gwt-rpcs exist to serve your views/and
> your view controllers, then you will discover that their interface and
> responsibility is different from the business service interface. hence,
> it is no longer just passing things through to the next layer.
The GWT doc touches lightly on both perspectives:
<http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.ArchitecturalPerspectives.html>
I'm glad to hear that this been your experience, too. We've found that
in practice it's often useful to think of your GWT RPC layer as the
"server-half of the UI" instead of a totally decoupled web services
layer. Here's why that design works well...
1) Fine-grained RPC interfaces are inefficient. Within reason, having
fewer but bigger payloads takes better advantage of the network. It's
true that when you're designing general-purpose back end services, it's
often appropriate to make their APIs fine-grained, but then exposing
those same APIs across HTTP becomes quite inefficient. IMHO, exposing
fine-grained APIs over the wire was the central problem with the
1990s-style "remote objects" concepts (e.g. DCOM), because in fact you
*do* need to design APIs differently based on the role and proximity of
the caller. With GWT, since you can easily have state in the client,
you can take advantage of that fact by creating an efficient RPC layer
that is tailored for your app's front-end; that RPC layer can then
organize calls to the more general back end business logic, which can
be written using any framework, not just EJBs. So, that hopefully
explains one reason we chose Servlets for the GWT RPC implementation:
because if you do much heavy lifting, you'll probably be calling into a
different back end framework anyway.
2) You can't do cross-domain RPCs anyway. If you're writing big apps,
chances are good that your back end involves a variety of services
running on multiple hosts and/or ports. Due to cross-domain
restrictions in XmlHttpRequest (which also apply to different ports
even on the same host, btw), you would still only be able to call
exactly one host and port. In other words, even if you wanted to make
your RPC back end completely general-purpose, you'd hit this roadblock
anyway. Thus, we designed GWT RPC to be the fastest and simplest
possible way to move objects between client-side code and server-side
code, because only on the server do you have the freedom to stitch
together complex services anyway.
For details on cross-domain restrictions, there's a good article on the
Yahoo! Developer Network:
<http://developer.yahoo.com/javascript/howto-proxy.html>
> imho the gwt design principles should be published, promoted and
> embraced as these principles are what is separating it from the rest of
> the field. i believe the team are engineering gwt in such a way that
> promotes 3rd party to add the weight and dependencies (eg. spring
> integration) if required.
We know that GWT takes a different approach on certain things (RPC,
monolithic compiles, etc.), and it's all intentional. We try to think
super-hard about how to provide functionality that is easy to use, hard
to mess up, easy to build tools for, very scalable, and above all,
highly efficient.
-- Bruce
Eric B
people's replies here, keeping the RPC specification general and not
tied to any specific high level J2EE technology is a good thing. That
way we can customize our backends to work with Struts, Spring, EJB, or
any other new framework that comes out.
Tazly, if you really wanted to do what you're asking without going
through a servlet you could just connect directly with a HTTPRequest
(assuming its on the same server because of the cross-browser
limitation described above). This would also be the work around for
those with PHP or .NET backends. However, I think most developers in
this group love Java like I do and want to stay away from the other
server-side technologies out there.
Thanks,
Eric
Tazly
request, so just to clear things up: I don't mean to tie everybody into
using EJB's. However, I do want GWT to integrate transparently with an
EJB-container.
> We have found that we often wind up calling multiple business service methods from the GWT
service.
And how do you coordinate transactions between those multiple business
calls from within a Servlet (i.e. outside EJB context)? You wrap them
up in a SSB, and call that once from the servlet. So the Servlet is
still just passing through one call.
- Rune
Tazly
The reason I want to be in EJB land is because of the services the EJB
container gives me. Transactions and security for instance. Try taking
a fresh view on EJB's, and not be stuck in old prejudices. EJB3 is easy
to use, annotation-driven and very, very powerful, and most importantly
NOT limited to business problems. EJBs are excelent for solving
UI-problems as Gavin King is exploiting with his SEAM framework.
> Why or how do webservices add value to the rpc?
WS methods are very easy to add to EJB's, so using a WS for remoting
would bypass the Web Container and thereby reducing complexity.
> If *YOU* need ejbs then please dont impose such limitations on all of us
If both EJBs and Servlets were available, we would both be happy.
> Servlets are the simplest thing required to implement a service on the server - aka KISS and
> so are more than appropriate.
I disagree. Servlets are much too complex for the simple task of making
a RPC call. And they only take me half the way into the server. The
developer would have no use for the Web Container if we had GWT+EJB.
- Rune Larsen
mP
serialization process between the browser and the server is already
done ? It doesnt add anything. How do you propose the web service be
implemented on the client in javascript ? The GWT serialisation
protocol is almost json facilitating an efficient and relatively
compact mechanism.
Firstly container role based security can also be configured for
servlets with equivalent declarations within web.xml. Transactions can
also be used outside a ejb container. There is nothing ejb can do that
cant be achieved within a servlet. Sure ejb containers add automatic
transaction management at defined boundaries but the this can easily be
achieved with Spring...Why use EJB3 when one can use the real thing -
Hibernate.
georgeuoa
Dear All
Allow me a few comments.
>And how do you coordinate transactions between those multiple business
calls from within a Servlet (i.e. outside EJB context)?
That's why we like Spring so much. You can wrap service methods into
automatically managed transactions, which includes propagation. Of
course, that won't work if you percieve a set of RPC calls as a single
('long') transaction (for example an RPC for the query, a 2nd RPC for
some update, a 3rd RPC for showing the results).
> Firstly container role based security can also be configured for
servlets with equivalent declarations within web.xml
Unless I'm mistaken that security is then grained on the service level.
With acegi & spring for example you can go as detailed as specifying
access constraints to individual methods of a service, taking into
acount event the actual values of their arguments and session content.
Eric
> And how do you coordinate transactions between those multiple business
> calls from within a Servlet (i.e. outside EJB context)? You wrap them
> up in a SSB, and call that once from the servlet. So the Servlet is
> still just passing through one call.
There are many ways to do this. You could use the UserTransaction to
manage the transaction boundary yourself. But in many cases, this is
unnecessary, because having multiple transactions isn't a problem.
Let me give you an example. We have a List of Users screen, and on this
screen is a Create User button. Clicking on this button leads to a new
screen, which has a form with required information about the new User
and a Create button. When the Create button is pressed, the use case
says that the User is created and the List of Users screen is
re-displayed, to include the new User.
There are two business service methods that are involved here. The
first is createUser(User). The second is getListOfUsers(). That's a
fairly straight-forward way to design our business services, and it
could map cleanly to an EJB SSB (we don't use EJB, but the idea is the
same).
We could have chosen to implement a simple pass-through GWT service,
and proxy the createUser() and getListOfUsers() methods. But in doing
so, our use case above would have to make these two calls, in sequence.
Create the user, then fetch the updated list of users. That violates
our goal of having just one client-to-server invocation per flow. So,
we created a GWT service method createUserAndGetListOfUsers(). This GWT
service first calls the business service createUser() and then
getListOfUsers(). Since the second call is read-only, there is really
no need for a single transaction spanning both calls. If we had had the
need to coordinate multiple updates, it is likely we would have used
the Session Facade pattern to put this into the business service layer.
-eric
claude
I have no problem with GWT supporting EJB, but please, oh please, do
not ever make it compulsary to have an EJB container involved. My
personal observation and experience is that the elegance of Spring has
a clarity of purpose that has yet to be matched in the EJB
specifications (and there have been many false starts). In effect,
Spring would have never come into being if it didn't address tangible
problems with EJB. That being said, there is a place for EJB and
support is always a good things, though I'm not convinced anything
specific is required other than looser coupling in GWT, such that
things can be wired using different idioms, as may be required from
time to time on the server.