Page History
...
Wildfly modul navn: dk.sds.nsp.minlog.api
...
Minlog-producer-registration
Dette bibliotek indeholder implementering af interface defineret i minlog-producer-api biblioteket.
...
Wildfly modul navn: dk.sds.nsp.minlog.producer
Dette bibliotek har en afhængighed til minlog-producer-api biblioteket, så det er kun nødvendigt at anvende dette bibliotek i sit projekt.
API Beskrivelse og anvendelse
Anvendelse af API sker primært gennem to klasser og så en række POJO klasser.
RegisterServiceProvider
Dette er service provider klassen. Den definerer en enkelt statisk metode og denne metode skal kaldes for at få en instans af RegisterService. Metoden man skal kalde hedder getRegisterService().
Hvis man kalder getRegisterService() metoden UDEN at have minlog-producer-registration på sin classpath så får man en test implementering af RegisterService. Denne udgave sender IKKE data til MinLog og validerer heller ikke input. Den logger udelukkende kald til via log4j.
RegisterService
Når man har anvendt RegisterServiceProvider til at få en implementering af RegisterService er der 4 metoder man kan kalde.
void init(Properties properties)
Denne metode skal kaldes inden man kalder andre metoder. Hvis man ikke går dette får man en exception. De properties der skal angives som argument er dem der kan anvendes til at konfigurere en KafkaProducer.
RegistrationResult addRegistrations(List<LogEntry>)
Denne metode kaldes for at registrere i MinLog. Argumentet indeholder en liste af LogEntry objekter som repræsenterer de data der skal registreres i MinLog. RegistrationResult er resultatet af registreringen.
void flush()
Sørger for at kalde flush() på KafkaProducer. Metoden skal kaldes hvor gang man vi sikre sig at kald til addRegistrations() er persisteret i Kafka.
void close()
Kaldes når servicen ikke længere skal bruges. Sørger for pænt at lukke forbindelsen til Kafka osv.
LogEntry
Source
Destination
I forbindelse med version 3 af Seal.java er det besluttet at opdele koden, så den bliver fordelt i flere moduler. Det gøres bl.a. for at undgå at serviceudbydere behøver at hente al Seal.java koden ned, hvis man kun har behøv for at udstille en DGWS service.
Serviceudbydere kan desuden hente DGWS og IDWS modulerne uden at de samtidigt får WSS4J med ned, da dette modul, for nogen har givet store problemer.
2.1. Seal-common
Indeholder kode som bruges på tværs af IDWS og DGWS (og evt. fremtidige formater).
...
4.1. Standard SOSI-factory
4.2. IDWSH-factory
Fra version 2.1 inkluderer Seal.Java nu IDWSHFactory. Version 2.1 markerer begyndelsen af IDWSH-support. Det formodes at fremdidige versioner af Seal.Java vil udvide support og arbejdsgang ved hjælp af IDWSH.
Seal.Java 2.1 understøtter kun IDWSH IdentityToken. Strømmen til konstruktion og anvendelse af IdentityToken er vist nedenstående figur.
...
Når SOSIFactory er oprettet, er det let at komme i gang. Overvej følgende kodestykker, der indeholder kode til opbygning af en anmodning (request) som sendes til en tjenesteudbyder (Service provider).
5.1. Service Consumer
1 |
|
Det reelle arbejde ligger i følgende linier:
...
På den "anden side" hos serviceudbyderen bruges biblioteket således. Også her håndterer udvikleren kun ting, der er relateret til forretningsopgaven.
1 |
|
- Plain Old Java Objects - https://en.wikipedia.org/wiki/Plain_old_Java_object ↩