So, maybe this is a case where I should go for a SOA?

Question

Scenario: I have a CRM system, and my app. When a new order is created in the CRM system, myApp should do some stuff (create a project room for the order), and write something (project room url) back to the CRM system.

So I could easily implement this using a point to point integration, myApp host a service that, when finished with stuff, calls a service in the CRM.

Question is: Should I go for the extra effort of adding some service bus (extra code, extra maintaince) or is it not a suitable case? The company has no service bus today, and no integration strategy at all.

In case of a 'yes' to the above question (I'm sort of expecting that) what is the extra time I should estimate for including, say nServiceBus or rhino-service-bus ((never tried either of them), into the scope? Do you have any recommandations on other esb's, or a case study I could read?

Thanks for any help

Regards

Larsi

Answer 1

The question is whether or not it's a business event that other systems may care about. If I take the case of new customer, perhaps the marketing system sends them an email and the ordering system then starts processing the order.

If that is something you can see happening, I would then use the push pub/sub model (http://www.eaipatterns.com/ObserverJmsExample.html) using nservicebus. All you have to do is build a handler to listen for a new customer message for each applicaton that cares and then in that method, do your thing.

Also.... what you're doing is moving to SOA but you need several more things to be SOA. SOA is architectural philosophy. The pub/sub that we're talking about is more of using MoM.

Answer 2

If you are thinking about moving to an SOA architecture the first thing to consider before making communication decisions is your service boundaries. If your app owns the implementation of a particular business capability, meaning it specifies business logic and is the authoritative source of data for that capability, then it should be its own service. If, however, your app is simply providing helper functions to the CRM system, then in SOA terms your app and the CRM would both be part of the same service.

Start by reading this short post: http://fafach.wordpress.com/2011/04/20/soa-what-is-a-service/

Then check out this excellent introductory SOA video: http://www.nservicebus.com/ArchitecturalPrinciples.aspx

Answer 3

You should distinguish between to major aspects of SOA

one is having services, which is mostly a design issue. in a nutshell it means that the service should be a commodity, and not custom made for the specific client you plan for..

the second aspect is the infrastructure - which may include and ESB

If you have a single service, or a small number of services, you can use simple web services (without an ESB or other infrastructure) and still get all the benefits of SOA. When the project grows, adding an ESB won't be much harder than adding one now.

on the other hand, redesigning the interface of the service when adding more clients is a hard process if you have existing clients that are hard to modify