caTissue Suite Code Jamboree I Action Items and ... - NCI Wiki

saucecopywriterInternet and Web Development

Feb 2, 2013 (4 years and 2 months ago)

165 views


Tissue Banks and Pathology Tools Workspace

caTissue Suite Code
Jamboree I

Action Items and Discussion Summaries

June 22
-
24, 2011

University of Colorado Denver

Anschutz Medical Campus

Notes compiled by Beth DiGiulian <digiulian_beth@bah.com>

Page
1

of
27


Contents

Summary Action Items

................................
................................
................................
................................
..

2

Code Jamboree Goals

................................
................................
................................
................................
.

10

Presentations

................................
................................
................................
................................
..............

11

Discussion Summaries

................................
................................
................................
................................
.

11

A.

Reorg
anization of the Code Structure

................................
................................
............................

11

B.

Graphical User Interface

................................
................................
................................
.................

11

C.

Connecting with External Web Applications

................................
................................
...................

12

D.

Tools for Managing Open Source Development

................................
................................
.............

12

E.

Exception Handling

................................
................................
................................
.........................

13

F.

Gen
eral Code Suggestions

................................
................................
................................
..............

13

G.

Reconciling Local Versions and Interoperability

................................
................................
.............

13

H.

API Layers and Services

................................
................................
................................
...................

14

1.

General Comments

................................
................................
................................
.....................

14

2.

SOA (access module through web service) or Modularization?

................................
.................

14

3.

Higher Level API: caRUBY Details

................................
................................
................................

15

I.

Plug
-
In Architecture

................................
................................
................................
........................

15

J.

B
uild Deploy Automation Discussion

................................
................................
..............................

16

K.

General Documentation Issues

................................
................................
................................
.......

17

L.

Architecture Diagram Suggestions and Comments

................................
................................
........

18

M.

Cookbook wiki


Knowledge Base for Developers

................................
................................
......

19

N.

Community Code Contributions

................................
................................
................................
.....

20

O.

Hands
-
on Session to Bring a Code Modification into caTissue Main Branch

................................
.

20

Miscellaneous

................................
................................
................................
................................
.............

20

Summary Quick Fixes for caTissue 2.0 (Original List from Jamboree Notes)

................................
.............

21

Future Discussion Topics/ Demonstrations/ Hands on Sessions to Schedule

................................
............

21

How to Keep the Code Jamboree Going?

................................
................................
................................
...

21

Appendix

................................
................................
................................
................................
.....................

22

1.

Ranking of Code Jamboree Sessions

................................
................................
...........................

22

2.

caTissue Architecture Diagram

................................
................................
................................
...

23

Page
2

of
27


3.

Idea for Creating an Extension Development Environment to

Enable Reconciliation of Local
Versions (Joshua

Phillips):
create a patch using Eclipse or any IDE you choose then submit to
crucible to development team as a patch file.

................................
................................
...................

24

4.

Special BDA Instructions For MAC:

................................
................................
.............................

24

Attendance

................................
................................
................................
................................
..................

25


Summary Action Items

Note that the Reference column contains hyperlinks to the section where the action
item is described in
the notes.

No.

Description

Assigned To

Scope

Reference

1

All java source files need to move
out of web
-
inf.

Denis

Krylov

2.0

Reorganization
of
the
Code Structure

2

Repair the Jar file dependencies.
Note JAR versions and
corresponding Jar source code in
the SVN repository. Dependencies
between Jar files should also be
noted.

Denis

Krylov

2.0

Reorganization
of
the
Code Structure

3

Cleanup mismatches between
entity/category and duplicate class
names. Duplicate class names are
permitted across mult
iple entity
groups.

Sri

Adiga


Show what has been
completed prior to 2.0


some mismatches have been
repaired

Out of scope for 2.0


Agenda
item
for Code
Jamboree II

Reorganization
of
the
Code Structure

4

Reconsider placement of business
logic.

Sri

to look at future clean
-
up/


Also need to detail where it
has already been fixed.

Out of scope for 2.0,
although there has been
some cleanup of

business
logic

e.g.
.

Pa
r
ticular
modules that the
dev
elopment

team were
aware of were addressed
in 2.0. We can point to
those as improvements.
Direct people to it and get
feedback.


(Short term)

Deep dive into
caTissue
current
architecture
Reorg
anization
of the
Code Structure

&
Connecting with
External Web
App
licati
on
s

5

Consider providing a diagram to
detail

what variables are associated
with which object.

2.0/KC team

2.0

Making sure the object
model is available and up
to date.

Reorganization
of
the
Code Structure

6

Provide a document or wiki page
that describes the SVN repository
naming convention.

2.0

2.0

Reorganization
of
the
Code Structure

Page
3

of
27


No.

Description

Assigned To

Scope

Reference

7

Create a caTissue trunk. Clean up
the SVN branches and trunks: make
it easier to determine where to add
customized areas

Denis Krylov

2.0

Reorganization
of
the
Code Structure

&
Connecting with
External Web
App
licati
on
s

8

Consider moving GUI customization
to a
n external properties file.


Out of scope for 2.0.
To be
discussed during
Code
Jamboree II

Graphical User
Interf
ace

9

Consider areas that are of gen
eral
use and where improvements could
be made for the GUI (see list in
notes)


Out of scope for 2.0.
Future re
-
architecting

Graphical User
Interf
ace

10

Auto
-
population of Patient
Demographics should be a common
extension point in caTissue


Out of scope for 2.0. Code
Jamboree II


Add to caTissue wish list

Connecting with
External Web
App
licati
on
s

11

Create a “higher level” API to make
it easier to connect with external
apps


Out of scope for 2.0. Code
Jamboree II


Add to caTissue wish list

Connecting with
External Web
App
licati
on
s

12

List what the “happy set” of
development tools are, so that
people have a guide to what has
worked well for the developers and
others

KC to create
the shell


Dev
elopment

team to start
list

Dev
elopment

