Table of Contents

Interazioni tra i componenti

Come i tre pezzi della piattaforma — InfocadServer, InfocadWeb e il database Oracle — sono collegati fra loro. Questa è la pagina che spiega l'accoppiamento: se leggi una sola pagina di architettura, leggi questa.

Important

I due repository non sono accoppiati dal codice sorgente. Sono accoppiati da tre canali distinti: una cartella di binari condivisa (build time), .NET Remoting (runtime) e il database Oracle condiviso (dati). Ignorarne uno porta a conclusioni sbagliate su come si compila, si esegue e si mette in sicurezza il sistema.

I tre canali in un colpo d'occhio

flowchart TB
    subgraph BUILD["1 · Build time"]
      SRC["InfocadServer<br/>137 progetti"] -->|"OutputPath"| ASM[["Assembly/<br/>cartella condivisa"]]
      ASM -->|"HintPath"| WEBP["InfocadWeb<br/>123 progetti"]
    end
    subgraph RUN["2 · Runtime"]
      IIS["IIS · InfocadWeb<br/>+ *Controllers.dll"]
      HOST["Windows Service<br/>Business host · BL/DAO"]
      IIS -->|".NET Remoting<br/>tcp o ipc"| HOST
    end
    subgraph DATA["3 · Dati"]
      IIS2["InfocadWeb"] --> ORA[("Oracle<br/>4 schemi")]
      HOST2["InfocadServer"] --> ORA
    end
# Canale Quando Protocollo / meccanismo Direzione
1 Cartella Assembly/ compilazione drop folder di DLL (OutputPath → HintPath) Server → Web
2 .NET Remoting esecuzione TcpChannel (o IpcChannel), formatter binario Web → Server
3 Oracle condiviso esecuzione ODP.NET + stored procedure entrambi → DB
4 SOAP / integrazioni esecuzione ASMX / WCF, HTTP esterno ↔ Web

Canale 1 — la cartella Assembly/ condivisa (build time)

VERIFIED. Entrambi i repository puntano alla stessa cartella di output, che vive nella directory padre dei due repo (qui: Documentation/Assembly/):

  • InfocadServer produce: 137 progetti su 159 dichiarano <OutputPath>..\..\Assembly\</OutputPath> (281 occorrenze fra le configurazioni Debug/Release); i progetti net8 *XNET scrivono in ..\..\Assembly\net8.0\ (38 occorrenze).
  • InfocadWeb consuma: 123 progetti su 149 referenziano quelle DLL con <HintPath>..\..\..\Assembly\…</HintPath> — 1841 riferimenti in totale. La profondità del percorso relativo varia (3, 4, 5 o 6 livelli) in base a quanto è annidato il progetto, ma risolve sempre sulla stessa cartella.
  • Le DLL sono versionate 3.8.0.0, con <SpecificVersion>False</SpecificVersion>.

Esempio concreto (InfocadWeb/WebMachine/CASSANDRA/Cassandra.csproj:218-220): Descor.Property.PropertyControllers → ..\..\..\Assembly\Descor.Property.PropertyControllers.dll, prodotta da InfocadServer/PropertyControllers/.

Note

Tre conseguenze pratiche.

  1. I due repo devono essere clonati come fratelli sotto la stessa cartella padre — non per l'unico riferimento di progetto cross-repo (ServiceJob.CUT → ArchiveManager.csproj), ma per queste 1841 reference binarie.
  2. Ordine di build obbligato: prima InfocadServer.sln (popola Assembly/), poi le solution di InfocadWeb. Su una cartella Assembly/ vuota, InfocadWeb non compila.
  3. Assembly/ è output di build, non versionato: non è in nessuno dei due repo. Su questo host contiene solo net8.0/ (dai build *XNET fatti in analisi); le DLL 4.8 richiedono un build su Windows.

Vedi anche Guide per sviluppatori → onboarding e Operations.

Canale 2 — .NET Remoting (runtime)

VERIFIED. A runtime il tier web non chiama servizi REST o SOAP di InfocadServer: carica in-process le DLL Descor.<Dominio>.<Dominio>Controllers e sono quelle a uscire dal processo via .NET Remoting verso il Windows Service che ospita le business layer.

sequenceDiagram
    participant P as Pagina .aspx
    participant C as XController.dll<br/>(in IIS)
    participant F as DAOFactory
    participant B as DAO/BL remoto<br/>(Windows Service)
    participant O as Oracle
    P->>C: chiamata in-process
    C->>F: CreateDAO(Ctrl_X)
    F-->>C: proxy Remoting
    C->>B: tcp://IP:PORT/DAO_X.rem
    B->>O: stored procedure
    O-->>B: result set
    B-->>C: DTO serializzato
    C-->>P: DTO

