We have a big project here. It doesn't involve integrating existing software, but does involve a lot of parts that I think could best be written as web services so that they can be reused by other parts of the business, etc. Is it good to break up a project into services or is SOA better when you are trying to integrate things that aren't meant to go together or stuff that has remote components, etc. Basically, what I'm saying, is that I could put all this stuff into nicely organized java code, or I could break it out into services, and I don't know which to do.
I think the answer is that you should keep on writing your application like you always did. Write a tiered application, and make sure the business logic ends up in the (stateless) middle tier. Now this middle tier will exist of EJBs or POJOs. Next you will have to do two things:
1. Turn them into a service.
2. Register the service with the ESB.
There are multiple ways to go about achieving the above:
Use EJB annotations to turn your POJO into an EJB. You can now register the EJB with the ESB by writing a custom action which calls the EJB. This is demonstrated in the bussines_service quickstart. The action receives a message, some objects can be pulled out and used to send to the EJB. The return value of the EJB can be used to update the message.
Add JSR-181 annotations to bring up a WebService. Now if you do this using JBossWS something cool happens. If the ESB runs on the same instance it auto-discovers these services and registers them with the ESB. Now can can send a soap message to a gateway and the ESB will forward this message to your WebService. So, for example, you can now send SOAP messages in a file to an ftp server. See the webservice_producer quickstart.
If you have used seam to build your app, you can take take a look at Michael Yuan's write up called "Seam-and-SOA" when he attended a JBESB training earlier this week. Also we have an integration example with the Seam DVD store that Burr created. Be on the lookout for this to become a quickstart too.
Use Spring annotations to turn your POJO into a Spring enabled POJO. Now write a custom action to call the bean. See the Spring_OAP quickstart.
I hope this demonstrates the pattern. To be clear on why you should take the extra step to register your service to an ESB, this is to obtain capabilities like routing to multiple destinations, content-based-routing, message transformation, service orchestration (jBPM or BPEL), service-human workflow integration (jBPM), bringing up services over different protocols (ftp, file, etc). I guess that list is pretty well documented on the project page.