NexusFabricCereți o prezentare

Protocoale

Un mesaj intră pe o ușă, iese pe un apel și se întoarce ca răspuns. Pagina asta descrie cele trei momente și ce decide platforma în fiecare.

Intrarea: poarta rulează înaintea corpului

Poarta de acces e închisă implicit. Pornirea fără credențiale e o opțiune explicită, care se anunță la fiecare pornire — nu o valoare implicită tăcută.

Decizia se ia înaintea corpului. Un apelant nelegitimat provoacă două interogări indexate și atât: niciun octet de corp citit, nicio parsare, nicio încărcare de artefact. Consecință de contract: un apelant fără credențială care anunță un corp peste plafon primește un refuz de autentificare, nu unul de dimensiune — plafonul e stare internă și nu se divulgă înainte de autentificare.

Ușa gRPC

Ușa gRPC e un ascultător separat, pornit explicit pe portul lui. Un apel rutat trece prin aceeași poartă ca rutele HTTP și prin aceeași paranteză de livrare, deci deduplicarea, corelarea și memoizarea răspunsului funcționează acolo fără cod scris în plus.

Ce nu face ușa gRPC: streaming refuzat explicit, tabelă de rutare construită la pornire, secvența de tratare a erorii fără corp livrabil.

Ieșirea HTTP

Adresa unui apel de ieșire se poate calcula din mesaj și din configurarea instalației: e un șablon, verificat la publicare ca orice alt șablon, nu un șir concatenat la rulare.

Când backendul răspunde cu o eroare, corpul acelei erori e disponibil fluxului: secvența de tratare a erorii îl poate citi și poate compune un răspuns din el. Anteturile răspunsului sunt și ele disponibile, mai puțin cele sensibile, reținute chiar la captură — nu filtrate mai târziu.

Ieșirea gRPC

Ieșirea gRPC lucrează cu descriptori protobuf încărcați dinamic, susține TLS reciproc, o cascadă de adrese și un întrerupător per adresă.

Contractul răspunsului

Răspunsul către apelant e ieșirea fluxului, neîmpachetată. Nu există plic, iar tipul de conținut se derivă din forma corpului.

Forma ieșirii fluxului și corpul care pleacă pe fir
Ieșirea fluxuluiCorpul răspunsuluiTipul de conținut
Obiect, listă, număr, booleanJSONapplication/json
ȘirTextul verbatim, fără ghilimeletext/plain; charset=utf-8
NimicNiciun octetAbsent
Document XMLXML-ul serializatapplication/xml; charset=utf-8
  • Fluxul își declară statusul răspunsului, pe orice pas, inclusiv semantica de proxy: statusul backendului devine statusul răspunsului.
  • Fluxul dictează anteturile răspunsului, pe orice pas; la nume repetat câștigă ultimul scriitor, în ordinea execuției.
  • Anteturile primite de la backend se întorc către apelant numai dacă fluxul le-a declarat pe o listă. Fără listă, nu se întoarce niciunul.

Plafonul unui mesaj

Nu există un plafon unic pe instalație. Plafonul se rezolvă per punct de acces, pe trei straturi: valoarea instalației, valoarea fluxului și valoarea unui pas de ieșire. Un corp care își anunță dimensiunea peste plafon e refuzat fără să se citească un octet din el.

SOAP

O cerere SOAP 1.1 sau 1.2 se despachetează pe /run, fluxul lucrează pe conținutul Body-ului, iar răspunsul pleacă în plicul aceleiași versiuni. Un plic stricat e 400 cu SOAP Fault, iar un flux care eșuează întoarce SOAP Fault, nu un corp de succes. Pe ieșire, un pas care declară versiunea împachetează corpul și trimite SOAPAction.

Un soap_version: din afara vocabularului {1.1, 1.2} e refuz la publicare — pe pașii obișnuiți, pe cei de ## Fault: și în bibliotecile expandate — nu abandon tăcut al modului SOAP.

GET /flows/{tenant}/{flux}/wsdl generează un WSDL 1.1 document/literal din configurarea SOAP a fluxului publicat; un flux fără configurare SOAP și un flux inexistent răspund identic, 404.

Poarta nu se schimbă pentru SOAP: o cerere SOAP trece prin aceeași poartă, neschimbată, iar un refuz e 401/403 HTTP simplu, niciodată un SOAP Fault.

Două limite rămân. WS-Security nu există: un element de securitate din corpul mesajului nu autentifică nimic, fiindcă poarta decide înainte ca un corp să existe. Și nu se consumă un WSDL străin, iar contractul pe care îl poate publica un serviciu expus e slab tipizat, xsd:anyType — schema tipizată, fault-urile declarate și mai multe operații pe același serviciu nu sunt construite. Dacă proiectul vostru depinde de un contract SOAP tipizat, asta e informația relevantă, și o aveți înainte de prima discuție.