Actually, SOA with servlets and JSPs is standard.

Think of it as the phrase, "service-oriented architecture", not the acronym,
"SOA".  You can write to a service-oriented architecture in BASIC, let alone
Java, let alone using SOAP or BPEL.  The point is to write your components as
services, and have them communicate through a service-to-service communication
layer.

When you do it from a web application, that makes it a web service.  No
mention yet of SOAP.  But now that we have mentioned SOAP, it might be the
fastest way to a fully-functional prototype.

First, write a conventional web app using JSPs, a servlet and Java logic to
invoke a service.  This service will be called by direct function calls from
some logic invoked by the controller servlet.  No SOAP.  But the service class
needs to be independent, preferably defined by an interface with an
implementing class that the client logic cannot see.

Example:

package example.soa.service;
import java.util.Collection;
import example.soa.model.Good; // an interface
public interface WarehouseService
{
  public void stash( Collection <Good> goods );
  public Collection <Good> retrieve();
}

Then you cheat.  You run Java2WSDL over the interface to create a WSDL.
Eclipse and NetBeans both do this automagically for you, I believe.  Otherwise
you get it from the Axis project.  Then you run WSDL2Java over the WSDL to
generate client and proxy stubs for a client.  Next you write a cover class
that invokes the Locator, retrieves a local instance of the interface type
that actually calls the proxy, and then simply calls the methods of the interface.

Finally, you create a client web project that uses the URL of the server web
project to fulfill its logic requests.  The JSP view page(s) can be
near-clones of the JSPs from the server-side "direct" application.  (Change
the titles to confirm that you're viewing from the client.)

I'm waving all sorts of magic wands here.  There is a learning curve, which
the IDEs can help you gloss over.  You have to get all the right JARs into
your project library (deployed WEB-INF/lib/ directory).  Still, about a week
of dedicated practice should get a crude but deployable and runnable prototype
going.

Truth to tell, just constructing the services as independent interfaces with
hidden (i.e., package-private or quieter) implementor classes, preferably
instantiated through a (configurable) factory class, already has you in a
service-oriented architecture.  That's what makes it easy to break up the
calls across a web-app-to-web-app communication gap.  A local class implements
the interface via direct calls, a remote one via proxies and stubs.

Plus you can probably get partial credit for the local implementation of a
true SOA even if you fubar the remote implementation.

Having a working local version lets you know better where a broken remote one
is actually not working.  Sensible separation into layers has already
happened.  You can ask focused questions in Usenet, because remoteness issues
will have been teased away from all others.

One practical basis for SOA is to think, always, interface-wise.