Jestem raczej nowicjuszem w SOA i dlatego eksperymentuję.

Obecnie częścią, która stwarza dla mnie największy problem, jest uwierzytelnianie, moja obecna myśl o tym dotyczy następujących rzeczy:

Klient wysyła pewien rodzaj wiadomości uwierzytelniającej do usługi uwierzytelniania / użytkownika, ta usługa odpytuje db i jeśli użytkownik zostanie znaleziony, a hasło jest poprawne, odpowie identyfikatorem sesji, ten identyfikator zostanie użyty we wszystkich dalszych żądaniach ten klient.

Wydaje mi się to całkiem ok, ale nie wiem, jak powinienem obsługiwać żądania do innych usług, pomyślałem o trzech różnych podejściach.

Każda usługa pyta o usługę uwierzytelniania, jeśli sesja jest ważna, a jeśli tak, to jakie role ma użytkownik. Usługa uwierzytelniania wygląda w bazie danych i odpowiada odpowiednio.

Usługa uwierzytelniania przechowuje wszystkie informacje o sesji w pamięci RAM i odpowiada bez roundtrip db na żądania.

Usługa uwierzytelniania wysyła autoryzowaną wiadomość do esb, esb przekazuje tę autoryzowaną wiadomość do każdej usługi, a usługi te buforują ją. Żadne dalsze żądania do usługi uwierzytelniania nie byłyby konieczne. Jeśli użytkownik się wyloguje lub jego role się zmienią, zostanie wysłana inna wiadomość i przetworzona przez wszystkie usługi.

Myślę, że pierwsze podejście powoduje zbyt duże obciążenie usługi uwierzytelniania / db, ale wymaga najmniej wysiłku, aby ją wdrożyć.

Drugi jest nadal bardzo łatwy do wdrożenia, ale nacisk na usługę uwierzytelniania pozostaje prawie taki sam.

Trzecia jest nieco bardziej skomplikowana w implementacji, ale skróciłaby czas reakcji, ponieważ nie ma żadnych podróży do usługi uwierzytelniania. Chociaż, jeśli jest zbyt dużo informacji o sesji, takie podejście po prostu się nie powiedzie i prawie nie da się skalować.