locked
SOA - Autonomous/Coupling Question - Location of functionallity RRS feed

  • Question


  • Hi forum  

    We have several applications that have services. These services are primaraly made for use from external developers.

     

    We are now creating a scheduler application. Here you setup tasks that call services in multiple applications.

     

    Some of the applications already contact each other. So there are peaces of integration between them.

     

    The primary purpose of the scheduler application is integration between the applications. The scheduler application should be able to run tasks just like windows scheduler. In time - many different tasks will be developed. A task can call multiple services in multiple applications - but also just one.

     

    Sometimes we would be able to re-use some of the integration already existing between the applications. But I'm not sure it is a good idea.

     

    Here is an example with 3 applications.

     

    1. ERP Application (ERP)

    2. CRM Application (CRM)

    3. Scheduler Application (the new one I'm making)

     

    I have created some methods to illustrate the issue below. Entries are written to a CRM app and another type of entry is created in an ERP app. The entry that is create in the Erp app holds an Id of the newly created entry from the crm app)

     

    Crm.CreateEntrysLocally(Entry[] entries)

     

    Crm.CreateEntrysLocallyAndCreateEntrysInErp (Entry[] entries)

    This method calls the local CreateEntrysLocally and Erp.CreateEntrysLocally. The CreateEntrysLocallyAndCreateEntrysInErp method holds some compensating programming that handles clean-up if the last call fails. We cannot use transactions between the applications. So I do not gain any transaction support.

     

    Erp.CreateEntryLocally(AnotherKindOfEntry[] entries)

     

    Now I'm creating a scheduler application. I want a task to (amongst other things) create an entry in both applications. The question now is. Do I use the Api for each application or do I call the Crm.CreateEntryLocallyAndCreateEntryInErp method. The Tenets of service orientation state that services should be Autonomous. Would this violate this tenet.

     

    The Crm.CreateEntryLocallyAndCreateEntryInErp method does hold some programming that I would have to do again. It also saves a little network trafic since I would need to first get the ids of the newly created entries in the CRM system and then add them to new entries which I would then create in the ERP system.

     

    The same task might require that I call the ERP application 10 times anyway - because the integration through the CRM application might not be enough to perform the task. I would just call Crm.CreateEntryLocallyAndCreateEntryInErp to save a some programming. If I do not call it one could reason that I would be making the same programming in 2 places - and thereby possibly getting issues with needing to correct things several places.

     

    Should I make a clean break between the scheduler application and call things diretly in each app, or should I utilize methods like Crm.CreateEntryLocallyAndCreateEntryInErp - or should I even try to focus more on building methods like Crm.CreateEntryLocallyAndCreateEntryInErp so I can also provide this fuctionallity in the applications APIs.

     

     

     

    I hope someone has some input on this because I'm having a bit of difficulty in seeing clearly here.

     

    Siteadm

    Thursday, February 15, 2007 9:19 PM

Answers

  • it looks like you are trying to build a kind of router / broker application. You don't have Biztalk? that's the easiest way to accomplish this kind of functionality, but you can make it yourself... take a look at the Webservice security guidance there are some topics in it you must think about. Good luck

    Saturday, February 17, 2007 7:47 AM
  • Do you realise with the what you describe above that your ERP system is tightly coupled to your CRM system, this is because the CRM system has to know about the ERP system for the method 'CreateEntrysLocallyAndCreateEntrysInErp'. This is a dependence that you want to avoid.

    It sounds as though to me you have a set wrokflows that you want to run on a periodic basis or a data driven basis. As suggested you require the use a controlling system that submits message to your components and controls the overall process. There are several technologies available for this as well developng your own implementation. MS technologies include BizTalk, Windows Workflow Foundation (WWF).

    If you starting thinking about a system has as a set of components that you interact with by submitting messages too then you will start to think about component\service seperation and the benefits that can be gained from this. Take a look at the SOA  (Service Orientated Architect) paradigm for more understanding of component\service seperation.

    Having components\services that react to messages is the key IMO.

    HTH

    Ollie Riches

    Saturday, February 17, 2007 12:10 PM
  • Hi,

    I agree with Clemens. This is an ideal scenario for Biztalk. Try to avoid direct coupling between your ERP and CRM system. Build a sevice layer aroud your ERP and CRM and connect them with Biztalk. If you would have other apps connecting to your ERP, you can reuse your biztalk services aroud the ERP. Keep your integration on a separate layer, don't start with point to point, because that's what your building now, using services.

    Hans.

    Sunday, February 18, 2007 12:25 PM

