Integrated Workforce Registration (IWR) System
Workforce Integration Profile Page
Software Architecture Design Document
Version 2.2
1
IWRSSoftware Architecture Document
Contents
1
Table of Figures .....................................................................................................................4
1
Introduction ..........................................................................................................................6
1.2
Document Purpose .......................................................................................................................... 6
1.3
Reference Documents...................................................................................................................... 7
1.4
Assumptions..................................................................................................................................... 7
2
System Use Cases...................................................................................................................8
2.1
Use Case Realization ........................................................................................................................ 9
2.1.1
User Management .............................................................................................................. 9
2.1.2
Question Management ..................................................................................................... 10
2.1.3
Registration ....................................................................................................................... 11
2.1.4
Data Exchange................................................................................................................... 13
2.1.5
Profile Page (WIPP) ........................................................................................................... 14
3
Project Roles and Responsibilities ........................................................................................ 19
4
Solution Architecture ........................................................................................................... 20
2
4.1
Presentation Tier............................................................................................................................ 22
4.2
Middle Tier ..................................................................................................................................... 22
4.2.1
Registration ....................................................................................................................... 23
4.2.2
Questions Administration ................................................................................................. 24
4.2.3
Manage Account ............................................................................................................... 25
4.2.4
Self Service ........................................................................................................................ 26
4.2.5
State Profile Manager ....................................................................................................... 27
4.2.6
IWRS Data Service ............................................................................................................. 27
4.2.7
IWRS LDAP Service ............................................................................................................ 27
4.3
Data Tier......................................................................................................................................... 27
4.4
Integration Tier .............................................................................................................................. 28
4.5
Infrastructure Services ................................................................................................................... 28
4.5.1
Logging .............................................................................................................................. 28
4.5.2
Auditing ............................................................................................................................. 28
4.5.3
Validators .......................................................................................................................... 28
4.5.4
Exception Reporter ........................................................................................................... 29
IWRSSoftware Architecture Document
5
Application Structure ........................................................................................................... 30
6
High Level Design ................................................................................................................. 31
6.1
IWRS Client..................................................................................................................................... 31
6.2
WIPP Client .................................................................................................................................... 32
7
Network Infrastructure ........................................................................................................ 33
8
Hosting Solution .................................................................................................................. 36
8.1
Cloud Hosted.................................................................................................................................. 36
8.2
State Hosted................................................................................................................................... 37
9
Single Sign On ...................................................................................................................... 38
10
Technology Stack ................................................................................................................. 40
11
Appendix A: ......................................................................................................................... 48
3
IWRSSoftware Architecture Document
1 Table of Figures
Use Case – Registration .............................................................................................................................. 11
Use Case – User Management ...................................................................................................................... 9
Use Case – Question Management ............................................................................................................. 10
Use Case –Data Exchange ........................................................................................................................... 14
IWRS Solution Architecture......................................................................................................................... 21
IWRS LDAP Structure .................................................................................................................................. 26
IWRS Application Structure......................................................................................................................... 30
High Level Design – IWRS Client ................................................................................................................. 31
High Level Design – WIPP Client ................................................................................................................. 32
IWRS Cloud/State Production Environment ............................................................................................... 34
Cloud Hosted Solution ................................................................................................................................ 36
State Hosted Solution ................................................................................................................................. 37
IWRS Authentication Flow .......................................................................................................................... 38
4
IWRSSoftware Architecture Document
Revision History
Version
Date
Description
Author
DRAFT
2/18/13
Initial version with only Registration
Flow.
GCOM Software Inc.
1.0
3/25/13
Updated all sections based on ITSC
review comments
GCOM Software Inc.
1.1
4/10/13
Updated section 2.1.1 with Registration
common data elements and removed
Mass Upload of Job seekers function.
GCOM Software Inc.
2.0
5/29/2013
Updated user comments from states.
GCOM Software Inc.
Updated WIPP related changes.
2.1
06/21/2013
Removed Tohu references and updated
PrimeFaces in various sections.
GCOM Software Inc.
2.2
06/26/2013
Updated SAD with KK's (ITSC) review
comments
GCOM Software Inc.
5
IWRSSoftware Architecture Document
1 Introduction
The goal of this IWRS and WIPP is to effectively and seamlessly connect unemployment insurance and
workforce systems for the UI claimant/job seeker, through the development and implementation of a
web based IWR system and User Profile Page (WIPP). The Integrated Workforce Registration (IWR)
system will become the point of entry into the state system for unemployed individuals/jobseekers in
the three pilot states (Mississippi, Oregon and New York) that have partnered with NASWA/ITSC for this
project. The profile page acts as a two way communication channel between the state’s workforce
systems, UI/ES/WIA agencies, and the job seeker, providing relevant real time information. The WIPP
standardizes the information contained within the workforce systems (UI, WIA, and ES) as well as the
information gathered from the job seeker during the IWR process. The technology solution will be built
using open source technologies. The development effort will be overseen by ITSC, in partnership with
the three pilot states and the United States Department of Labor (USDOL), Employment and Training
Administration (ETA) Office of Unemployment Insurance.
The Information Technology Support Center (ITSC) is assigned with the task of developing an
Integrated Workforce Registration System (IWRS) under the US Department of Labor (USDOL),
Employment and Training Administration’s national vision to improve the connection and integration of
Unemployment Insurance (UI) and workforce systems.
The goals of the IWRS/WIPP are –
1. An Integrated Registration System that must capture service driven job seeker information.
2. Incorporation of “Real-time Triage” and “Skills Transferability/Job Matching” functionality into
the Integrated Registration System.
3. Provide existing and future real time triage and job match tools, and systems.
4. Provide dynamic and customizable profile page based on the hosting state’s external existing
web interface (look and feel).
5. Provide modular profile page.
ITSC will use a Service Oriented Architecture that will enable Enterprise Application Integration and
reusability of service components across various enterprise applications.
1.2 Document Purpose
This document defines the overall high level architecture of IWR and WIPP system for various use cases
mentioned in the “Connectivity IWR” RFP. The following subjects are described in this document:
•
•
6
System Architecture
IWRS and WIPP Deployment
IWRSSoftware Architecture Document
1.3 Reference Documents
The following documents were used in the preparation of or are referenced within the System
Architecture Document:
1. Connectivity IWR RFP 09252012.pdf (Integrated Workforce Registration (IWR) System RFP)
2. GCOM_WIPP_SOW.docx
3. Tohu Framework (http://www.jboss.org/tohu) PrimeFaces (
http://www.primefaces.org/showcase/ui/home.jsf )
4. Drools Framework http://www.jboss.org/drools/
5. JBoss Application Server (http://www.jboss.org/jbossas)
6. OpenDJ and OpenAM (http://forgerock.com/what-we-offer/open-identity-stack/)
7. Global Unique Identifier (http://en.wikipedia.org/wiki/Globally_unique_identifier)
8. Logging framework
(http://docs.oracle.com/javase/6/docs/technotes/guides/logging/overview.html)
9. Design patterns:http://www.allapplabs.com/j2ee_design_patterns/j2ee_design_patterns.htm
10. RESTful Web Service : http://www.ibm.com/developerworks/webservices/library/ws-restful
1.4 Assumptions
Following assumptions have been made while designing this application architecture:
1. Application components will be built using open source components.
2. Technologies, standards, and methodologies will be selected based upon industry’s best
practices and in accordance with the core objectives of system stability and maintainability.
3. All registration data will be stored in the state systems and will be accessed/updated using bidirectional interface.
4. IWRS will store only configuration related data e.g. state specific configuration (profile,
questionnaire etc.)
5. Agencies responsible for system interfaces will provide the appropriate access for data sharing.
7
IWRSSoftware Architecture Document
2 System Use Cases
IWR system consists of following use cases. Please refer Connectivity IWR RFP 09252012.pdf for
detailed information about each use case.
Manage
Account
Self Service
Question
Administration
Registration
Data Exchange
WIPP
8
Use Case Name
1. Create Account
2. Modify Account
3. Revoke Account
4. Create User Group
5. Modify User Group
6. Delete User Group
1. Forgotten User ID
2. Forgotten Password
1. Question Configuration — New Question(Registration)
2. Question Configuration — Update Question(Registration)
3. Question Configuration — Retire/Expire Question(Registration)
4. Account Administration - Modify SSO related Question(OpenAM)
5. Account Administration - Active/Inactive SSO relates Question(OpenAM)
1. Register New Self-Service Job Seeker
2. Register New Job Seeker with Staff Assistance
3. Returning Job Seeker Who Has Registered Previously
Implementation of Service Interfaces
Workforce Integration Profile Page
IWRSSoftware Architecture Document
2.1 Use Case Realization
2.1.1 User Management
Manage Account
Create Account
Modify Account
Revoke Account
IWRS::System Administrator
Create User Group
Modify User Group
Delete User Group
Use Case – User Management
The User Management use cases will allow an IWRS administrator to manage the user account
information and user groups i.e. roles. User information and roles will be stored in the OpenDJ LDAP.
Following common user information will be captured as part of account creation








9
User ID
Password
First Name
Last Name
Email Address
Birth date (optional)
Zip code (optional)
SSN (optional)
IWRSSoftware Architecture Document


Secret questions and answers
The above fields will be state customizable. Also states can decide how many secret questions they
want to accept.
IWRS will have following user groups (roles)
a. Job Seeker
b. System Administrator
c. State Staff
The system administrator role will allow state system administrator to manage the state specific
configuration while state staff role will allow user to manage registration information on behalf of Job
seeker.
IWRS will use OpenDJ LDAP SDK to create and modify user information in the LDAP.
2.1.2 Question Management
Questions Administration
New Question
Update Question
IWRS::System Administrator
Retire/Expire
Question
Use Case – Question Management
10
IWRSSoftware Architecture Document
The Questions Administration will allow system administrator to manage state specific questions. This
set of use cases allow configuration of data entry questions, their order, and the results derived from
their answers. Once user makes changes to the question set, application will display questions to
administrator in the order in which it will be displayed to the Job Seeker.
IWRS will use Red Hat Tohu framework PrimeFaces (JSF)and custom logic to display dynamic questions
during registration process . JSF validation will be utilized to do Registration field validation and Drools
will be used to do business validation IWRS will present two sets of questions to Job seeker during
registration process. First set is common set of questions which are applicable to all states and second
set of questions will be state specific questions. All questions (state and common) will be stored in the
IWRS centralized database.
2.1.3 Registration
Once job seeker account is created in the system, user will be redirected to complete the registration
information. Registration form will display data elements (questions) which are configured for that
state. User registration information will be stored on the state side and will be retrieved using
Registration interface implemented by state.
Registration
Register New
Self-Service Job Seeker
Returning Job Seeker
Who Has Registered
Previously
IWRS::Job Seeker
Register New Job
Seeker with Staff Assistance
IWRS::State Staff
Use Case – Registration
Registration module will consist of user interface components, business service and web service adapter
to pull information from state interface. First time when user comes to registration screen, application
11
IWRSSoftware Architecture Document
will query user data from the state system and prepopulate the registration screen. Application will pass
following information to query the initial registration information:








User ID
First Name
Last Name
Email Address
Birth date (if available)
Zip code (if available)
SSN (if available)
etc
The following are common data elements that are agreed upon by states ag.
Name
Description
Type
firstName
First Name
Text
lastName
Last Name
Text
emailAddress
Email Address
Text
dateOfBirth
Date of birth
Text
SSN
Social security number
Text
Gender
Sex of the person
Text
Veteran Status
Is user veteran?
Boolean
Migrant SFW
12
Text
Occupation
User’s occupation
Text
employmentStatus
Employment Status
Text
communicationMethod
User’s preferred method of
communication.
Text
Disability
Is Job seeker disabled
Text
primaryLanguage
Primary language of Job seeker
Text
Race
Job seeker race
Text
Ethnicity
Job seeker ethnicity
Text
IWRSSoftware Architecture Document
Name
Description
Type
informedConsent
User consent
Boolean
Education
Education of the user
Text
Residential Address
User’s residential address
Address
Mailing Address
User’s mailing address
Address
Please refer to the registration flow v2.0 document to see the registration process flow and different
parties involved in IWRS registration flow.
Registration flow
v2.0.pdf
2.1.4 Data Exchange
State Systems
State Use Case1
State Use Case2
IWRS::IWRS
.
.
.
State Use Case n
13
IWRSSoftware Architecture Document
Use Case –Data Exchange
IWRS will be responsible for exchanging data with state systems. State systems will publish state
services using SOAP/HTTP web service. As part of initial discussion, following interfaces have been
identified:
Interface Name
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Registration
Profile Data
UI Claim Info
Get Event Info
Get Matching Jobs
Triage
Message Center(Agency/User)
LMI/Job forecast
Navigation to Services
Training and Activities
Jobseeker Personalized Calendar
Motivational Job Seeker Tips
Social Media Links / Feeds
Direction
Pull
Pull
Pull
Pull
Pull
Pull
Pull/Push
Pull
Pull
Pull
Pull
Pull
Pull
The data transmitted between two systems will be encrypted using digital certificate.
2.1.5 Profile Page (WIPP)
Once the job seeker is registered in the system using IWR, he/she will be navigated to profile page.
There will be two types of WIPP users (job-seeker and customer service representative) that the IWR
system will integrate with the Workforce Integrated Profile Page. The profile page will act as a two way
communication channel between the state’s workforce systems, UI/ES/WIA agencies, and the job
seeker, providing relevant real time information. The profile page will standardize the information
contained within the workforce systems (UI, WIA, and ES) as well as the information gathered from the
job seeker during the IWR process.
The profile page will have following sections which will be displayed based on user profile information
and state configuration.
a)
b)
c)
d)
e)
f)
14
Job Postings
Navigation to services
Profile Summary
Message Center
Agency Message Center
Training and Activities
IWRSSoftware Architecture Document
g)
h)
i)
j)
k)
l)
m)
n)
UI Claim Info
LMI/Job Forecast
Job Seeker Tips
National Tools
Job-Seeker Personalized Calendar
Social Media Links / Feeds
User Chat
Motivational Job Seeker Tips
2.1.5.1 Job Postings
The online job match section will be used to provide the job seeker with available job openings,
harnessing the job match functionality of the state system (i.e. O*Net code or skills-based), provided
real time. If a job-seeker clicks on a specified job posting, the Profile Page will capture the “click” the job
seeker accessed and prompt the job- seeker next visit for additional information (i.e. applied,
interviewing, didn’t get it, not interested)
a) Interfaces: A generic interface will be created to pull the data from the state job bank. The job
seeker will have the option to specify how many postings will be displayed with a lower and
upper limit. This function will be updated real time.
b) Data provided from initial registration (O Net code, education level, skills, etc….) will feed and
inform the state job bank to return the postings. The quality of the job matches will be
determined by the amount and quality of information the job seeker provides, which will be
stressed to the jobseeker.
2.1.5.2 Navigation to Services
Using the information that is provided by both the initial registration and data stored within the
workforce systems that is gathered as part of triage component, recommendations of services (online
training, including free training, OR’s NRCC training) will be provided to the job seeker. The services will
be dynamically analyzed based on listed information and qualifications of the job seeker (the ability to
navigate to appropriate programs and services they are eligible for). The system (“intelligence”) will
provide recommendations and push people to services. Conducts gap analysis of the job seeker based
on skill sets, education level, and job experience. All recommendations within this section are solely
based on online self service capabilities provided by the state’s online system.
2.1.5.3 Profile Summary
All information that is gathered from the job seeker will make up a combination of the job seeker
registration personal profile.
An interface to the different workforce systems will provide the state system data information. The IWR
system is not the system of record for any of the collected data except for the initial registration of a job
15
IWRSSoftware Architecture Document
seeker. Once the other workforce system eligibility process is completed, it will maintain the system of
record for the job seeker.
The state will provide the appropriate interface to their systems to gather and disseminate the
information to and from the different workforce systems.
2.1.5.4 Message Center
This section of the Profile Page is provided to the job seeker to act as the primary contact channel
between the job seeker and the agencies (WIA, ES and UI). This section will allow Real Time Triage
components (identified and developed by states) as well as other Workforce systems to send automated
messages and receive messages from the job-seeker. Additionally, information from this section shall
be routed to the appropriate groups within the hosting agencies email list. The information in this
section may not be enabled by all agencies if there is no current email routing solution established to
the different workforce partners.
a) Basic email interface shall be developed to handle both input (receipt) and output (sending)
of information by the job seeker.
b) Internal users will use the existing interface to respond to all messages from the jobseeker.
c) A question based routing process shall be developed to understand the appropriate
user/agency to receive the correspondence. This process shall take place prior to allowing
the user to enter in specific information or a question.
d) Templates for information provided could change based on destination of the
correspondence (i.e. if info is provided to UI, identification information may be required).
2.1.5.5 Agency Message Center
This section will be used to provide agency generic or directed messages from the workforce agencies to
the job seekers. Based on information that the profile page will know about the job seeker (i.e. veteran,
recently unemployed, etc.) directed messages could be posted by the agency as a broader group.
Information in the section will be different for each state.
2.1.5.6 Training and Activities
The information and content in this section will be populated based on the job seeker’s local One Stop
calendars, providing information on upcoming workshop sessions (i.e. resume building, interviewing,
social media for job search, dressing for success, etc.), job fairs, employer recruitments, job clubs etc.,
that job seekers can attend. The information that is populated in this section must be pulled in to the
Profile Page based on the One Stop system’s current and future capabilities (Localization area to allow
different regions to put/list/feed what’s important to them).
a) The information in this section will only provide events that the job-seeker qualifies for
within their local area.
b) Once a job seeker selects to participate in an event then the appropriate information will be
captured within their personal calendar as well as register the job seeker for the event.
16
IWRSSoftware Architecture Document
2.1.5.7 UI Claim Info
Provided by the state UI Agency, this section will act similarly to an Inquiry screen providing real time
summaries of information relevant to the job seeker’s UI claim. All data/information that is provided in
this section shall be defined by the implementing state and could change, based on that state’s UI
communications needs with the job-seeker (claimant). This section will provide and update the status of
the job seeker’s UI claim in real time. It will also provide the ability to recognize and inform the
appropriate next steps for a UI claimant.
a) The state agencies will provide the appropriate interface to gather the appropriate data
elements needed to populate this section.
b) Although this may provide a small sub-set of information available based on state’s existing
configuration, a link to the state’s UI self-service web UI inquiry may be provided in this
area.
2.1.5.8 LMI/Job Forecast
This section will feature local employers that are potentially hiring and regional labor market
information. This page will display information on wage and in demand job projections from employers.
Page will display job forecasting using some of the national tools (e.g. MySkillsMyFuture) that are
available job forecasting.
2.1.5.9 National Tools
This module will interface directly with the federal tools that are provided to support different jobseeker activities. These Federal interfaces will include, but are not limited to, the following tools:




