xml-soap-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Symons" <gsym...@researchfed.com>
Subject RE: SOAP & servlet model parallels
Date Wed, 05 Jun 2002 15:53:04 GMT
I'm kinda new to SOAP myself, but my understanding from my reading in
"Professional XML Web Services" from Wrox (ISBN:1-861005-09-1) that the
best way to do this is to actually just create a class that implements
the Provider interface and use that as a custom provider for your SOAP
service. I haven't totally looked into what's involved, but looking
briefly at the docs, it seems that would be an easier way to do it,
since you can leave the RPCRouter alone, and let it extract all the call
data out of the envelope and then pass it to your provider. Of course
that'd mean you'd have to embed any security information into the SOAP
call itself rather than using protocol level authentication, but that
also seems more extensible and flexible to me anyway.

|                                  \
|  Greg Symons                     /
|  Systems Analyst                 \
|  Research Federal Credit Union   /
|  (586) 264-8710 x1234            \

-----Original Message-----
From: Erich Izdepski [mailto:eizdepski@cysive.com] 
Sent: Wednesday, June 05, 2002 9:46 AM
To: soap-user@xml.apache.org; puff@darksleep.com
Subject: RE: SOAP & servlet model parallels

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