230 likes | 440 Views
Nlets – The International Justice and Public Safety Information Sharing Network. What is Nlets. NLETS is a sophisticated high-speed message switching system created for and dedicated to the criminal justice community. Nlets is….
E N D
Nlets – The International Justice and Public Safety Information Sharing Network
What is Nlets • NLETS is a sophisticated high-speed message switching system created for and dedicated to the criminal justice community.
Nlets is… Non-profit corporation chartered by the States – funded by user fees Members are all 50 states, most federal agencies & territories, and the RCMP Nearly 40 years in operation Links 30,000 agencies and over 600,000 access devices in the U.S. and Canada Topping 77 million transmissions per month
Facts and Figures • 77 Million transactions per month! Only way to: • State Criminal Histories • Electronic “HIT” confirmation • Canadian Files (CPIC) • Homeland Alert Messages • Screen Officers Flying Armed • INS databases at LESC – IAQs • Driver records and vehicle registrations • Aircraft Registrations • HAZMAT, GSA Federal registrations, NICB • Push administrative messages to all CJ agencies
NLETS XML Operational Capabilities • XML Message Router (XMR) since 2001 • All NLETS transactions available in GJXDM 3.0.x format plus full legacysystem translation capabilities • 750,000 XML rap sheets alone per month • All FBI, WI, KY rapsheets are in XML • All NLETS states/agencies have access to XML and web services • Georgia first state to implement XML and Web Services for all transactions • Other users: US Courts, Perserec, Puerto Rico
Web Services • Within a secured network, NLETS exposes a web service to which users connect and send XML as a string • States wishing to receive a response via web services host own service for NLETS to connect to • NLETS specifies name and fingerprint of service, how data is handled is up to state
Text Message Text within CDATA XML Message Validates user Transforms XML to Text Determines Destination & Format Validates XML Text Message XML Message XMR XML Message
Building Capabilities • Web Services/Applications box • Allows Nlets greater flexibility in providing more services • Coast Guard • FAA • FMCSA • Parsing, etc
Example of New Service Implementation <n:NLETSInquiryData Key=“BQ"> <j:Boat> <j:PropertyAssignedIDDetails> <j:PropertyOwnerAppliedID> <j:ID>SEASKATE</j:ID> </j:PropertyOwnerAppliedID> </j:PropertyAssignedIDDetails> </j:Boat> </n:NLETSInquiryData> <n:NLETSResponseData Key=“BR"> <n:Vessel> … </n:Vessel> </n:NLETSResponseData> <html> … </html> Nlets Coast Guard Query Web Page Request Nlets NOC Internet
Message Key Standardization & Implementation Ongoing Rapsheet 3.0 Released 2005, Implementation Ongoing CANDLE Launched 2006, Implementation Ongoing Coast Guard Completed Operation Respond Phase 1 & 2 Completed Phase 3 In Progress Insurenet In Progress ChoicePoint In Progress FMCSA CDLIS In Progress Interpol In Progress Boat Response In Progress NIEM State Warrants In Progress Nlets XML and Web Services Projects
CANDLE • Collaboration between AAMVA and Nlets for Driver’s License Exchange • Driver License • Version 1.0.5 • Vehicle Registration • Version 1.0.3 • Will be discussed in next session
Images • Currently Base64 • Web Services Attachments, MTOM, etc • SRFERS Initiative • To be discussed tomorrow
State Warrants • Pilot with WA and UC • Standardizing Responses • Leveraging NCIC Specifications – GJXDM 3.0.3
Boat Registration Responses • NIEM Pilot – NIEM 1.0beta1 • Standardized GJXDM Coast Guard Response existed because of web scrape functionality • IN expressed desire to send state Boat Registration Responses in standardized format • New format must account for unreliable web scraped data as well as state requirements • Working with XSTF, NBAC, GTRI to report bugs, improve model • Will leverage web services box, specialized stylesheets to continue support for IN
GJXDM 3 GJXDM Schemas jxdm, ncic_2000, proxy 1 GJXDM namespace All relationships are inline NIEM 7 NIEM Schemas appInfo, common, justice, ncic_2000, proxy, structures, universal 3 NIEM namespaces VehicleEngine as association 1 additional type extension Boat Registration
<n:Vessel> <u:PropertyLengthMeasure>3.14</u:PropertyLengthMeasure> <u:PropertyOwnerPerson> <u:PersonName> <u:PersonGivenName>String</u:PersonGivenName> <u:PersonMiddleName>String</u:PersonMiddleName> <u:PersonSurName>String</u:PersonSurName> <u:PersonFullName>String</u:PersonFullName> </u:PersonName> <u:PersonBirthDate>1967-08-13</u:PersonBirthDate> </u:PropertyOwnerPerson> <u:PropertyModelName>String</u:PropertyModelName> <u:PropertyOwnerAppliedID> <u:ID>String</u:ID> </u:PropertyOwnerAppliedID> <u:PropertyYearDate>2001</u:PropertyYearDate> <c:BoatRegistrationID> <u:ID>String</u:ID> </c:BoatRegistrationID> <c:BoatMakeCode>token</c:BoatMakeCode> <c:BoatTypeCode>token</c:BoatTypeCode> Boat Registration – NIEM Instance
Boat Registration – GJXDM Instance <n:Vessel> <j:PropertyAssignedIDDetails> <j:PropertyOwnerAppliedID> <j:ID>String</j:ID> </j:PropertyOwnerAppliedID> </j:PropertyAssignedIDDetails> <j:PropertyPhysicalDetails> <j:PropertyModelName>String</j:PropertyModelName> <j:PropertyYearDate>2001</j:PropertyYearDate> <j:PropertyLengthMeasure>3.14</j:PropertyLengthMeasure> </j:PropertyPhysicalDetails> <j:PropertyOwner.Person> <j:PersonName> <j:PersonFullName>String</j:PersonFullName> </j:PersonName> <j:PersonBirthDate>1967-08-13</j:PersonBirthDate> </j:PropertyOwner.Person> <j:VehicleEngine> <j:VehicleEnginePowerDisplacementText>-0</j:VehicleEnginePowerDisplacementText> <j:VehicleFuelTypeText>String</j:VehicleFuelTypeText> </j:VehicleEngine>
Boat Registration • NIEM Technical Issues Encountered • Multiple inheritance across Universal and Common schemas
Lessons Learned – XML Standardization • Most difficult aspect – working without SME • Stake in sand, can’t change specs on people • Any changes have to be optional • Users are slow to implement, need to be able to do things slowly and in pieces • Implementation limited by “lowest common denominator”
Lessons Learned - GJXDM • Leverage IEPDs • Publish components in similar manner to IEPD • Flexibility is a double edged sword • Type substitution/cascading extension, multiple elements for same thing • Ambiguous data impossible to standardize • Names – Person or Organization?
Nlets Plan • Not rewriting specifications across the board • Use of new standards (ie NIEM) as Nlets community can benefit • Active participating in review and pilots to assist community • Support all relevant IEPDs • Web Services – Work with FBI to align with solid web services specification • Leverage WS-Security, ReliableMessaging, etc
Contact Me Kate Silhol Nlets Senior Software Engineer ksilhol@nlets.org (602) 224-0744