MySkillsMyFuture
MyNextMove
ServiceLocator (CareerOneStopCenter Locator)
Military to Civilian Occupation Translator
2.1.5.10
Job-Seeker Personalized Calendar
This calendar provides the job-seeker with an individual view of upcoming appointments, due dates, or
other relevant date specific materials pertaining to all workforce agency areas. This module will take a
feed from the state workforce agency and populate based on the individual state information with the
individual job-seeker, not generic information.
2.1.5.11
Social Media Links / Feeds
This module will provide the states with direct access to the different social media tools used by each of
the pilot state workforce agencies. The module can either specify direct links to the tool or feeds that
represents the states postings or job-seeker information to assist in their job search efforts.
17
IWRSSoftware Architecture Document
2.1.5.12
Motivational Job Seeker Tips
This section will provide different tips in gaining employment motivating the job-seeker within their
concentrated area of search. This module will display single tip on the profile page and ability to
navigate to other tips provided by state.
2.1.5.13
User Chat
The user chat functionality will provide the state agencies with the ability to provide real time
interaction with the job-seeker based on the state implemented chat tools. This will not provide the full
solution of chat but more of common interface that will enable the ability to interact with the job-seeker
using chat.
18
IWRSSoftware Architecture Document
3 Project Roles and Responsibilities
Following key project roles are defined for IWRS
Role
1.
2.
ITSC Project Manager
GCOM Project Manager
3.
State Project Manager
4.
IT Leads
19
Responsibilities
Overall IWRS project manager.
Responsible for executing tasks assigned to GCOM staff as
per IWRS project plan. Reporting status to ITSC project
manager.
Project Manager in charge of the resources and related
activities execution at the State level.
There is a PM for each State: New York, Mississippi, and
Oregon.
Empowered to make the technical decisions regarding the
Solution Architecture for the IWRS.
IWRSSoftware Architecture Document
4 Solution Architecture
This section describes overall solution architecture of IWRS application. IWRS will be designed keeping
following design principles in mind:
 IWRS/WIPP solution will be based on Services Oriented Architecture concept which loosely