Lato client (nel processo IIS). Ogni dominio ha una DAOFactory che costruisce l'URL remoto — 26 file contengono Activator.GetObject, tutti in InfocadServer, zero in InfocadWeb (i client sono le DLL dei Controllers, che girano nel web):

' InfocadServer/PropertyControllers/serv/DAOFactory.vb:15
Return DirectCast(Activator.GetObject(GetType(IDAO_Building),
    SettingsManager.CHANNEL & "://" & SettingsManager.SERVERADDRESS & "/" &
    My.Resources.ServicesDictionary.Service_Buildings), IDaoBase)

I nomi degli endpoint stanno in 11 file ServicesDictionary.resx — 188 nomi .rem distinti (es. Service_Buildings → DAO_Buildings.rem).

Lato server (nel Windows Service). Gli host registrano i tipi come oggetti well-known SingleCall — 231 registrazioni in totale:

Host File RegisterWellKnownServiceType
InfocadServer (principale) InfocadServer/Business/Start.vb 182
ECMServer InfocadServer/Business/StartECM.vb 27
IEMServer InfocadServer/Business/StartIEM.vb 22

Configurazione del canale. Due modalità alternative, scelte da configurazione:

Cosa Chiave / API Evidenza
Canale lato client (tcp / ipc) appSetting SSO_CHANNEL InfocadServer/Common/Config/SettingsManager.cs:57
Indirizzo lato client SERVERADDRESS = IP:PORT (tcp) o CHANNELNAME (ipc) SettingsManager.cs:81-92
Scelta lato server SystemSettings.Settings.UseIPCChannel Business/Start.vb:205, :253-262
Porta di ascolto SystemSettings.Settings.Port Business/Start.vb:240-251
Warning

Superficie di attacco del canale Remoting (rilievo di documentazione, da triagare col team). Sul canale TCP: encryption = "EncryptAndSign" (Start.vb:211) ma authenticationMode = "None" (Start.vb:212) e TypeFilterLevel.Full (Start.vb:217); sul canale IPC authorizedGroup = "Everyone" (Start.vb:232). Chi raggiunge la porta può quindi invocare i 231 tipi well-known senza autenticarsi a livello di trasporto, e i grant di sezione non vengono ri-verificati oltre il confine Remoting — è il difetto sistemico TD-008 (9 domini). Vedi anche Global — identity e Remoting.

Canale 3 — il database Oracle condiviso (dati)

VERIFIED. Entrambi i tier scrivono sugli stessi schemi, tramite stored procedure (nessun ORM, nessuna sincronizzazione applicativa fra i due repo): il database è anche un punto di integrazione, non solo un archivio.

Connection string Schema Usata principalmente da File di config
MainConnection INFOCAD_TEST38 DAL di dominio InfocadServer, web CASSANDRA 19
RequestCenterConnection REQUESTCENTER_TEST38 RequestCenter BL/DAL (InfocadWeb) 15
DEMConnection DEM_TEST38 sottosistema DEM 13
OracleProvidersDB ASPNET_TEST38 provider Membership/Role ASP.NET 11

Le connection string non si modificano a mano: ConnectionsService le riscrive nei *.exe.config al deploy leggendo connections.xml — vedi Operations. Dettaglio schemi: Database.

Canale 4 — SOAP e integrazioni esterne (perimetro)

VERIFIED. L'intera superficie SOAP/WCF (46 .asmx + 35 .svc) sta in InfocadWeb, non in InfocadServer (dove il WCF è sottile: solo EnergyService, self-hosted). Serve il perimetro esterno — non la comunicazione Web↔Server. Vedi API / Servizi, CONF-001 e Integrazioni.

Cosa NON esiste (verificato, per evitare assunzioni)

Assunzione comune Realtà
REST / Web API fra i tier No — ApiController = 0 in entrambi i repo
ASP.NET MVC No — solo Web Forms
ORM (EF, Dapper, NHibernate) No — solo stored procedure via wrapper DAL
Message bus / code (MSMQ, RabbitMQ, Kafka, Azure Service Bus, NServiceBus, MassTransit) No — 0 file. Le "code" sono le triadi Process/Queue/Scheduler di InfocadIntegration su Quartz.NET + tabelle Oracle
Riferimenti di progetto cross-repo Uno solo (ServiceJob.CUT → ArchiveManager.csproj); tutto il resto è binario via Assembly/
Suite di test automatici / CI No — 0 progetti di test, nessuna configurazione CI

Dove approfondire