6

I'm in the very early stages of moving a development team away from large monolithic app development to an SOA approach. One of the things that caught my eye in this article about SOA:

Stevey's Google Platforms Rant

"if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism"

I can see us creating a lot of services because we provide a very wide range of services to the business so service repository / discovery will be important.

I'm also mindful of this quote from an article by David Linthicum on MSDN:

Chapter 1: Service Oriented Architecture (SOA)

"SOAs may be realized via Web services but Web services are not necessarily required to implement SOA"

I'm not sure that I want the endpoint of every service to be available as a web service, some of the end points might be Windows Services, or even simple console apps running for a few seconds in the middle of the night.

Is it frowned upon in SOA to base the service repository / discovery on the actual interfaces that the endpoints will implement? I'm thinking of some way of searching a library of DLLs (we're 100% .NET here) and being able to quickly see the contracts, and also see any concrete implementations of the contracts we have written and the developer notes about each one. Is this an approach that will cause problems as time goes by, we implement more services and the whole thing gets bigger?

markp3rry
  • 221
  • 1
  • 6

1 Answers1

2

Take on a service catalog "service" as a project. This is where one can retrieve the list of available services, and you can manage which services are available to which types of consumers (internal, external, metered).

If you have any exposure in Azure (you mentioned .NET), you can use API Management to do a lot of this for you. https://azure.microsoft.com/en-us/services/api-management/

Kyle J V
  • 226
  • 1
  • 8