couples the different tiers (Presentation, Business service, data tier and integration) of
application services. Solution will be based on “Connectivity Reference System Architecture”.
 IWRS/WIPP solution will enable deployment approach with multiple iterative releases thus
reducing the risk significantly and allowing for segmented deployment of fully tested back end
integration platform.
 IWRS/WIPP architecture will allow ITSC or state to change or add functions in any tier without
affecting other tiers thus offering flexibility.
 The user interface part of IWRS/WIPP will be user friendly and will allow state specific
customization.
 Interfaces between IWRS and WIPP as well as IWRS and State systems will be based on industry
standards web services specifications.
 IWRS/WIPP components can be hosted locally or in the cloud. IWRS/WIPP will be designed
keeping in mind that state can choose all or some modules of IWRS system. Each of the IWRS
module e.g. Registration, Triage will be separate modules and provide flexibility to state of
hosting locally or consume it from cloud.
 Low or no cost of acquisition for software technologies used in the design.
 Widely accepted, supported and proven Open Source technology.
 State(s) should be able to buy licenses and support if they plan to use a supported version of the
software technologies used.
 Role/Group Based Access control driven identity security in conjunction with Java
Authentication and Authorization Service (JAAS).
 Provide Single Sign On (SSO) capability for states that do not own Single Sign On capability.
 Seamlessly integration with existing Single Sign On (SSO) systems of states that already have
