How to design service that can provide interface as JAX-WS web service, or via JMS, or as local meth
- by kevinegham
Using a typical JEE framework, how do I develop and
deploy a service that can be called as a web service
(with a WSDL interface), be invoked via JMS messages,
or called directly from another service in the same
container?
Here's some more context:
Currently I am responsible for a service
(let's call it Service X) with the following
properties:
Interface definition is a human readable
document kept up-to-date manually.
Accepts HTTP form-encoded requests to a single URL.
Sends plain old XML responses (no schema).
Uses Apache to accept requests + a
proprietary application server (not servlet
or EJB based) containing all logic which
runs in a seperate tier.
Makes heavy use of a relational database.
Called both by internal applications
written in a variety of languages and
also by a small number of third-parties.
I want to (or at least, have been told to!):
Switch to a well-known (pref. open source) JEE
stack such as JBoss, Glassfish, etc.
Split Service X into Service A and Service B
so that we can take Service B down for maintenance
without affecting Service A. Note that Service
B will depend on (i.e. need to make requests to)
Service A.
Make both services easier for third parties to
integrate with by providing at least a WS-I style
interface (WSDL + SOAP + XML + HTTP) and probably
a JMS interface too. In future we might consider
a more lightweight API too (REST + JSON? Google
Protocol Buffers?) but that's a nice to have.
Additional consideration are:
On a smaller deployment, Service A and Service B
will likely to running on the same machine and it
would seem rather silly for them to use HTTP or a
message bus to communicate; better if they could
run in the same container and make method calls to
each other.
Backwards compatibility with the existing ad-hoc
Service X interface is not required, and we're not
planning on re-using too much of the existing code
for the new services.
I'm happy with either contract-first (WSDL I guess)
or (annotated) code-first development.
Apologies if my terminology is a bit hazy - I'm
pretty experienced with Java and web programming
in general, but am finding it quite hard to get up
to speed with all this enterprise / SOA stuff - it
seems I have a lot to learn! I'm also not very used
to using a framework rather than simply writing code
that calls some packages to do things.
I've got as far as downloading Glassfish, knocking
up a simple WSDL file and using wsimport + a little
dummy code to turn that into a WAR file which I've
deployed.