All replies

  • it looks like you are trying to build a kind of router / broker application. You don't have Biztalk? that's the easiest way to accomplish this kind of functionality, but you can make it yourself... take a look at the Webservice security guidance there are some topics in it you must think about. Good luck

    Saturday, February 17, 2007 7:47 AM
  • Do you realise with the what you describe above that your ERP system is tightly coupled to your CRM system, this is because the CRM system has to know about the ERP system for the method 'CreateEntrysLocallyAndCreateEntrysInErp'. This is a dependence that you want to avoid.

    It sounds as though to me you have a set wrokflows that you want to run on a periodic basis or a data driven basis. As suggested you require the use a controlling system that submits message to your components and controls the overall process. There are several technologies available for this as well developng your own implementation. MS technologies include BizTalk, Windows Workflow Foundation (WWF).

    If you starting thinking about a system has as a set of components that you interact with by submitting messages too then you will start to think about component\service seperation and the benefits that can be gained from this. Take a look at the SOA  (Service Orientated Architect) paradigm for more understanding of component\service seperation.

    Having components\services that react to messages is the key IMO.

    HTH

    Ollie Riches

    Saturday, February 17, 2007 12:10 PM
  •  

    Hi Ollie and Clemens

    The operations can be automatic. But they can also be.

    Is this something like what you are suggesting? Click the link. I have made a picture of a visio diagram and put in on My Space.

    http://tkfiles.storage.msn.com/x1ppUPyqopddk6CQ9nYZrZQklzqYvUYuorlmT4PiIXtzw9KXSibmc_jky8MUhCkTxS1vSLi3QKP6-5h9y-khgrS1cijSXzCU6m2NtfFV2fCV11A7awiRybxkaP3m9hxOtxA52dzygqM50tTTSwxR6hr_w

    Should the front directly talk to a work flow engine when calls are made that integrate multiple services? or would you always communicate from the front end with the work flow engine?

    I'm guessing it would be best to let the front ends call services in various systems and not use service agents located on the data tier behind the services?

     

    Siteadm

    Sunday, February 18, 2007 9:30 AM
  • Hi,

    I agree with Clemens. This is an ideal scenario for Biztalk. Try to avoid direct coupling between your ERP and CRM system. Build a sevice layer aroud your ERP and CRM and connect them with Biztalk. If you would have other apps connecting to your ERP, you can reuse your biztalk services aroud the ERP. Keep your integration on a separate layer, don't start with point to point, because that's what your building now, using services.

    Hans.

    Sunday, February 18, 2007 12:25 PM
  •  

    Hi Hans

    Thank you for answering my post.

    I actually have a service layer. But it might not be in the sense you mean.

    The N-tier applications have the following architecture. (Click the link to see a picture of a visio diagram)

    http://tkfiles.storage.msn.com/x1pppQPzd7N2QxBQ4ZJX1ILBxCWWcDpzdXorj-NvVNX5ganwoWp-REQ4z8ccE-WHCEfRVpIpdZLOirY3hsSS8EgvYclPvY_5gkNyzeZzGQIHsA

    I need to get in from external applications and have the services in the application above participate in business ”transactions”.

    Where would you put in the Biztalk server?

    Could I not make something using Windows Workflow Foundation so I can avoid the Biztalk server? (I need a solution quite soon. I afraid I won't have time to get into Biztalk server before I need the functionallity.)

    Sunday, February 18, 2007 6:01 PM