such capability using Federation – SAML2.
IWR system will be based on n-tier architecture which will consist of presentation tier, middle (business)
tier, data tier and integration tier. The overall solution will be implemented using set of Java/JEE
components to realize use cases defined in the Section 2 “Use Cases”.
20
IWRSSoftware Architecture Document
Job
Job Seeker
Seeker
State
State Administrator
Administrator
WIPP
IWRS
Presentation
State
State Staff
Staff
EJB Call
Middle Tier
Questions
Administration
Data
RESTFul Webservice
Self Service
UI Claim Info
Event Info
Profile Data
Matching Jobs
Registration
IWRS Data
Service
Triage
LMI/Job
Forecast
Message Center
Navigation to
Services
Manage
Account
IWRS LDAP
Service
Infrastructure
Services
Training and
Activities
State Profile
Manager
Personalized
Calendar
Logging
Auditing
Validators
Social Media
Links / Feeds
Exception
Handler
Job Seeker Tips
Exception
Reporter
IWRS
State
State
Configuration
Questions
Questions
DB
Common
Common
Questions
Questions
State
State Profile
Profile
Config
Config
Job
Job
Events
Events
Audit
Audit
State
Services
Registration
Adapter
Profile Data
Adapter
UI Claim Info
Adapter
LMI/Job Forecast
Adapter
Event Info
Adapter
Navigation to
Services Adapter
Training and
Activities
Personalized
Calendar Adapter
Job Seeker Tips
Adapter
Message Center
Adapter
Social Media Links
Adapter
Triage
Job
Match
One Stop
UI Benefits
Workforce
Systems
Job Matching
Adapter
Integration
IWRS LDAP
Triage
IWRS Solution Architecture
IWR/WIPP will be combination of secure (protected) and unsecure (unprotected) application.
Application user needs to have an account in the system to access the protected part of the application.
During account creation process, system administrator or application will assign one or more roles to
user. Based on logged in user’s role, application will redirect user to specific page. For state staff and
system administrator, it will redirect them to their home page where they can select task they want to
perform e.g. Create Job Event or Create New Account.
21
IWRSSoftware Architecture Document
For Job seeker, application will redirect him/her to registration page if registration process is not
complete or profile page (WIPP) in case registration information is complete. User can also directly go to
WIPP from state site in case registration information is complete.
Application will maintain user authentication information in the LDAP along with his/her roles in the
system. The communication between user browser and application will be secure (HTTPS) and
encrypted using 256 bit encryption. IWRS/WIPP will support following browsers:


Browser
Internet Explorer
Mozilla Firefox
Version
7, 8 and 9
Version 3.6 – Version 12
4.1 Presentation Tier
The presentation tier will be responsible for displaying web pages to browser user. This tier will be
implemented using following technologies:










JavaServer Faces
RichFaces PrimeFaces
Cascading Style sheets (CSS)
JQuery
Java 1.6 classes
HTML
Servlets 2.5
Tohu Framework
Drools
AJAX
The presentation user interface will be ADA (Americans with Disabilities Act) compliant. The banner on
the top of the page will be personalized based on logged in user’s state e.g. if user belongs to NY then
NY banner will be displayed on the top.
The communication between IWRS user interface components and business components will be done
using EJB while interface between WIPP and IWRS business components will be done using RESTful web
services.
4.2 Middle Tier
IWRS/WIPP middle tier will consist of business components and will be hosted on the JEE application tier
e.g. JBoss. Each of the business modules will be separate deployable units i.e. EAR file. Based on
“Connectivity IWR RFP 09252012.pdf” document, following business components (modules) have been
identified.
22
IWRSSoftware Architecture Document
(Note: These components are described at a very high level in this document. Each of the components
(except IWRS Data Service and IWRS LDAP Service) will have its own technical design document which
will describe implementation of these components in detail. The documents will be published to stake
holders as per the project schedule.)
4.2.1 Registration
Registration component will implement IWRS registration functionality. Job Seeker and state staff will
have access to this function and will consists of set of JavaServer Faces pages, business service and Web
Service registration adapter which will talk to state system to fetch initial registration information as
well as update registration information provided by Job Seeker in the state system.
Once user has navigated to registration page, based on user’s profile information in the LDAP, a
questionnaire pertaining to that state will be displayed. This questionnaire will consist of state questions
and common questions. The registration web page will be implemented using Tohu framework
PrimeFaces (JSF)and custom logic which will be responsible for displaying questions. JSF validation will
be utilized to do Registration field validation and Drools will be used to do business validation Based on
the answers provided by Job Seeker, Registration screen may display additional questions. Tohu
Framework PrimeFaces(JSF) and custom logic uses DROOLS rules engine to determine additional
questions.
When initial registration page is displayed, certain information will be pre-populated based on the user’s
account information in the LDAP. The typical interaction between IWRS and State Registration service is
shown below.
23
IWRSSoftware Architecture Document
Registration System
Job
Job Seeker
Seeker
IWRS LDAP
State
State Registration
Registration System
System
WIPP
WIPP
User Navigates to registration screen.
System queries information in
the LDAP based on userid.
If present LastName,
FirstName, Email Address etc.
information is returned.
Pre-population
of Registration
information
If sufficient information is
available then call is made to
fetch user information
available in the state system.
State system returns
user information if
available.
User submits registration information.
System sends registration
information to the state.
Submission of
Registration
information
System acknowledges acceptance of
information or send error message in
case of failure..
User is notified the outcome.
User is send to WIPP if registration is successful.
The state will implement registration service and will expose it as a SOAP/HTTP web service. IWRS
application will implement the web service client to consume the registration web service. Since all
registration data will be stored in the state system, this will be one way interface.
4.2.2 Questions Administration
The IWRS “Questions Administration” component will be responsible for allowing state administrator to
configure questions. This component will allow addition of new questions and modification or expiring
of existing questions. The module will be implemented using set of JavaServer faces, business
component and data service. Once a state administrator is done with changes, a display preview will be
shown to the user. The questionnaire configuration information will be stored in the IWRS database
along with business rules.
24
IWRSSoftware Architecture Document
4.2.3 Manage Account
The IWRS information is stored in the LDAP. In the cloud hosted solution, IWRS will have centralized
LDAP server which will store user information and user groups associated with user. Following user
information will be stored in the LDAP.









