C# : Strategy for mapping/storing business id


I'm creating 3 services, let say : A/B/C

A has some business reference to C and vice versa.

So the B service has it owns database and it owns service that "speaking" with both A and C service.
Is it a good design/approach to do that or does it exists a generic pattern/strategy to apply for such situation?

Thanks in advance,

Kind Regards.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AndyAinscowFreelance programmer / ConsultantCommented:
After reading your question I must say I do not understand what you want to do / what your current situation is.
Please supply more detail and possibly a diagram.
Dnx_7Author Commented:

Look at this scenario :

Service A : intranet
Service B : intranet/automation
Service C : automation

Service A only holds intranet concept and has no idea about automation.
Service C holds a reference to some table in automation system.

That's why, actually, my strategy is to create a third service (B) to aggregate results from the intranet AND automation/
eg : a user is created in the intranet (A) and has a unique id, this unique id is propagated into the automation service (C) as a business id.
so to have full information about a user + automation information, we request to service B. This one will request to both service to aggregate result to a "AutomatedUser".

More clear?

AndyAinscowFreelance programmer / ConsultantCommented:
That looks to be a sensible approach.
Let's consider other real world applications

Suppose I have an HR application (Application A)  and I have several other smaller homegrown applications (Application B, C, D, E, etc.).   These homegrown apps may allow users to update their own profile, lookup/log vacation days, search for coworker emails / job titles / etc, or even have some kind of org chart app.

If Application A (the HR application) is fairly robust it may have its own message broker / web services to allow reading/writing to the HR app.   However this is not always the case and even if it is, many organizations choose to have *ALL* cross-platform messaging handled through a single central messaging point.

This is what WebSphere Message Broker (WMB) was built for. WebSphere scales to handle millions of transactions across hundreds of applications per hour.

So... back to your question:  "Does creating a third web service to act as a translator between two distinct web services make sense?"   The answer is an emphatic "YES"

The real trick is to create the third web service in such a way that should you want to create more web services you should be able to simply plug them into the message broker service you are creating now.  You don't want to have to create a new translation web service every time you want to connect two services together.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dnx_7Author Commented:
Nice explanation! Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.