This discussion is archived
3 Replies Latest reply: Jan 2, 2013 2:25 PM by vladodias RSS

Enterprise Data Store: Import to App or Integrate over Services?

915023 Newbie
Currently Being Moderated
We have a department specific application we are building. It is used to refer doctors and also create and book classes for patients at one of many possible locations. The doctor profiles and attributes as well as our locations are stored in an enterprise data store. The initial thought was to use services when accessing doctor information or a location being used for a class. The issue is, that the application requires joining against a doctor record when pulling up classes or historical patient calls. To a new SOA developer/architect, it does not fit in the model to use services to handle this. That a purpose built application that specifically operates on doctor and location data should have a local copy of that data.

Looking for seasoned feedback. Thank you.

*[ more thoughts if needed ]*
It doesn't make SOA sense to me to store the key of the doctor or the location in the apps database for reference in services because then you are no longer loosely coupled. It makes more sense for our coming WayFinding system that it would use an enterprise service to get locations or doctors since it is only representing data and not operating on it.
  • 1. Re: Enterprise Data Store: Import to App or Integrate over Services?
    vladodias Guru
    Currently Being Moderated
    Hi,

    Other questions to be asked are:

    - How often will the data be accessed?
    - Does it work for your business to have data replicated in a D-1 fashion? Or it is critical to have up-to-date information? The latter will make replication strategy get complex?
    - requires joining against a doctor record when pulling up classes or historical patient calls why this doesn't fit? Please explain...

    Cheers,
    Vlad
  • 2. Re: Enterprise Data Store: Import to App or Integrate over Services?
    915023 Newbie
    Currently Being Moderated
    Vlad,

    Thanks for your response. I responded to your questions below.

    - How often will the data be accessed?
    ---- On a constant basis during normal business hours. This is a call center.
    - Does it work for your business to have data replicated in a D-1 fashion? Or it is critical to have up-to-date information? The latter will make replication strategy get complex?
    ---- It's critical to have up-to-date information. (I'm not familiar with the term "D-1").
    - requires joining against a doctor record when pulling up classes or historical patient calls why this doesn't fit? Please explain...
    ---- If the physician data remains in the enterprise database and made available through services, then we need to keep the PK of the doctor record in the applications own database as a FK. Doesn't that present data integrity issues? You can't cascade changes from one server to another if that doctor's record was, say deleted.

    Thank you.
  • 3. Re: Enterprise Data Store: Import to App or Integrate over Services?
    vladodias Guru
    Currently Being Moderated
    sniperd wrote:
    - How often will the data be accessed?
    ---- On a constant basis during normal business hours. This is a call center.
    Access to local replicated data typically performs better than web service calls... point to data replication...
    - Does it work for your business to have data replicated in a D-1 fashion? Or it is critical to have up-to-date information? The latter will make replication strategy get complex?
    ---- It's critical to have up-to-date information. (I'm not familiar with the term "D-1").
    One possible solution would be to have a job to copy data every night, so you would have a copy up-to-date until last night, changes performed on the current day would be inaccessible... If that approach is not good enough, you will need to put in place a complex data replication solution to get up-to-date information replicated in near-real-time... for me this is a very strong point to services...
    - requires joining against a doctor record when pulling up classes or historical patient calls why this doesn't fit? Please explain...
    ---- If the physician data remains in the enterprise database and made available through services, then we need to keep the PK of the doctor record in the applications own database as a FK. Doesn't that present data integrity issues? You can't cascade changes from one server to another if that doctor's record was, say deleted.
    None of the approaches will solve that problem... either data replication or a service oriented approach will suffer from that... If you have a doctor record deleted on the enterprise database you have a problem because you can't replicate the exclusion on the local database, that will create integration issues and make a replication approach yet more complex... As for having doctor's PK in apps database, I don't see any other way around but having a doctor identifier shared in both databases, PK is a database concept, when we think in services you may not need a PK, but surely you need to share some ID among implementations...

    Hope this helps...

    Cheers,
    Vlad

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points