UserID
Password
First Name (Required)
Last Name (Required)
Middle Initial (Optional)
Email Address (Required)
Zip Code (Optional)
SSN (Optional)
Answers to secret questions (Required)
Following secret questions will be configured by default and can be changed based on state needs:
#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Question
What is the name of a favorite pet?
What is the name of your favorite restaurant?
What is the name of a favorite teacher?
Name a city you would like to visit.
What is your favorite jelly bean flavor?
Name your favorite fictional character.
Name your favorite athlete.
What is the street name where a relative lives?
What is the name of your favorite band?
What is the title of your least favorite movie?
For centralized hosted LDAP server following LDAP structure will be created to store user information
and user attributes. IWRS will use OpenDJ LDAP server which will be installed in the Data tier.
25
IWRSSoftware Architecture Document
org
us
dol
ny
MS
user
user
JSmith
JDove
DSmith
IWRS LDAP Structure
The Manage Account component will be responsible for managing user information and user groups
associated with the user. IWRS will implement LDAP service which will be wrapper over OpenDJ SDK to
manage user information in the LDAP.
4.2.4 Self Service
The self service module will allow user to reset the password or send userid in case user has forgotten it.
The self-service component will be implemented using set of JavaServer Faces (unsecure), business
component and LDAP Service.
In case where user has forgotten his or her userid, application will ask user to enter answers to set of
secret questions which the user has set up during initial account creation process. If the user answers all
questions correctly then the userid is sent to user’s email or mobile (SMS). In case of unsuccessful
attempt, user is allowed to retry (based on configured retry attempts). If user fails to answer secret
questions then user will be asked to contact Help Desk. Application will provide Help Desk contact
information to the user.
26
IWRSSoftware Architecture Document
In case where user has forgotten password, user will be asked to enter his or her user id. If user id is
present in the system then user will be asked to answer secret questions. Once user answers all
questions correctly, a temporary password will be sent to his/her email address or mobile (SMS). In case
user fails to answer secret question, it will follow same path as “forgotten userid” use case.
4.2.5 State Profile Manager
The state profile manger module will be responsible for storing state specific configuration information
e.g. services available for the states, registration data elements etc. This component will be
implemented using set of JavaServer Faces, business service and data service. The data will be stored in
the centralized IWRS database.
4.2.6 IWRS Data Service
The IWRS data service will provide data access framework for all IWRS modules. The services which
implements data access service will derive base implementation from IWRS Data service. IWRS Data
Service will be based on Java Persistence API.
4.2.7 IWRS LDAP Service
The LDAP service will be wrapper over OpenDJ LDAP SDK. The wrapper service will allow application
modules flexibility of interacting with any LDAP server without making changes to API call.
4.3 Data Tier
The data tier is responsible for storing data related to application as well as user information. The data
tier will consist of relational database as well as LDAP. IWRS/WIPP data service layer will be
implemented based on Java Persistence API (JPA) which can support most of the relational databases.
IWRS/WIPP data access layer will be validated using MySQL and Oracle database. GCOM will document
the configuration changes required to switch from one database to another. The relational database will
be responsible for storing following information







The state specific configuration (profile) information
State specific questionnaire
Common questionnaire
Job Event information
Common messages if any
Temporary data e.g. Bulk upload of Job seeker information
Profile page configuration specific to jobseeker (user personalization)
IWRS user information will be stored in the OpenDJ LDAP information. Please refer to “Manage
Account” section for more information about LDAP structure.
27
IWRSSoftware Architecture Document
4.4 Integration Tier
The integration tier will be responsible for communicating with state services to query and fetch the
data. State services will be exposed using SOAP/HTTPs. IWRS will have set of adapters which will be
responsible for communicating with state services. The IWRS web service adapters will have following
responsibilities:
 Map data from IWRS to State required interface.
 Handle Service up and down messages. If state decides to implement service up and down
messages, IWRS will be cognizant of that and it will take appropriate action to notify its
consumer.
 Handle error messages and notify consumer.
