Nella 5 i web service vengono simulati tramite un oggetto automation che si occupa sia della gestione del servizio di ascolto alle chiamate che della definizione dei metodi esportati verso l'esterno, e la comunicazione fra l'applicazione consumer e il webservice non avviene in modo trasparente come in 2009 (in pratica bisogna gestirla tramite xmlport e occuparsi di scrivere e leggere correttamente l'xml lato ..NET).
Detto in parole povere il programmatore si occupa di scrivere in .NET la DLL (automation) che poi viene utilizzata in una codeunit nav, nella codeunit vengono pubblicati in automatico gli eventi (metodi) messi a disposizione dal web service. La DLL si occupa di ricevere/gestire tutte le chiamate e di tutta la logica applicativa.
Le problematiche a cui andiamo incontro con la 5 sono:
1) Gestione del servizio di ascolto webservices, come gestiamo la multiutenza? è stabile? in Nav 2009 cè il servizio standard supportato da Microsoft.(
2) Interfaccia del web service, se ci si accorge di dover aggiungere un nuovo metodo alla DLL è necessario ricreare completamente anche la codeunit Navision e non solo aggiornare l'automation (su questo ultimo punto ci sto lavorando).
3) L'impegno per lo sviluppo si lato .NET che Navision risulta maggiore.
4) complessità dell'architettura.
Di seguito una breve descrizione dell'architettura:
1) Web Service Consumer: Qualsiasi client o applicazione che usufruisce del web service (CRM,Intranet ecc..).
2) Port: è la porta fisica su cui rimane in ascolto il web service
3) WCF Web Service: Interfaccia del Web Service
4) COM Event Dispatcher : Definisce e richiama gli eventi a cui avra accesso Navision tramite l'oggetto COM.
5) Codeunit Event Handler : E' responsabile della partenza del servizio e della gestione dell'interfaccia COM
6) XMLPort: gestisce la comunicazione da e per il servizio.