Agile Development and ESB
I am working on transitioning our corporate technology paradigm to Agile Development. It was a tough process, but we're almost there! :)
We have legacy systems for our database management (formerly Access, now ported to .NET and MS SQL) and we are developing a framework for our future vision. We want to migrate to the Internet as much as possible. But we want to integrate the current system with the "upcoming" one. We will not duplicate tasks and functionality.
My vision is to move all of our users' contact information to another database, linking these "profiles" with MS SQL for their history and accounting information. We will be storing all the accounting systems in a desktop application, but there is a lot more functionality that we are going to add that will be highly dependent on the web, especially Ruby on Rails.
I guess the question is why ESB? Is there a way to create SOA without using gung-ho with complex ESB systems. The whole idea is K.I.S. anyway. Can SOA be created in such a way that the / web / mobile interface is the interface, keeping the functionality in the business logic (of course, some functionality had to be implemented on the interface, but with a minimal minimum). And are ESBs really the right fit for an agile philosophy? The more I read and study them, the less I think so!: /
Thanks for your friends! If you need to clarify, just ask a few questions and I'll do my best to do it! :)
source to share
ESBs fit well into flexibility when the infrastructure or infrastructure is in place. You will find that you can create a new system in pieces, run new parts a little in parallel with the old system, and gradually shutdown the old parts of the system until only the new system is left and no one knows the difference.
the underlying SOA only defines services instead of applications; ESB manages services on channels to hide endpoints, making upgrades and replacements more fluid
source to share
I learned to get away with the term ESB pretty quickly as it is very overloaded and means different things to different people (and sometimes different things to the same person :-))
The main thing, of course, is to ask yourself what exactly you are asking for.
Wrapping your database (s) as a service is likely to be a smart choice, especially if you have multiple clients for this data; you will have to spend a lot of time thinking about your contracts and announcements, but flexible help can help a lot here.
Now the question is how to call this service, and I think you need to weigh the likelihood of changing customers and services and how your system will evolve.
Service Bus helps mask services from its client (which could be other services), and this “masking” can relay the relay to location, protocol, formats, codes, etc. some forms of Service Bus also support a route (what to call and when), but I don't like the idea at all.
so the question you need to ask yourself, I think, is what you need to start with what you want to do (and can justify) before starting the investment.
For example, if you are initially happy with a more precise approach, your customers can contact the service directly; at a later stage, as the service evolves, you can enter a "middle man" to request a request and response (yes - you can call it ESB if you like).
Alternatively, you can start with a basic "middle man" so that customers never call the service directly, but only have the functionality you need to get started, and extend it as a requirement form; it can start out as a simple transport vehicle.
Ideally, you are building on top of a product with many built-in capabilities; BizTalk Server is a good match you are using on MS stack (but it has a learning curve).
so sorry if this is not a very specific answer, but I suppose my main point is that the "ESB" shouldn't be overkill, it just comes down to what you want on the first day and nimble (and SOA) definitely helps by allowing you to evolve over time rather than something like that.
(if something above is complete stupidity or a little unclear due to lack of sleep with a newborn in the house! sorry :-))
source to share
The whole migration is what brought me to the ESB ... But the whole idea of the ESB seems difficult to solve for a problem that includes about 30,000 profiles! We are on the cusp of some exponential growth (up to several million profiles) and it might be best to start a new path. How easy is it to associate a record that is in a MySQL database with data stored in an MS SQL DB? I don't want to obviously double-enter, but there might be a more flexible way than a "full" ESB ... I understand that SOA with ESB can be quite flexible in terms of updates and substitutions, but would that be overkill? :)
source to share