The data between IWRS and state services will be encrypted using SSL certificate.
4.5 Infrastructure Services
The infrastructure services are cross cutting concerns which are responsible for implementing services
across all tiers. Following infrastructure services will be implemented by IWRS/WIPP.
4.5.1 Logging
IWRS/WIPP modules will use Java Standard Logging framework to log the application information for
debugging purpose. IWRS/WIPP will implement wrapper class over Java Standard logging framework
which will allow states (state hosted applications) to change logging framework without affecting
business layer or clients of logging framework. The development and test environment log level will be
set to “DEBUG” for stage and production environment log level will be set to “ERROR”. Please refer Java
Logging Overview for more information about logging information.
4.5.2 Auditing
IWRS/WIPP will audit user actions in the database. The audit service will store audit information in the
centralized database. Each IWRS/WIPP module will be responsible for storing audit information.
4.5.3 Validators
IWRS will use Apache validation classes to perform common validations like null check, email address
etc. If custom validations need to be implemented then those will be part of IWRS validation service.
The validation service will be implemented either in Java or using DROOLs.
4.5.3.1 Exception Handler
IWRS/WIPP exception handling classes will be responsible for implementing base exception classes.
IWRS/WIPP exception handler framework will implement checked and unchecked exception classes. All
IWRS/WIPP modules will derive module specific exception classes from these base classes.
28
IWRSSoftware Architecture Document
4.5.4 Exception Reporter
Exception Reporter service will be responsible for reporting exception information to the user via email
or by writing to log file.
29
IWRSSoftware Architecture Document
5 Application Structure
IWRS Common
Framework
Java 1.5
JEE 1.5
OS
Registration
Questions Administration
Manage Account
Self-Service
State Profile Manager
WIPP Interfaces
Common Domain Classes
Auditing
Validation
JDK
Exception Handler
LDAP Service
Data Service
Exception Reporter
Third Party Classes like Tohu, DROOLS,
Apache Validators etc.
IWRS Services
This section describes the IWR/WIPP application structure and dependency. At the bottom of the layer is
the Operating System. IWRS/WIPP can be hosted on Windows Server, AIX, any flavor of UNIX which is
supported by Java and Linux. IWRS/WIPP Framework and services will be built on Java 1.6 and JEE 6
versions. IWRS/WIPP will utilize features like Generics, Annotations etc. to implement IWRS/WIPP
Framework components and services.
Logging
JRE
Linux/Windows/AIX/UNIX
IWRS Application Structure
The framework components and modules will be developed using Java and JEE components such as
Enterprise JavaBeans (Stateless Session Bean, Message Driven Bean etc.), Third party classes such as
Tohu, DROOLS, Apache Validators etc.
30
IWRSSoftware Architecture Document
6 High Level Design
At high level, IWRS has two design patterns. The first pattern is where IWRS frontend e.g. Registration is
making request for backend services while second pattern is where WIPP is making request for IWRS
backend services. Following section describes both design patterns in detail.
6.1 IWRS Client
The IWRS client or frontend is responsible for Job Seeker, System Administrator and State Staff to
expose the functionality of IWRS services. The IWRS client can be hosted on the same server as IWRS
backend (same JVM) or can be deployed remotely (different JVM). The IWRS client will be dynamic web
application and will be installed on application web container while IWRS backend is installed in
application container.
Value Objects
Domain Objects
Entity Objects
IWRS
DB
Data Access Service
JavaServer Faces
(IWRS Client)
Managed Bean
Enterprise Stateless
Javabean
Business Delegate
Business Service
Service Interface
Adapter
(Web Service Client)
State System
EJB
Client
LDAP Service
IWRS LDAP
High Level Design – IWRS Client
1. Application user makes request to IWRS client. The IWRS client will be implemented using
JavaServer Faces, RichFaces, JQuery, CSS and HTML pages. The controls on the web page e.g. text
box, list, drop down boxes will be bound to a Managed bean. A Managed bean is a plain Java class
which is developed based on JavaBean standard. Once user submits the data, all values from HTML
controls are passed to Managed bean.
2. The data in the Managed bean is validated using JavaServer Faces validation classes. In case of
validation error, error message is displayed on top of the page. If data validation is successful then
31
IWRSSoftware Architecture Document
3.
4.
5.
6.
7.
data in the managed bean is passed to business delegate. Business delegate knows how to create an
instance of business service and invoke the different operation on it. Please refer Business
Delegatelink for more information about this pattern.
Business Delegate creates instance of Enterprise JavaBean and invokes operation e.g. register.
Enterprise JavaBean then performs following functions
a. Starts business transaction with the help of J2EE application container.
b. Performs auditing of business call.
c. Calls actual business service to perform business function.
Business services then makes call to other services (Data Access Service) or adapters (State service)
to perform business functionality.
Business service is responsible for mapping domain objects to entity objects. The data service is
responsible for storing data in IWRS database.
The data service will be implemented using Java Persistence API.
6.2 WIPP Client
The WIPP application is responsible for presenting services (UI, ES, and WIA) available to Job Seeker. The
WIPP client can be co-located (same JVM) or can be installed remotely on different network. The IWRS
backend service will act as a data exchange service and will provide services requested by WIPP. The
services provided by IWRS to WIPP client are exposed as a REST Web Service.
JSON/XML
Domain Objects
Entity Objects
IWRS
DB
Data Access Service
WIPP
REST Web Service
Service Interface
Adapter
(Web Service Client)
Business Service
State System
LDAP Service
IWRS LDAP
High Level Design – WIPP Client
Following steps describe the application flow when user navigates to WIPP
1. User is navigated to WIPP either from registration module or from state web site.
2. Application displays different sections (e.g. Message Center, Calendar, Chat etc.) on profile page
based on state and user preferences. Profile page sections are displayed based on what
functionality state has enabled. State can enable/disable particular section as per their need.
32
IWRSSoftware Architecture Document
3.
4.
5.
6.
7.
Further user can customize state enabled sections (i.e. hide the section, set configuration
parameters etc.)
For each of the section configured on the page, application makes call to IWRS to fetch the data.
All of these calls will be done simultaneously using AJAX.
IWRS will contain business service for each of the WIPP service which will be responsible for
making calls to state service using IWRS Service adapter.
The service interface will be responsible for constructing web service call to state service and
receiving response from state service.
Once response is received from state, it will be passed to WIPP via business service.
In case of error (e.g. state service is not available, communication error etc.) WIPP will display
user friendly message to end user.
Since WIPP can be hosted locally or remotely on different network (geographically) it was
decided to use RESTFul web services than EJB. Appendix A describes difference between using
RESTFul web service and EJB service technology.
7 Network Infrastructure
This section illustrates the recommended hardware configuration of the System, featuring a scalable and
highly available architecture. Please note that the specific configuration for IWR System will be
determined according to many factors, such as:



33
Expected load on the system
High availability and Disaster Recovery (DR) requirements
Cost
IWRSSoftware Architecture Document
The production architecture, supporting the availability targets, is shown in the example figure below,.
IWRS Cloud/State Production Environment
IWRS/WIPP users can access application through Internet (Jobseeker) or Intranet (state staff).
The sample architecture features:



34
2x Load Balancers with internal fail-over capability, balancing user sessions across the active
Web Server clusters
Clustered Proxy Web Servers outside the firewall hosting the web services - these are accessed
by customers over the internet.
Clustered Web Servers inside the firewall hosting the web services - these are accessed by State
Staff/internal users over the intranet (WAN/LAN).
IWRSSoftware Architecture Document





