Prima di dare un’occhiata al commento di Raffaele devo fare un altro passaggio. Nella nostra analisi ad un certo punto abbiamo introdotto e definito i servizi che servono per soddisfare il requisito.
Tempo fa abbiamo anche parlato di cosa sia un servizio nel mondo SOA.
Abbiamo definito i nostri servizi:
Che sono:
- per forza logicamente separati
- possono essere fisicamente separati
- possono essere, tutti o in parte, servizi di terze parti
Un esempio
Quando un ordine su Amazon è in corso la timeline che rappresenta l’avanzamento della spedizione è fornita da un servizio di terze parti:
Quelle informazioni non sono sotto il controllo di Amazon, solo la visualizzazione è gestita da Amazon, potremmo quindi dire che uno scenario come il seguente è perfettamente accettabile nel mondo reale*:
- Marketing: SalesForce, cloud.
- Sales: SAP installato internamente
- Shipping: realizzato internamente e deployato internamente
- Warehouse: SAP installato internamente
- Publishing: realizzato internamente e deployato internamente
- Shipment Tracking: fornito da terze parti, in base al corriere scelto per ogni spedizione
I nostri modelli possono quindi essere su sistemi diversi, non necessariamente sotto il nostro controllo e non necessariamente deployati internamente. Potremmo quindi riorganizzare l’elenco di cui sopra nel seguente modo:
- SAP, interno:
- Interno / API e hosting condivisi (o condivisibili):
- terze parti:
- Marketing
- Shipment tracking
Perché distinguere tra “SAP, interno” e “terze parti”? Principalmente per una questione di ownership, sul SAP interno abbiamo un minimo di controllo e con un certo sforzo possiamo apportare cambiamenti e aggiustamenti che sulle terze parti sono esclusi a priori.
Post in questa serie:
* I servizi che sto usando negli esempi, e la loro separazione, non sono quelli di Amazon, provengono comunque da un caso reale e sono effettivamente organizzati come delineato.