0

I want to build an API (services box/ESB) with the purpose of interacting with our internal systems. (ERPs, Product Information Management System, OMS, etc.)

I have the opportunity to do it on the same architecture of one of ERPs. It's financially wise but I fear it could be bitting us in the butt later.

My other option is to build it on a standalone infrastructure that will be completely independent.

Based on SOA principle and architecture best practices, should I build it on our ERP server or in a standalone cluster?

Uffe
  • 10,396
  • 1
  • 33
  • 40
Stephane Leduc
  • 1

2 Answers2

0

In recent times,there have emerged two trends for ESB ,one being federated ESB ,other being singular ESB.

If it's a single ESB which is being planned ahead, the concept of Separation of Concerns fits in well here . orchestration ,choreography,service discoverability become better when ESB is independently sanitised .IMHO,keep it on a separate server ,so not only one system ,many systems can reuse the service.

sRiRaJ mISHrA
  • 86
  • 1
  • 7
0

I like Udi Dahan's explanation that an ESB is like ethernet. You can't point to it and say "here's my ethernet." It's lower-level infrastructure that basically runs everywhere. Everything else builds on top of it.

If it's centralized, then you're using a message broker rather than a bus. This architecture is analogous to a hub-and-spoke network, with the message broker being the hub.

pnschofield
  • 877
  • 1
  • 6
  • 16