Clustered Application Servers hosting the application services - clustering functionality is
supported by the application framework.
Clustered Primary Database Servers hosting the database instances - database instance fail-over
can be managed by a COTS clustering product
Standby Database Server, used for reporting as well as a standby database server
Primary and Standby Storage Units, hosting the disk storage subsystems - the primary storage is
generally a high-quality storage unit, and the stand-by medium quality.
Media Servers, for managing partial and full back-ups process, collocated in the Standby
Database Server and having no performance impact on the online transactions.
The architecture also supports Disaster Recovery (DR) across data centers. The DR configuration also
supports active-passive as well as active-active configurations at the web and application server layers,
with the clustered primary database server being the primary active database, which replicates to the
standby database server located in the remote data center. The ultimate configuration will be
architected based on the standards set by ITSC and State staff.
35
IWRSSoftware Architecture Document
8 Hosting Solution
There are two types of hosting solution for IWRS.
1. Cloud Hosted
2. State Hosted
8.1 Cloud Hosted
The IWR/WIPP components of the solution including the registration system will be hosted in cloud.
However, the database and other state developed components like Triage, Job Search, Job Match and UI
components, etc., will be hosted by the participating state.
State has to expose the integrating components as a secured public web service for the cloud hosted
solution to integrate with. The web service must match the WSDL published after the application detail
design.
OpenAM will be used for Single Sign On. A federation component will be available to integrate with a
state owned SSO system if the participating state owns such system.
State Systems
IWRS
ES
SOAP/HTTPs
UI
IWRS
IWRS
WIA
Cloud Hosted Solution
36
IWRSSoftware Architecture Document
8.2 State Hosted
The participating state hosts all the IWR components in their environment including the cloud
components. The components will integrate locally within their infrastructure. The participating state
will use its state owned Single Sign On system.
State Systems
ES
SOAP/HTTPs
z
UI
IWRS
IWRS
WIA
State Hosted Solution
37
IWRSSoftware Architecture Document
9 Single Sign On
The IWR/WIPP system will provide the state with the capabilities to accept and validate user’s
authorization credentials. During the login process, the user will have the capabilities to utilize a user id
and password to enter into the workforce systems using the IWR/WIPP system. This will provide Single
Sign On (SSO) capabilities to the state’s workforce systems. If the state already has a solution that
addresses these capabilities, then the IWRS/WIPP will federate with that model and validate the user’s
credentials using the state federation agent.
When IWRS user attempts to access a protected resource before being authenticated, the web policy
agent intercepting the browser's request finds no session token in the request, and so redirects the
user's browser to the IWRS login page for authentication. After the user has successfully authenticated,
OpenAM sets a session token in a browser cookie, and redirects browser back to the page the user tried
to access initially. The following diagram shows how the pieces fit together when a web client accesses a
web page protected by a policy agent.
Web Browser
5
OpenAM
1
3
2
Policy Agent
IWRS website
4
Apache HTTP Web Server hosted on IWRS
IWRS Authentication Flow
The web policy agent will be installed in the web server and configured to be called by the web server
when an IWRS client requests access to a protected resource on the IWRS application.
1. The IWRS user requests access to a protected resource.
38
IWRSSoftware Architecture Document
2. The web server runs the request through the policy agent that protects the resource according
to OpenAM policy. The policy agent acts to enforce policy, whereas the policy configuration and
decisions are handled by OpenAM.
3. The policy agent communicates with OpenAM to get the policy decision to enforce.
4. For a resource to which OpenAM approves access, the policy agent allows access.
5. The web server returns the requested access to the IWRS web user.
The IWRS/WIPP application can be hosted in the cloud or can be hosted locally. In case of cloud hosted
solution if participating state has OpenAM solution then it will use cloud based OpenAM in federated
mode. If participating state does not have OpenAM then it will use cloud hosted OpenAM solution. In
case of state hosted IWRS/WIPP solution, IWRS/WIPP will use state hosted OpenAM solution.
39
IWRSSoftware Architecture Document
10 Technology Stack
This table documents the technology stack for IWRS.
Product/To
ol
1. Eclipse
Juno
Version
Description
Environment
Juno
Dev
2. JBoss
Application
Server
7.1.1
Eclipse is a multi-language software
development environment comprising a
base workspace and an extensible plug-in
system for customizing the environment.
It is written mostly in Java.
It can be used to develop applications in
Java and, by means of various plug-ins,
other programming languages including
Ada, C, C++, and COBOL. Development
environments include the Eclipse Java
development tools (JDT) for Java and
Scala, Eclipse CDT for C/C++ and Eclipse
PDT for PHP, among others.
JBoss Application Server (JavaBeans Open
Source Software Application Server) is an
application server that implements the
Java Platform, Enterprise Edition (Java
EE). It supports the following features:












40
Dev
Test
Stage
Prod
Aspect-oriented programming
(AOP) support
Clustering
Deployment API
Distributed caching (using JBoss
Cache, a standalone product)
Distributed deployment (farming)
Enterprise JavaBeans versions 3
and 2.1
Failover (including sessions)
Hibernate integration (for
persistence programming; Java
Persistence API or JPA)
Java Authentication and
Authorization Service (JAAS)
Java EE Connector Architecture
(JCA) integration
Java Management Extensions
Java Message Service (JMS)
IWRSSoftware Architecture Document













3. JBoss
Drools
4. Tohu
Framework
5.5.0
1.3.1
integration
Java Naming and Directory
Interface (JNDI)
Java Transaction API (JTA)
Java Authorization Contract for
Containers (JACC) integration
JavaMail
Java Server Faces 1.2 (Mojarra)
Java Server Pages (JSP) / Java
Servlet 2.1/2.5 (Tomcat)
JBossWS (JBoss Web Services) for
Java EE web services like JAX-WS
JDBC
Load balancing
Management API
OSGi framework
RMI-IIOP (JacORB, contraction of
Java and CORBA)
SOAP with Attachments API for
Java (SAAJ)
Drools is a Business Rule Management
System (BRMS) with a forward chaining
inference based rules engine, more
correctly known as a productive rule
system, using an enhanced
implementation of the Rete algorithm.
Drools supports the JSR-94 standard for
its business rule engine and enterprise
framework for the construction,
maintenance, and enforcement of
business policies in an organization,
application or service.
Tohu is an engine built on Drools to
create dynamic UIs. It is an alternative to
the traditional MVC approach which
instead uses a generic UI layer to render
arbitrary UIs defined using simple
business rules.
Dev
Test
Stage
Prod
Dev
Test
Stage
Prod
Most forms have some sort of dynamic
41
IWRSSoftware Architecture Document
behaviour where the value a user types in
one field affects whether or not to show
another field. Tohu makes this sort of
thing extemely easy to build and
maintain. Typically you can have the
logic of your forms (and page flows)
working within days or even hours, and
then someone with a different set of skills
(e.g. CSS / UI design) can make it look
nice.
There are 3 core components:



5. MySQL
42
5.6
Questionnaire rule support. This
is a set of Java based classes that
enable specific Questionnaire
rules to be created and used in a
rule based application.
Rule Execution Server. While this
is actually a separate project
being worked on by JBoss staff, it
is included here as it is a
fundamental part of the solution.
The execution server provides a
service interface into the Rule
Engine (output is XML or JSON currently only XML is supported
in Tohu).
User Interface Display
libraries. This takes the output
from the Execution Server and
creates the required
interface. The first available
interface generates HTML via a
JavaScript library that is based on
JQuery, but other interfaces are
expected to be provided in
future. e.g. Eclipse Rich Client.
MySQL is an open source relational
Dev
IWRSSoftware Architecture Document
database management system (RDBMS)
that runs as a server providing multi-user
access to a number of databases.
Test
Stage
Prod
MySQL works on many different system
platforms, including AIX, BSDi, FreeBSD,
HP-UX, eComStation, i5/OS, IRIX, Linux,
Mac OS X, Microsoft Windows, NetBSD,
Novell NetWare, OpenBSD, OpenSolaris,
OS/2 Warp, QNX, Solaris, Symbian,
SunOS, SCO OpenServer, SCO UnixWare,
Sanos and Tru64. A port of MySQL to
OpenVMS also exists.
6. JavaServer
Faces
7. Rich Faces
2.1
4.2.3
JavaServer Faces technology simplifies
building user interfaces for JavaServer
applications.
Developers of various skill levels can
quickly build web applications by:
assembling reusable UI components in a
page; connecting these components to an
application data source; and wiring clientgenerated events to server-side event
handlers.
RichFaces is an open source Ajax-enabled Dev
component library for JavaServer Faces
hosted by JBoss. It allows easy integration Test
of Ajax capabilities into enterprise
Stage
application development.
Prod
RichFaces is more than just a component
library for JavaServer Faces. It adds:




