In mission critical systems it is important to design with redundancy in mind. JBossESB 4.2.GA will be the first version with build-in fail-over, load balancing and delayed message redelivery to help you build a robust architecture. When using SOA it is implied that the Service has become the building unit. JBossESB allows you to distribute service instances across many nodes. Each node can be a virtual or physical machine running one or more instances of JBossESB. In this article it is shown how you can go about setting up Distributed Services, Protocol Clustering, Fail-over, Load Balancing and Message Redelivery.
--Kurt
Thursday, August 23, 2007
Saturday, August 4, 2007
Services, services, services
A really good discussion to a nice post from Kurt on where to start with service development. The advice differs from what I said in an earlier post, but as you'll see from the comments to Kurt's post, they're not mutually incompatible. Taken together, they represent the top-down and bottom-up development approach I mentioned:
You can develop these two aspects sequentially or concurrently (even by different teams, which allows each team to concentrate on the right skill sets needed for each role). This is an aspect of what's traditionally called the service lifecycle part of governance. It isn't easy to get it right first time without appropriate tools and patterns. Plus experience helps a lot here: even with tools/patterns, you'll find it easier to do the more you do it.
- top-down (business logic development): do as Kurt suggests and develop your business logic using whatever tools and methodologies you think are appropriate. From a high level perspective, this is as critical to your success as ever.
- bottom-up (service development): do as I suggest and think about the contract you want your service to expose and how that would map into message exchanges (content, sync versus async etc.); try to keep it as agnostic to the backend business logic implementation as possible (e.g., don't go exposing individual objects on to the bus). The service is your route into SOA: get it right and you'll be able to leverage all of the benefits the industry keeps pushing.
You can develop these two aspects sequentially or concurrently (even by different teams, which allows each team to concentrate on the right skill sets needed for each role). This is an aspect of what's traditionally called the service lifecycle part of governance. It isn't easy to get it right first time without appropriate tools and patterns. Plus experience helps a lot here: even with tools/patterns, you'll find it easier to do the more you do it.
Thursday, August 2, 2007
How to design new services? Best practices.
If you have existing applications out there that need integration, then the problem space is fairly well understood. But what if you you are building a NEW application? Here is a question I received:
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:
EJB
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.
WebService
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.
Seam
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.
Spring POJO
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.
--Kurt
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:
EJB
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.
WebService
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.
Seam
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.
Spring POJO
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.
--Kurt
Subscribe to:
Posts (Atom)