Sono nelle primissime fasi del trasferimento di un team di sviluppo dal grande sviluppo di applicazioni monolitiche a un approccio SOA. Una delle cose che ha attirato la mia attenzione in questo articolo su SOA:
Rant delle piattaforme Google di Stevey
"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"
Posso vederci creare molti servizi perché forniamo una gamma molto ampia di servizi per l'azienda, quindi il deposito / scoperta dei servizi sarà importante.
Sono anche conscio di questa citazione da un articolo di David Linthicum su MSDN:
Capitolo 1: Service Oriented Architecture (SOA)
"SOAs may be realized via Web services but Web services are not necessarily required to implement SOA"
Non sono sicuro di volere che l'endpoint di ogni servizio sia disponibile come servizio Web, alcuni dei punti finali potrebbero essere Servizi Windows, o anche semplici app console in esecuzione per qualche secondo nel bel mezzo della notte .
La SOA è disapprovata per basare il repository / l'individuazione del servizio sulle interfacce effettive che verranno implementate dagli endpoint? Sto pensando ad un modo di cercare una libreria di DLL (siamo qui al 100% .NET) ed essere in grado di vedere rapidamente i contratti, e anche vedere eventuali implementazioni concrete dei contratti che abbiamo scritto e le note degli sviluppatori su ciascuna uno. È un approccio che causerà problemi col passare del tempo, implementeremo più servizi e il tutto si ingrandirà?