xml-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erich Izdepski" <eizdep...@cysive.com>
Subject RE: SOAP & servlet model parallels
Date Wed, 05 Jun 2002 13:45:34 GMT
You can extend the soap rpcrouter and direct all calls to your new class,
providing a point to put in whatever other processing (your authentication,
needs, perhaps) you might want.

Erich Izdepski
Senior Software Engineer
Cysive, Inc.

-----Original Message-----
From: Steven J. Owens [mailto:puffmail@darksleep.com]
Sent: Wednesday, June 05, 2002 4:25 AM
To: soap-user@xml.apache.org
Subject: SOAP & servlet model parallels


     I'm quite familiar with the servlet world and I'm getting into
SOAP.  I have to say, the general idea of SOAP seems quite natural and
right to me, and I'm happy to see it taking off the way it has.  I'm
also quite impressed by Apache SOAP, so far.

     In considering how to structure applications that are heavily
SOAP-oriented, I'm starting to see a lot of parallels between the two
models.  I look at solving a problem and I feel like, "well, in the
servlet world I'd solve that with foo... so where's the equivalent in
the Apache SOAP world?"

     In the past, I've been involved with projects where a lot of the
fundamental structure of the application was built by somebody who
didn't really know the servlet model, and hence reinvented a lot of it
in the process.  Sometimes this lead to advantages, but it also added
work, added cognitive overhead in learning and working with the code,
made it less standard, and made it harder to plug into new tools and
innovations as they came along.  I hope somebody here can steer me
in the right direction, to avoid that sort of mistake.

     Some specific examples...

     A typical/straightforward SOAP application boils down to SOAP
calls, encoding types, and SOAP handlers.  Assume, for the sake of
argument, that you're using the default encoding types.  You define
the types of messages and you set up the SOAP server's configuration
to field each message type off to an appropriate handler.

     So far, so good.  Now what my actual application needs, beyond
the SOAP communication layer, is a configurable rules scheme where a
request is processed according to a configuration file, and an
appropriate class gets instantiated and invoked to handle the
request...hey waitaminnit, that looks an awful lot like the whole
Apache SOAP setup.

     So why don't I just use that to do it?  That way I can use Apache
SOAP not only to define the pipe/wire, but also to define the larger
structure of the application itsef, and I'm using more standard code,
implementing less on my own, and making the system easier for somebody
else who's familiar with SOAP to manage.

     Only problem is, I need to configure some sort of security
scheme, so each request gets checked for authentication before being
fielded off to a request-specific handler.  In the servlet world, as
of spec 2.3, that's done with filters - providing this sort of
cross-cutting processing is the whole reason for filters.  Is there a
filter equivalent in Apache SOAP?

     In the pre 2.3 servlet world it was done using a single front-end
servlet using a RequestDispatcher to field requests off to other
servlets.  This avoided the overhead of a browser redirect, and
provided convenient mechanisms for adding state to the request at each
step of the process.  Is there an equivalent to the RequestDispatcher
in the Apache SOAP world?  Can I have messages get bounced around to
internal SOAP handlers/servers without paying the overhead of
serializing out to XML and reparsing repeatedly?

     As part of that front-send servlet strategy, some sort of
security realm configuration would be used to keep the other servlets
from being publically accessible.  Is there any sort of
server-configurable security scheme for doing something like that in
Apache SOAP?  Would I just the Jakarta security realm stuff to secure
SOAP pieces?

     Come to think of it, when I install the Apache SOAP server, it
comes with an administration interface.  Is there anything in SOAP
itself to secure that, or do I just need to use the Tomcat security
realm stuff to secure it?

     I hasten to point out that I can think of a variety of ways to
code a system to do all of this; a singleton-ish security manager
class that gets invoked by all of the handlers I write, for example,
and an similarly just using a single handler for all messages, that
single handler walking an XML file and using reflection to instantiate
an appropriate class and invoke it.  I'm interested in finding "the
Apache SOAP" way (or even just "the SOAP way") to do it, or at least
in definitively figuring out that there is no "Right Way" before I go
off and invent a lot of code that has to be understood and maintained.

Steven J. Owens

"I'm going to make broad, sweeping generalizations and strong,
 declarative statements, because otherwise I'll be here all night and
 this document will be four times longer and much less fun to read.
 Take it all with a grain of salt." - Me

View raw message