team to
create list and hand to KC
to create a community
page and get
contributions.


(Short term)

Tools for Managing
Open Source
D
evelopment

13

Determine if NCI should help clarify
and standardize the exception
handling process.


Out of scope for 2.0

Exception Handling

14

At startup, have business logic
checks against objects
.


Li Wen


Vanderbilt. This is a
problem when one doesn’t use the
API. If we have to check everything
at startup against the database (x,y
in scope or

not) may make startup
too exhaustive.


We

need to make sure the
API can cover needs so
that customizers don’t
have to

modify the
database directly.


May be o
f value
to have a
database sanity check e.g.

“yes db is ready and will
work with caTissue”

General Code
Suggestions

Page
4

of
27


No.

Description

Assigned To

Scope

Reference

15

Replace institution name/logo
should be part of install process
.


Would
display your logo in
caTissue.

Community


Li Wen

(Vanderbilt)


Need to check with
developers to verify

this
process


Fred Loney volunteered to
produce a requirements
document for this.

Show as a demonstrable
community contribution in
2.0.


Should have this e
ither as
part of the install or part of
the configuration.



Need further detail on
functionality. Good topic
for monthly technical calls
sta
rting October 3 @ 2 PM
Eastern.

General Code
Suggestions

16

Determine who should be
addressing the CAS authentication
issue. Should it be addressed by the
caTissue development team?

Dev team

2.0

General Code
Suggestions

17

STRUTS should manage actions on
themselves
, and should not
delegate.


Out of scope for 2.0.


Open dev would really
help with this. Could show
where there are instances
of

this and provide to dev
team.

General Code
Suggestions

18

Test Joshua Phillips solution for
creating an extension development
environment to enable
reco
nciliation of local versions.

Bart Brown

to work with
Joshua Phillip using 1.2 code
base


Output is a cookbook article.

Immediate


Ensuring this works is part
of the SVN re
-
organization.


Determine what is the
happy extension
development
environment.