8. PrimeFaces
43
3.5
Dev
Test
Stage
Prod
Skin ability (easily change and
update application look and feel)
Component Development Kit
(CDK) to assist in constructing
JavaServer Faces components
Dynamic Resource Framework
Both page wide, and component
based Ajax control components.
PrimeFaces is an open source JSF
Dev
IWRSSoftware Architecture Document
9. Java
Persistence
API
(Hibernate)
4.0.0
component suite with various extensions.
• Rich set of components (HtmlEditor,
Dialog, AutoComplete, Charts and many
more).
• Built-in Ajax based on standard JSF 2.0
Ajax APIs.
• Lightweight, one jar, zero-configuration
and no required dependencies.
• Ajax Push support via websockets.
• Mobile UI kit to create mobile web
applications for handheld devices.
• Skinning Framework with 35+ built-in
themes and support for visual theme
designer tool.
• Extensive documentation.
• Large, vibrant and active user
community.
• Developed with "passion" from
application developers to application
developers.
Hibernate is an object-relational mapping
(ORM) library for the Java language,
providing a framework for mapping an
object-oriented domain model to a
traditional relational database. Hibernate
solves object-relational impedance
mismatch problems by replacing direct
persistence-related database accesses
with high-level object handling functions.
Test
Stage
Prod
Dev
Test
Stage
Prod
Hibernate is free software that is
distributed under the GNU Lesser General
Public License.
Hibernate's primary feature is mapping
from Java classes to database tables (and
from Java data types to SQL data types).
Hibernate also provides data query and
retrieval facilities. It also generates the
SQL calls and attempts to relieve the
developer from manual result set
handling and object conversion and keep
the application portable to all supported
SQL databases with little performance
overhead
44
IWRSSoftware Architecture Document
10. OpenAM
10
OpenAM is an open source access
management, entitlements and
federation server platform.
Dev
Test
Stage
Prod
OpenAM is designed in response to
legacy access management bundles
thrown together via acquisition—with
differing architectures, APIs, libraries,
user-interfaces, and documentation that
pass integration costs and complexity on
to customers.
OpenAM is the world’s only open source,
purpose-built, all-in-one access
management platform able to secure and
share resources across enterprise, cloud,
social, and mobile environments.
Unique Benefits :



11. OpenDJ
45
2.4.6
It is the only developer-friendly
access management solution to
use a single, common
programming interface (REST)
that’s easy to invoke.
It is the only “All-in-One” Access
Management solution that
includes Authentication, SSO,
Authorization, Federation,
Entitlements, Adaptive
Authentication, Strong
Authentication, and Web
Services Security in a single,
unified product.
OpenAM is based on the Sun
OpenSSO codebase for
modularity, lightweight
flexibility, and massive scalability,
available to all. It’s an easy way
for form.
OpenDJ is a free, open source Lightweight
Directory Access Protocol (LDAPv3) and
Directory Service Markup Language
(DSMLv2) compliant directory service
written in the Java programming
language.
Dev
Test
Stage
Prod
IWRSSoftware Architecture Document
One of the key design principles of the
OpenDJ architecture is addressing
scalability and performance to deal with
high throughput and low latency
response requirements. Highly robust
replication helps to ensure data
availability for consistent, reliable access
to identity data at all times. In addition,
advanced features such as Assured
Replication can be used to guarantee
data availability in the event of server
failure. For geographically distributed
environments, OpenDJ supports WANoptimized replication for increased
bandwidth efficiencies.
12. Maven
3.0.5
13. Jenkins
1.502
14. Sonar
3.4.1
Apache Maven is a software project
management and comprehension tool.
Based on the concept of a project object
model (POM), Maven can manage a
project's build, reporting and
documentation from a central piece of
information.
Jenkins is an open sourcecontinuous
integration tool written in Java.
Jenkins provides continuous integration
services for software development. It is a
server-based system running in a servlet
container such as Apache Tomcat. It
supports SCM tools including CVS,
Subversion, Git, Mercurial, Perforce and
Clearcase, and can execute Apache Ant
and Apache Maven based projects as well
as arbitrary shell scripts and Windows
batch commands.
Dev
Sonar is an open platform to manage
code quality. As such, it covers the 7 axes
of code quality:
Dev



46
Dev
Architecture and Design
Duplications
Unit Tests
IWRSSoftware Architecture Document




15. Rational
ClearQuest
Web
47
7.0.1.2
Complexity
Potential bugs
Coding rules
Comments
IBM Rational ClearQuest is application
lifecycle management (ALM) software
that provides flexible change and defect
tracking, customizable processes, realtime reporting and lifecycle traceability
for better visibility and control of the
software development lifecycle. This
solution provides scalable, multiplatform
support to any size organization, so you
can continue to use your customized
processes as your organization’s needs
evolve. Rational ClearQuest supports the
IBM AIX, HP-UX, Linux, Sun Solaris and
Microsoft Windows operating systems.
Rational ClearQuest can improve visibility
and control of software development
projects.
 Enhance software quality with
built-in defect and changetracking capabilities.
 Customize and automate
workflows for greater efficiency
and predictability. Develop best
practices with the ALM template.
 Simplify compliance
management with tools that help
you efficiently manage
compliance processes and track
approvals.
 Gain visibility into projects with
real-time reports for better
decision making.
 Leverage enhanced
integrations with several other
IBM lifecycle products for a
complete ALM solution.
Test
IWRSSoftware Architecture Document
11 Appendix A:
REST Webservice
1. HTML form componentsare directly bound
to REST service. Since REST web service
will be deployed on the backend all
validations will happen on the backend.
This will have performance impact on the
application.
2. With RESTful service all validation errors
are send back to client/consumer as XML
data, the client needs to decode the XML
(error) and display to the user. This adds
complexity to the validation process.
3. RESTful service implementation can be
consumed by any webservice client (Java,
.Net, etc)
4. In RESTful implementation, the transaction
control needs to be implemented by
application which adds complexity. REST
standard does not talk about transaction
implementation.
5. Tohu is a framework on top of Drools that
allows interactive web applications to be
built from rule definitions. Tohu uses AJAX
calls and does not support RESTful web
service implementation.
6. RESTful web service is based on HTTP
protocol that implies installing HTTP
servers in the middle tier.
48
EJB
1. User input data from the screen/form is
bound to the JSF bean as Java object, it
can be directly exchanged with EJB
without any further conversion also HTML
form data can be validated using out of
box JSF validations. Using this approach
avoid extra calls to IWRS backend service.
2. Java object can be directly exchanged with
the EJB; any validation error from the
server side can be thrown as a user
defined exception to the client. The client
can catch the exception and display the
user friendly validation error to the user.
This makes validation process simpler.
3. The client needs to be Java
implementation.
4. In EJB implementation, transactions are
controlled by container; developer does
not have to write code.
5. With EJB implementation, Tohu can
remain frontend component and once
user completes registration process, data
can be passed from Tohu to EJB.
6. EJB is based on IIOP protocol which is part
of JEE container. With EJB 3, development
and deployments of EJBs are much
simpler.
IWRSSoftware Architecture Document