We've got a few java apps and will have more as time goes on. We'd like to be able to use the business services that the apps provide within an overall SOA that will also include VB apps, COBOL programs etc.
The java apps are layered as you'd expect with presentation, business/domain & data access layers, but we've gone for using POJOs (& Spring framework) rather than EJBs.
It looks like the easiest / most standard way to use these in an SOA is to create a new set of objects, lets call them WebServiceFacades, to wrap the business objects and expose their functionality via coarse-grained methods. (The original business objects may well have fine-grained methods at the moment as they're only used locally.) We can then run the tools on the WebServiceFacades to create the WSDL, and then the dd & mapping files. Finally we can package all the app code up in a jar / war, then an ear & deploy it on the server (WebSphere).
My boss is hung up on the idea of only having one instance of the code in production (not counting clusters). Is this something we should worry about? The code is source controlled, so I can see how we could manually manage different copies of the same app in production. If the webservice code is deployed together with the webapp code, we'd only ever need one instance in production.
Is this the 'correct' way to go about it? Can an ear contain code that acts as both a web service & a web app or does it have to be defined as one or the other?
I've seen plenty of low-level technical docs on web services (though limited experience) & plenty of high-level architecture SOA docs, but not much in between. What would be good is a code design-level description of how to make java web apps work in an SOA...
Joined: Apr 04, 2002
Can anyone advise? Have I gone completely off track?