(
Joshua
used Eclipse to develop
the a
pproach to apply
changes in your own build.


Good for a future
caTissue
Code Customization
Monthly call (starting Oct
3)
Get feedback from
community.
Possible
ag
enda item for Code
Jamboree II

Reconciling Local
V
ersions and
Interoperability

19

Create a high level (less granular)
API to facilitate handling
transactions. Duplicate.

Duplicate


See 11

Duplicate


See 11

API
Layers and
Services

20

Create a high level service which
allows the full object graph to be
saved (persists the object model)

See 11

See 11

API
Layers and
Services

Page
5

of
27


No.

Description

Assigned To

Scope

Reference

21

Expose the business layer logic so
that one could use that information
to define the higher level coarse
operations and then create a
courser granularity of the messages
being exchanged.
See
if the LSLR
will share their business logic
.

See 11


Ian/Brent

See 11


Have a formal review of
what Semantic Bits has
that is relevant from the
LSLR effort.

API
Layers and
Services

22

Further discuss if the community
believes caTissue should have more
plug
-
ins similar to what has been
done for label generation/printer
integration. If so, how should it be
architected? How do we make sure
there is
access to the necessary
data from the plug in?


Out of scope for 2.0. Part
of

a

comprehensive
overview of caTissue
architecture.

Plug
-
In
A
rchitectur
e

23

The BDA instructions should be
more specific

KC draft wiki page /Dev
Team fills in

2.0


Draft wiki page.

Build Deploy
Automation

Discussion

24

We need consistency in build
version names/tag names. This
impacts the BDA, bug tracking, and
the SVN.

Bijoy George

2.0

Build Deploy
Automation

Discussion

Page
6

of
27


No.

Description

Assigned To

Scope

Reference

25

Report what the default values are
in the Build


Some improvements are in
2.0. Partially meets. BDA
instructions will have pre
-
reqs for what needs to be
installed and


a.When you download
caTissue you shouldn’t
have to change things.
Defaults should not make
assumptions about
what
you have to make.
Consideration for future
arch review.


b.IN SCOPE for 2.0.
Properties files need to be
populated with default
values.


c
. Anytime you build
caTissue there should be a
logging of the properties
file that stays with the
build

i.e.

s
omething
produced by the ANT
script. Saving what you
se
e by what comes back
from ANT.


Agenda item for Code
Jamboree II.


Build Deploy
Automation

Discussion



Look
up in the raw notes

26

Consider how best to modify the
upgrade scripts for example: If you
have the object

model in
java/hibernate model/database
scripts, all have to be in synch to
allow changes to be effective,
which then makes it difficult to
make changes.


More discussion needed.


This action item m
ay be
more about
issues with the
caCoreSDk than
with
caTissue
.

Build Deploy
Automation

Discussion



Page
7

of
27


No.

Description

Assigned To

Scope

Reference

27

We need better information on the
dependencies of what caTissue
needs in the tech stack.

KC manag
e/ Dev Team can
discuss current stack

2.0


If there are known issues
with any of the tech stack
we should make note.


Create disclaimer.



Community can also
provide input for other
version issues.


Short term.

Build Deploy
Automation

Discussion

28

Correct needing to use different
versions of JBoss when deploying
caTissue and caGrid 1.4.


2.0

Build Deploy
Automation

Discussion

29

Have more descriptive internal
exception errors, for example one
could put a stack trace on the
server log


Out of scope for 2.0

Build Deploy
Automation

Discussion

&
General
Documentation
Issues

30

Need to put in an IVY repository for
the Oracle drivers, etc. in the NCI
SVN so it is easier to updat
e the
BDA.

Rakesh

Rakesh to ask Dev team
about this and get back to
us.

Build Deploy
Automation

Discussion

31

Add the MAC BDA process to the
BDA documentation


Building caTissue using a MAC vs a
PC.

Community


Check with Denis

Make sure we review BDA
documentation and th
at
som
eone can build BDA on
the MAC.


Cookbook article


Sept 13

Build Deploy
Automation

Discussion

32

We need module level/ package
level documentation diagrams. We
also need doc
umentation of code
structures.

KC/Dev

2.0 partially meets.


Outside

2.0 KC/Dev team
further work.

General
Documentation
Issues

Page
8

of
27


No.

Description

Assigned To

Scope

Reference

33

We need a description of the role
the
caCore
SDK has in caTissue
Suite.


2.0


Proper documentation of
the architecture


design
doc should have this
covered.



How does the caTissue API
relate to a generated
standard API from the
caCoreSDK?

Needs
better description of those
things and how they work.

General
Documentation
Issues

34

We need more detailed
design
documentation on the advanced
query module and the dynamic
extensions module. There are
several query types and methods to
query that may cause c
onfusion.


Itemized list f
or
documentation
improvemen
ts.


Dev team to look at this
list and see wh
at can be
knocked off in 2.0.

General
Documentation
Issues

35

Naming Conventions should be in
place. Fix the inconsistencies in
nomenclature fo
r labels/table
names/variables.


Out of scope for
2.0


Beyond scope for now.
Needs thorough review of
the code and re
-
architecting.

General
Documentation
Issues

36

Make the current workflow
documentation

less confusing

To be addressed by the
community

in cookbook
article submissions

What
are the s
teps one
needs to go through with
caTissue in their own
environment
?

.

General
Documentation
Issues

37

Describe how navigation in/out of
caTissue should be done, based on
business logic, when connecting to
external components.

May end up being a
cookbook article.
Community could show how
they have done it e.g. UAMS

May be good for a monthly
teleconferenc
e topic:

API
or grid service access.


How application is going to
flow through the GUI (may
be covered somewhere
else in this list). Click
mouse


how does tha
t
flow through the whole
struts?


General
Documentation
Issues


38

Have clearer descriptions of how
IVY manages so we can understand
what ar
e the components and
modules.

In IVY documentation

May need to look at the
IVY documentation for
some
of this. May need to
show to someone with a
basic understanding of IVY:
“here are t
he xml files and
dependencies” H
ow IVY
manages in general should
be in IVY documentation

General
Documentation
Issues

Page
9

of
27


No.

Description

Assigned To

Scope

Reference

39

Add documentation that the
caTissuecore_Properties.xml file is
key for date formats.



General
Documentation
Issues

40

For the Domain Model we should
be showing the other class
diagrams, for example show the
classes that interact with STRUTS or
show the sequen
ce diagrams.



General
Documentation
Issues

41

Make sure that all links are updated
to reflect SVN and not CV
S on the
Knowledge Center wiki


This has been completed
by Dave Mulvihill.

General
Documentation
Issues

42

Move all caTissue docs to the KC
wiki, including the requirements
and design documents


Links are all there.
Completed.

General
Documentation
Issues

43

Show where caTIES is tied in the
architecture diagram.


2.0

Architecture
Diagram

Suggestions and
Comments

44

Show how the Bulk Operations uses
the API


2.0

Architecture
Diagram

Suggestions and
Comments

45

Find out if we can query the
deployed version of caTissue
caDSR/mapping values?


2.0 In caTissue
documentation admin or
tech guide

Architecture
Diagram

Suggestions and
Comments

46

Clarify that there is a caDSR API,
and a caTissue API and also a
caCore API in the arch diagram.


2.0

Architecture
Diagram

Suggestions and
Comments

47

Correct the labeling of the caCore
Service and the caGrid service.


2.0

Architecture
Diagram

Suggestions and
Comments

48

Show relationships between the jsp
page and applications so it is easier
to navigate.


Out of scope

Architecture
Diagram

Suggestions and
Comments

49

Show that the shipping module
interfaces with the caCORE API and
the caCore Client API


2.0

Architecture
Diagram

Suggestions and
Comments

50

Create a Co
ok
book wiki to share
the experiences and test the
different versions that have been
used by the community.

Editing should be open to
the community.

In progress



looking

for
community input.

Cookbook wiki



Knowledge Base
for Developers

Page
10

of
27


No.

Description

Assigned To

Scope

Reference

51

Communicate a process/workflow
for how the community submits
patches. Describe the tools and
information needed (e.g. point
eclipse method, crucible method) in
a wiki.

KC/Dev Team

2.0


We are showing the

capability to do this in 2.0.


To what extent is what we
are going
to do with Li
Wen repeatable?

Community Code
Contributions

52

Define who will maintain the
branches and how branches are
moved back into the source trunk.

Part of 51. Work with NCISVN
which includes how to work with
the NCISVN


In progress

Community Code
Contributions

53

Community should contribute test
reports for their contributed code.


Address how people get
access to the NCI test
management tool.

Community Code
Contributions

54

The community needs access to the
caTissue 2.0 source code.

Knowledge Center/
Developers

In progress.

Community Code
Contributions

55

The dynamics of the economic
model of open source development
should be explored

Part of the Open Source
Development Initiative.

In progress. Show wiki
where the discussion
taking place.

Community Code
Contributions

56

Consider using Crucible when
pulling in Li Wen’s code for

the site
customization of the logo (This will
need to be a Robert Shirley
discussion)




Summary
Quick
Fixes
for caTissue
2.0
Community
Code
Contributions

57

Schedule proposed follow
-
up
discussion topics/demonstrations
and hands on sessions. (see list in
notes)


Code Jamboree II at some
point. Working out on
-
going
program of teleconferences
and F2F jamboree sessions in
order to do this. How often
should we do this? Where?
What works best?

Future
Discussion
Topics/
Demonstration
s
/
Hands on Sessions

to
Schedule

58

Couple the Code Jamboree with
caTissue Annual Users Meeting


Consideration. Or should
we have it

separate as we
did this year?

How to Keep the
Code Jamboree
Going?

59

Have a Code Jamboree Follow
-
up in
a month to see if the code
modifications were made


In progress

How to Keep the
Code Jamboree
Going?

60

Organize monthly technical calls for
the coding group


October 3 @ 2 PM Eastern


Technical calls
-


How to Keep the
Code Jamboree
Going?

Code Jamboree Goals

1.

Deep dive into caTissue
current architecture


2.

Understand h
ow caTissue is used by
the
community

Page
11

of
27


3.

Discuss and document ways

NCI CBIIT can improve

the

caTissue
code
architecture to better
meet the needs of the community


Presentations

Presentations covering the current architecture, future p
lans for caTissue code, as well
community
overviews o
f how the caTissue application is
being used
may

be fou
nd
on the TBPT wiki page
:

https://wiki.nci.nih.gov/display/TBPT/caTissue+Suite+Code+Jamboree+
-
+Ju
ne+22+
-
+24,+2011

Discussion
S
ummaries

A.

Reorganization
of the
Code Structure



All java hybrid files
need to move

out of web
-
inf.

1
Currently these

files
are
located
under
software/caTissue/src/java/WEB
-
INF which is not optimal
.



There are
cyclic dependencies found with the Ja
r files in the common package. V
ersions of
t
he jar files are in conflict. T
here is an issue with the dependencies between the different
modules. This could be an example of a larger problem

as this happen
ed with caTissue 1.1
as well.
Repair the Jar file dependencies.

There is currently no good way to note/find JAR
version
s and find corresponding Jar so
urce code in the SVN repository.
2

This needs to be
fixed.
Dependencies between Jar files should be noted
.



When working with dynamic extensions some community members

encountered
mismatch
es

between entity/category,
and duplicate class names. This
needs to be
addressed.

Cleanup mismatches between entity/category and duplicate class names.

Duplicate class name
s are permitted across multiple entity groups.
3



Business logic
is
spread

across all tiers which makes the business logic

hard to understand.
Reconsider placement of business logic.
4



With regards to request variables, i
t is
difficult

to figure out the variables and
their
relation
to
associated

objects.
Consider providing a variable
to associated object diagram.
5



It was agreed that
the development team should provide a document or wiki page that
describes the SVN repository naming conv
ention.
6



It was noted that we do not have a current caTissue trunk in the SVN. (The one that is there
h
as been obsolete for two years


current development is being done on a branch)
.
Denis K.
is assigned to create a caTissue trunk.
7

B.

Graphical User Interf
ace



If we want to

pre
serv
e customized version
s

of the GUI
, we should m
ove
GUI customization
to

an external properties file
.
8



Allow for site specific changes (tweaks) to the user interface e.g. several of the OSHU tissue
banks key on the MRN which is poorly supported in caTissue.
(
Information
is not sorted by
Page
12

of
27


MRN and the m
atching algorithm for new patients was not only

useless b
ut counter
-
productive as it pulls up everyone.)



Areas

that are of general use

and where improvements could be made include:
9

o

Registration page

o

Customization Hooks

o

Create

a pop
-
up window that hooks to specimen
requirements
allowing

for one click
specimen su
bmission

(There should be hooks in the registration page that allow for
the pop
-
up)

o

Create a consolidation page that allows one to perform one click

registration of the
specimen.

o

Remov
e
many of the fields
currently showing on the GUI.
Having the ability
to
remove fields would help wit
h internationalization issues (e.g.
you wouldn’t have to
put a SSN in the SSN field

to register a specimen). Also removing the consent field
would be helpf
ul when registering a patient.

C.

Connecting with External Web App
licati
on
s



Auto
-
population

of Patient Demographics
should be a com
mon extension p
oint in caTissue
10



Clean up the SVN branches and
trunks:
make it easier to determine
where to add
customized areas
. (
also notes in code structure discussion


Section A
)



Revisit where
Business Rules
(design review and code review)

are located and maintained
and consider moving them if appropriate.
(also noted in code structure discussion



Section
A
)
.



Create a “higher level” API to make it easier to connect with
external apps
11



Consider how authentication will work when connections are made to external apps



Consider navigation so that the external app
lication

can enter and exit caTissue seamlessly

D.

Tools for Managing Open Source D
evelopment




Do not mandate, rather
l
eave it open as to what tools people want to use



List what
the “happy set” of development tools

are,
so that people have a guide to what has
worked well for the developers and others.
12

Informal List of Open Source Tools that can be used for caTissue
Development

Tools

PM

Code
Mngmt



MS

Code
Mngmt
-

MAC

IDE

Hot
Deploy

Issue
Mngmt

Req.

Mngmt

Coding
Guidelines

Test
Mngmt

Build &
Integration

JIRA

X





X

X**




Apache


X










MyLYN
(Eclipse Plug
-
In)


X










TortoiseSVN


X









Eclipse
Subclipse
Plugin


X









Page
13

of
27


Tools

PM

Code
Mngmt



MS

Code
Mngmt
-

MAC

IDE

Hot
Deploy

Issue
Mngmt

Req.

Mngmt

Coding
Guidelines

Test
Mngmt

Build &
Integration

SmartSUN


X









Cornerstone



X








svnX



X








Eclipse



X

X*







JREbel





X






Bugzilla






X





Wiki







X




Javadoc








X



IDE plugins








X



UML
Modeling
Tool








X



Crucible









X


BDA










X

Ivy










X

Hudson










X


*H
ave Eclipse setting available to help developers

**P
lug
-
ins and links to Confluence

E.

Exception Handling



Enterprise
services specifications include

exceptions and how they should

be taken care of.
There is an
exception standardization

that is followed
.



The question was asked of the community: If they

want to pull in applications th
at might not all
be caBIG app
s e.g. in house, vendor, etc., h
ow
is an exception handled
?


What do
system
integrators look for i
n terms of exception handling?



Determine if NCI should

h
elp clarify and standardize the exception handling process. Would this
be helpful to the community?
13

F.

General Code Suggestions



At startup, h
ave b
usiness logic checks against objects
14

Replace institution name/logo should be
part of install process
15



With regards to security:
web.xml
should have CAS authentication.
Action Item: Determine
who should be addressing the CAS authentication

issue
.

Should

it be

addressed by the caTissue
d
evelopment team?

16



STRUTS should

manage actions on themselves.
It

looks like the code is delegating STRUTS action
to
other

STRUT action
s
. This should be corrected.

T
here should not be delegation.
17

G.

Reconciling Local V
ersions and Interoperability



The principles behind dynamic extensions

are similar to what is needed to

facilitate reconci
ling
local versions of caTissue. Key concepts:

o

Use of caBIG semantic
infrastructure

o

Use
XM
L Metadata
I
nterchange

as
the
standard for m
etadata exchange

Page
14

of
27


o

Use of caCORE SDK and grid



Some changes can be made without impact on interoperability



We should p
reserve the notion of a “shrink wrapped app”

f
or those who don’t care to mess
with code
. “
Don’t break caTissue!




Joshua Phillips idea

for cr
eating an extension development environment to enable
reconciliation of
local versions

is shown in the Appendix
.

Joshua’s

solution needs a
specialized build.
Bart Brown volunteered to work on testing this solution.
18

H.

API
Layers and Services

1.

General
Comments



It was agreed that there is a n
eed
for a
higher level (less granular)

API
to
facilitate handling

transactions
19

(
for example:

Fred Loney
created a higher level API using

caRuby

at OSHU

for
about a dozen use cases
. See caRuby detail below
)
.
A high
er level API would decouple the
caTissue client form relational issues. It would provide coarser granularity with more
information vs. having a service that is getting coarser values.



The caTissue Java API provides for low le
vel communication and is hard
to use when
interfacing with external systems.



May need to provide façade templates

(are they generalizable?)

for these higher level APIs.



Having a service layer close to the API to deal with marshaling issue
s would be helpful to
Vanderbil
t. It has to

be

a service because of the Jar

files. One could take the Jar file
s into
different applications rather than having to take the Jar files into the client.



If the coarser grain services are of higher value, it reduces th
e transaction control problem.
If
there are

larger grain services, we say transactions don’t cro
ss calls,
which is good.




It was agreed that a high level interface which allows the full object graph to be saved
(persists the object model), does make sense and should be a service.
20

The exa
mple
provided for why this should be a service was that it would help with .net integration.
(
Recombinant Data has their application in .net and therefore there is no way to
integrate
with caTissue unless it is through a service.
)
The transaction boundar
y does not cross the
high level service calls.
caTissue

developers would have to provide coding that would
manage the hibernate sessions ( this would require mod
ification to the caTissue API)



Existence of lowe
r level API and s
ervices is assumed
. A l
ower
level API exposed as a service
is of less interest than the higher
-
level API

as a service
.



Punt to Plug
-
ins
(
storage allocation need at Vanderbilt used as an example



customized
algorithms for
where to allocate a specimen

would be best as a plug
-
in
.
)

2.

SOA (access
module through web service) or M
odularization?



Services should offer a common functionality that uses both business logic and data sources.



The issue with the level of granularity of the messages being exchanged needs to be
defined.



There shoul
d be consideration of the non
-
functional requirements surrounding the services


i.e. to allow for scalability.

Page
15

of
27




One could build the SOA on top of the business layer. For example, the web application for
caTissue uses the exposed business logic layer now,
and in there is an orchestration. If the
entire business layer logic was exposed one could use that information to define the higher
level coarse operations and then create a courser granularity of the messages being
exchanged.
Rakesh

(WashU)

said that w
e should see if the LSLR will share their business
logic, as Joe Burden from Vanderbilt put forth that it would be very helpful to have the
business logi
c as a service and all agreed.
21



It was noted that a complexity for SOA is that one may want to use a d
ifferent registration
service depending on the protocol.

3.

Higher Level API:
caRUBY
D
etails



Fred Loney’s
caRUBY A
P
I

is built on top of the Java

API

o

is not a web service itself

o

could have a web service wrapped around it via XML to a Strut service

o

Fred’s API p
ersist
s items in the object model
, then exchanges information

o

Difficulties
were
encountered
by Fred
because of the web App idiosyncrasies in the
caTissue API

o

Dynamic

Extension API is also another bear


10% direct J
D
BC calls were needed
which was not good



caRuby is based upon C.R.U.D. (Create, Read, Update, Delete)

parameters
.



For data such as SS#’s and MRN’
s,
decisions on whether to include them are made in the
caRuby Client.



caRuby fills in the defaults in caTissue. One could write something similar in

other
languages e.g. Groovy Grails.



caRuby decouples the client from dependencies rather than performs an orchestration of
services (Patient Registration is more of an orchestration of services).



caRuby is a service layer that persists the Object Model.

It fixes the issue with marshaling
the jar files. (since we would rather have the jar files centralized).



caRuby takes anything that is a caTissue domain object. It makes sense of the object graph


so one can submit a complete collection protocol grap
h


and then use one call to figure
out all

that.

One call in caRUBY translates into 20
-
30 caTissue calls



Permissible values (such as Male/Female
-

gender) are passed because caRUBY specifies the
logical detail. caRuby

is not a web service. There is some lightweight architecture to expose
it as a Restful service.



It is easier to use Ruby for technical items that deal with the domain than using JAVA. (one
could also use Python, Perl, Groovy)

I.

Plug
-
In A
rchitectur
e



Modularizing

caTissue with var
ying levels of capabilities would

help developers, allowing
them to create drop
-
in replacements

and enable caTissue to support the needs of both large
and small bio
-
banks
.

A priority for modularizing is Dynamic Extensions, al
lowing for what
can be simplified

in the user interface.

Page
16

of
27




Further discuss if the community believes caTissue s
hould have more

plug
-
ins similar to
what
has been

done for label

generation/printer integration.

If so, h
ow should it be
architected?

How do we

make sure there is access to the necessary data from the plug in?
22



Candidate plugin points / hooks

include

o

Auto
-
population of Patient Demographics

o

Specimen location allocator (
Auto location

algorithm for
groups of specimens that
have certain attributes )

o

Web interface plugins



Quick Fix examples for plugins

o

Registration page

o

Storage container name generator

J.

Build Deploy Automation

Discussion



There was general agreement that t
he revised build is better.



The instructions should be more specific,
for example:

specifically direct people to the JDK
6.0 download instructions
,

if not the link (
detail

that 1.6 is found via the JDK 6.0)
.
23




We need consistency in build version names/tag names. This
impacts the BDA, bug tracking,
and the SVN.
24



Report what the defau
lts
are, for example:

<database.user Description: The username used
to connect to the database. Default Value: None
-
catissue>
25



We need to consider how best to modify the upgrade scripts, for example:
If you have the
object model in java/hibernate model/da
tabase scripts, all have to be in synch to allow
changes to be effective, which then makes it difficult to make changes. This was an issue
with caIntegrator, where one had to hunt down the various pieces.
A lot of tools in caBIG
(hibernate, sprint), expl
icitly support "don't repeat yourself" but these capabilities are not
taken in by the caBIG

infrastructure, for example with

hibernate

configurations, one
shouldn’t
have to generate hibernate configs

because it comes from the java annotation
classes; similarly upgrade scripts/database initialization scripts
should be

auto
-
generated.

The SDK generates the

h
ibernate mapping file based on
a
given data model. It does not add
annotations to generated doma
in objects. It pro
duces hbm.xml files instead of h
ibernate
annotations inline in the java
source. Seems like a good approach and a topic we need to
look at further.
26



caTissue is sensitive to the tech
nical

stack
, and this tech stack should be specified. W
e
need
better information on the dependencies of what caTissue needs

in the tech stack
. (If
there
are specific dependencies, they should be communicated
.)
27

caTissue needs to be flexible to
the different stacks (
weblogic or oracle 8, IBM AS400) if we want t
o have adoption and open
source development. We should

priori
tize where there is flexibility so
, for example,

we
don’t set

up a new database server
(because of a specific tech stack need)
for just one
application.

It was suggested to provide a ranking/pr
ioritization of the tech stack
components

to identify the flexibility in versions. Perhaps create a wiki to share
community testing of different tech stack components. (see cookbook discussion)

Page
17

of
27




With JBoss, there are headaches with the Grid enabled caTiss
ue because
in order to pass
security on the grid using caGrid 1.4,
we have to
use

different

versions of

JBoss
when
deploying caTissue
. The application should
rather
have one WAR file with generic
connections.
We should understand where in the code it is so dependent and not repeat
this in other applications. It
was noted that this dependency
may be a deployment issue
rather than a code issue: perhaps one needs

only

to shift the JAR file locations.
28



caCORE SDK

is generating the hibernate tools whereas with o
ther places/projects it's more
J
ava based. In caTissue it's all done in the UML which makes caTissue challenging.


For
example, there is a calculated field that ought to be built into an object and can be
derived
from existing data. If you only derive from the UML model, you lose the ability to make data
structures more intelligent. Building capability into caTissue is a challenge because of this.



Sichen Liu: with our SDK 4.2.3 release, domain objects c
an be added with custom
operations, like calculations etc. This is not necessarily using SOA but rather it is split into
12
-
15 services.
Perhaps caTissue can use this approach.
Topic for later discussion: how SOA
would help.



Have more descriptive intern
al exception errors, for example one could put a stack trace on
the server log.
29

For business logic problems
such as
with identification, put the same UI
description in the error message.



Need to put in an IVY repositor
y for the Oracle drivers, etc. i
n th
e NCI SVN so it is easier to
update the BDA.
30



See A
ppendix for the MAC BDA process that Denise Warzel followed during the Jamboree.

This should be included in the BDA documentation.
31

K.

General Documentation
Issues



The Package structure is not clear, there
are duplicates. We need module level/ package
level documentation / diagram
s. We also n
eed documentation of code structures
.
32



We need a description of the r
ole caCore SDK
has in caTissue Suite.
33



There is l
ack of documentation on how to add new attribute
s and make them user
queryable (the SQL queries/tables).
We need m
ore detailed documentation on
the
advanced query module and the
dynamic extensions module
. T
here are several
query
types
and methods to query that may cause confusion
.
34



More descriptions
with exception notice
s

would help
discover why exceptions occur
. Right
now the code is not
checked rather the notice

just says there is an exception
, which is not
meaningful.

Perhaps the business logic could be checked.



Perhaps the l
ack of source code
level documentation
could be rectified by having
controls/review gates to verify that items were documented properly.



Namin
g Conventions should be in place. Right now there are inconsistencies in
nomenclature for Labels/table names/variables.
35

Move this
into code best practices.



The c
urrent
development
workflow documentation is too confusing
36



There is a need for descriptions of how navigation in/out of caTissue should be done, based
on business logic, when connecting to
external components
.
37

Page
18

of
27




We need to

have clearer descriptions of how IVY manages so we can understand what are
the components and modules. Perhaps simplification can be done through services rather
than modularization
38




There is a need to add documentation that the caTissue
c
ore_Properties.
xml file is key for
date formats. This file is used by the matching algorithm and can be tweaked to better fit
needs.
39



For the Domain Model we should be showing the other class diagrams, for example show
the classes that interact with S
TRUTS

or show the

sequence diagrams (
it was noted by the
developers that
the actual design documents do have sequence diagrams)
40



On the Knowledge Center wiki
-

make sure all the links are updated to reflect SVN and not
CVS.
41




Move all docs to the w
iki, including the
requirements and design.
42

L.

Architecture Diagram

Suggestions and Comments




Pl
ease refer to the architecture d
iagram in this document’s Appendix



caTIES is intimately ti
ed into caTissue. Show where caTIES

is tied in the
architecture
diagram.
43

(Note: In theor
y one could change out the Text Extraction using the HL7
messages. Follow up on this.)



If test results are available, then we could use other databases such as PostgSQL



Could plug in another provider for the Person, Organization, etc. service rather than u
se
what is in CTRP and C3PR.



Bulk Operations uses the API and that is not shown
44



The presentation layer uses
the older struts framework 1.1.
Hibernate is used to maintain
objects, the caCore Ser
vice is part of caCore SDK and
the Grid Service is built separ
ately.



In the architecture diagram the EVS
-
caDSR Interface is an old component that has existed
since Core 1.0.
In the original plan, the EVS
-
caDSR interface was

supposed to
allow for
update
s to

permissible values from the caDSR
. Current versions update through the
database because it took
too long

for the caDSR to upda
te the values. In theory when
c
ommon data elements are updated with the permissible values it should work. This link is
“begging to be used for dynamic extensi
ons”.

o

It would be good to have the EVS
-
caDSR interface to have “Google
-
like” capabilities
so you would be able to know that you don't need to create a new concept. It
would only need “read” capability from the caDSR.

o

Business logic on the web interface

is not safe because specimen units may be
changed. For example: count vs. gram or

millimeter.
Rather, the value domain for
common data elements which will have associated specified units,
should be
extracted from the caDSR.

o

One should keep this in mi
nd when moving data
from caTissue to
a

data warehouse
.
The metadata from the caDSR should be used to make sure the proper units are
being
used.

Page
19

of
27


o

It was noted that currently, one can track permissible values but cannot currently
track or tie in the unit r
elated to the permissible value.

o

Can we query the deployed version of caTissue caDSR/mapping values? (Action
Item)
45



Does the API use the same business logic as the UI? This diagram should be able to answer
that question

and it currently doesn’t
. There i
s a caDSR API, and a caTissue API and there is
also a caCore API. This needs to be clarified

on this diagram
.
46



It would be good to understand where data access objects and domain objects fit into the
caTissue architecture and define their role.




The caCo
re Service is mislabeled. It should be renamed “caCore Client”. The same for grid
service. The grid service is server side
.
47



There should be a box around the app delegator box named caCore Service
.

Struts have
nothing to do with the app delegator. It is only for the caCORE API.

Is there business logic in
the struts components?



Showing relationships between the jsp page and applic
ations would make it easier to
navigate (via a STRUT diagram of the ou
tput, etc). Rakesh

(WashU)

knows of a diagram
generator that may be useful. It takes tiles and makes a diagram. The diagram really helped
Rakesh be able to dig down into the flow through the struts.
48




The Shipping module should show an interface with t
he caCORE API and the caCore Client
API
49

M.

Cookbook wiki



Knowledge Base for Developers



Certification and testing is tied to specific deployment scenarios and systems. NCI
certification is tied to NCI money and time that is provided to the developers. We should
have a wiki to share the experiences and test the different versions that have b
een used.
This is not NCI certification. IT teams should know that they deploy different versions at
their own risk. Example
: India

(CDAC)

wants
to use

IBM AS400
.
50




Cookbook Topics

o

caTissue d
ev
elopment

team should share

how they get
their internal

devel
opers up
to speed

when new developers come onto the project
, including FAQs on how
broad components are implemented.

o

Share API ‘TRAPS’

o

Share h
ow sites register patients (implications to caTissue UI)

o

Share interpretations of

common error messages

o

Provide a document of the caTissue Business logic.

o

Show sequence diagrams for “happy paths” such as for exception handling.

o

Share settings for different management tools

Page
20

of
27


N.

Community Code Contributions



The process/workflow
for how the community submits pat
ches to caTissue code needs to
be communicated
. Describe the tools and information needed (e.g. point eclipse method,
crucible method) in a wiki.
51



Define who will
maintain the branches and how branches

are moved

back into t
he source
trunk.
52



Community sho
uld

contribute test rep
orts for their contributed code.
53



The community needs access to the caTissue 2.0 source code.
54



The dynamics of the

economic model of open source development
should be explored:
55

o

H
ow individual sites may benefit from what has been de
veloped at other
institutions.

o

Code Bounties: Institutions
could
put out financial incentives for others to develop
the code that they need.

o

Contributions should be
accredited;

credibility of the contributors should be
associated with who gets to comm
it code.

O.

Hands
-
on Session to Bring a Code M
odifi
cation into caTissue Main
B
ranch



Purpose:
Fix the logo code

so that
a

site
can

customize the
logo
link without

having
to
work

with the caTissue source code or unpack and repack a jar file
. Li Wen of
Vanderbilt coded
this fix. (Action Item: Follow
-
up with Li Wen)



Feature list

to include:

o

Site will only need to

supply t
he image


or a link to it

and
t
he url where clicking
on the logo should take you
.

o

One should also have the
a
bility

to not link elsewhere when you click
on
the log

o

One should have the a
bility to hot deploy

Miscellaneous



To be able to update the shipping status of the shipping module through the user interface and
make it available through the API one could use the caCo
re client to push shipment status
through the API.



The Bulk Operations module internally calls the caCore internal API to persist the data in bulk.



Public
-
Private migration can be managed through role based access on a single caTissue
instance. Some s
ites, however, want more protection and require a completely separa
te
instance for public access.



Cascaded Style sheets are available if people want to get the style and mimic what caTissue
font/color/etc use when building customizations

Page
21

of
27


Summary
Quick Fixes
for caTissue 2.0

(Original List from
Jamboree Notes)



Clean Repositories (Fix SVN


maps to Ian)



Site/Logo mod in Deployment properties file


we will do this with the code that Li Wen wrote.



Trunk (maps to Ian) we must have one and be clear on

how it is used.



WEB
-
inf base of the code base should not be here.



Documentation Improvements
: n
eed to identify specifics that can be done for 2.0



Tag releases in Bugzilla with current BDA build


SVN and Bugzilla should have a consistent
terminology for
version of code.



Dependency management needs to be sorted out



BDA documentation improvements



State basic principles re: tools


If we say we are using a tool such as Eclipse, is it the only tool
that can be used? Show what the tool is being used for and
why that one is chosen. Don’t
require that particular tool.



Crucible? Use when pulling in Li Wen’s code (This will need to be a Robert Shirley discussion)
56



Move requirements and design documents to a fully functional NCI wiki (review requirements
management


need traceability e.g. JIRA add on?

Note: Jinlei uses wiki for collaboration


once formalized it goes to share point and link
s

to JIRA



BDA wiki improvements


could have Eclipse settings described here

Future
Discussion Topics/
Demonstration
s
/ Hands on Sessions

to Schedule



CDE Browser



CDAC: session variables



Vanderbilt use of

Talent (part of JasperSoft) ETL tool



JIRA (as PM tool)



Crucible (test management

tool
)



JRebel n
ote: The JRebel

Plug
-
in license can be granted free to those that apply saying they are
building code in caTissue. (Action Item

communicate this to the community)



Demonstrate how caTissue uses IVY



Internationalization

Hand’s On
:
a
llow for the removal of the Zip Codes a
nd SSN’s and replace
with other identifiers.
57

How to Keep the Code Jamboree Going?



Couple the Code Jamboree with caTissue Annual Users Meeting
58



Have a Code Jamboree Follow
-
up in a month to see if the code mod
ification
s were made
59

Page
22

of
27




Logistics to keep and
improve:

o

Flexibility i.e. be agile with the agenda

o

Audio/Video Feed needs improvement

o

Walk
ing

through code and the architecture in detail was helpful, as well as seeing
other
s’

code modifications

o

Organize monthly technical calls for the coding group
60

o

Crea
te a wiki “codebook’


have the Code Jamboree I

attendees

provide feedback and
help set it up
. Prioritize the Knowledge Center contributions to the cookbook.

o

Keep the hands on activities

o

Keep the coding breakouts
.
Making
code
fixes during the Jamboree is

useful
.

o

3 days was a good enough duration, if
made

longer, have pre
-
designated down times to
allow attendees to catch up with other responsibilities

Appendix

1.

Ranking of Code Jamboree Sessions


Page
23

of
27


2.

caTissue Architecture Diagram


Page
24

of
27


3.

Idea for Creating an
Extension Dev
elopment Environment to Enable
R
econciliation of L
ocal
V
ersions (
Joshua Phillips)

Idea


create a patch using Eclipse or
any IDE you choose then submit to crucible to development team as a patch file.


4.

Special BDA Instructions For MAC:

Download MAMP 1.9.4 from MAMP.

http://www.mamp.info/downloads/releases/MAMP_MAMP_PRO_1.9.4.dmg.zip

Install MAMP in the Applications fold
er. Double click on the MAMP folder.

Click on “Databases”

Click on catissue

Click on Privileges


“Create New User”



User Name = catissue



Click host = local



Password = catissue



Click on

“Create database with same name and grant all privileges”



Click on “
Check All”



Click “GO”

EXT ENV

Build.x

SRC

SVN

Page
25

of
27


After installing MAMP, check the phpMyAdmin tab for the version number of mySql, this goes into the
Install Properties file:

After installing MAMP, check the ______________ for the database port number, this goes into the
project.Pro
perties file: mysql.minimum.version=xxxxxx

If you have recently downloaded Ant, the ANT_HOME will probably be in your
Users/<username>/Downloads folder:

Users/<username>/Downloads/apache
-
ant
-
1.7.0


JAVA_HOME will probably be:

System/Library/Frameworks/
JavaVM.framework/Home


Install.Properties File:

-

The database.name, database.user, database.password have a default value of “catissue”, this can be
left as is

-

The csm.database.name, csm.databaes.user, csm.database.password have a default value of
“cat
issue”, this can be left as is


Run Ant Target:

In a terminal window, change directory to where the caTissue_Home/software/build


GENERAL:

Under “Create Database”

MySQL the following does not work if the <user_name> has not been created:

drop

database IF EXISTS <database_name>;

create database <database_name>;

grant all on <databas
e_name>.* to '<user_name>'@'%';

Attendance

Organization

Representative

3rd Millenium

Brian Davis

Booz Allen Hamilton

Anna Fernandez

Booz Allen Hamilton

Beth
DiGiulian

NCI CBIIT

Ian Fore

NCI CBIIT

Denise Warzel

Oregon Health and Sciences University

Fred Loney

Partners Health

Andrey Belozerov

Recombinant Data

Jinlei Liu

SAIC Frederick

Brent Lander

Semantic Bits

Joshua Phillips

Page
26

of
27


Organization

Representative

Semantic Bits

Denis Krylov

Semantic Bits

Kruttik Aggarwal

University of Arkansas for Medical Sciences

Nitin Karaskar

University of Colorado Cancer Center

Michael Ames

University of Colorado Cancer Center

Jessica Bondy

University of Iowa

Bart Brown

University of Texas Health
Sciences San Antonio

John J Hough

Vanderbilt University

Li Wen

Vanderbilt University

Joe Burden

Washington University St. Louis

Rakesh Nagarajan

Washington University St. Louis

Bijoy George

Note: Remote

Note: Remote

NCI, CBIIT

Dave Hau

Yale
University

Jim McCusker

C
-
DAC, India

Dipak Chaudhari

C
-
DAC, India

Srini Akkala

C
-
DAC, India

Ravi Batchu

Pune, India

Persistent Team

NCI, CBIIT

Sichen Liu

NCI, CBIIT

Prasad Konka


Do Not Erase Below this Line (End Note Detail for Action Items)




1


2


3


4


5


6


7


8


9


10


11


12


13


14


15


16


17


18


19


20


21


22


23


24


25


26


27


Page
27

of
27








28


29


30


31


32


33


34


35


36


37


38


39


40


41


42


43


44


45


46


47


48


49


50


51


52


53


54


55


56


57


58


59


60



Do not erase above t
his
line. ( Action Item Detail)