SOA Webservices - How to Manage Custom Service Development on Git

Question

As part of a larger SOA program, we are developing many web services on Oracle Service Bus. They are currently managed on SVN. SVN allows us to manage an individual version of the service version, as it allows us to create tags and branches at the level of individual folders. The following is a typical structure,

+- Services | +- Service1 | | | +- tags | | | +- branch1 | | | +- trunk | | | +- artefacts | +- Service2 | | | +- tags | | | +- branch1 | | | +- trunk | | | +- artefacts | +- service N 

Git definitely doesn't allow version controlling at the folder level. We have 150+ webservice, each one of them can have it own development cycle and can be built into a deployable. A direct mapping of our current strategy to Git would be to have each service as a git repository and also follows the git principle, but that makes us have more than 150 git repositories.

Is this approach right? Is there a better approach? Does anyone have a similar opportunity to develop a large number of web services?

We also considered the possibility of creating some kind of logical grouping and creating git repositories for this group, but I assume that this is the wrong strategy, as this will make my version control and tagging of individual services more difficult. Is there any other way in git where we can manage such a grouping?

Answer 1

Submodules and repo management

You can group them with submodules - recursively, if necessary. gitolite - down to which repo the user will have access to and which branches inside this repo.

Branch for each function

For a good alternative to the standard SVN branching strategy, refer to the Branch per Element section, and you should see my article on this exact subject, The strategy we encountered was partly related to a large number of repositories.

Since you are using Oracle, I must point out the obvious for everyone: Do not integrate over the database. If you just stop reading right here. I pray for your soul.

---

Architectural glue

According to SOA, I would designate one repository that will hold your contracts or versions with versions - version means that you support several versions of the same massage (usually 3: current, outdated and specific exception - all previous ones should raise unhandled exceptions), so you can deploy new versions of advanced services and support old and new clients during deployment with zero deployment times when working with client-server and publish-subscribe relationships. This repository is a submodule of all repositories that have an endpoint for integration.

Hooks

Add a hook to this repository to allow only changes that include OCP (Open Closure Principle) at the architectural level. You simply would not allow updates to published classes. After its publication, you must support it. Gitolite simplifies hook administration remotely. He himself uses them to transparently add features.

Contract migration

To add, the migration of the message version — among other things — is simplified with the Event Sourcing state. This is a subset of the CQRS (Command Responder Segregation). Even Microsoft does this , and I was fortunate enough to participate in this. The related contextual maps and anti-corruption levels of Domain Driven Design (DDD) when used to managing messages that exist outside the service are used in one. Further recommendations for this can be found in the Ubiquitous Language (also from DDD) and Domain Specific Language (see Martin Fowler's article here ).

Implementation

Consider 0MQ (ZeroMQ) for delivery in order to avoid the potentially significant technical footprint of other Message Bus ideas. This is the responsibility of the ongoing queue on your shoulders - crowding out a more robust strategy as a whole. See the previous paragraph for how to do this. Consider Service Stack if you encounter WCF in Windows environments. The less magical / automatically generated code is in the technology, the less problems you will have with complex conflict resolution scenarios, deployments, testing, etc.