4. Behaviour vs. Content
WWW
Applications
Simple
Complex
Standards-based
Proprietary
Build your own
Fix set of functions
Coarse-grained
Fine-grained
Integration: O(n)
Integration: O(n²)
10. Google
Server
Reader
Sage
Atom
Dojo
get(uri) : doc
Documents
post(uri, doc)
put(uri, doc)
Flex
delete(uri)
11. Workflow Google
Server
Engine Reader
Sage
Atom
Dojo
Documents
Console
Flex
12. Content Orientation …
Enforces simplicity
Encourages standardization (think SOA)
Allows applications to involve independently
from each other
Improves scalability and reuse of
infrastructure
13. Content Orientation …
May be inappropriate for complex processes
Requires content processing facilities in
each involved application (good availability
for content formats based on open
standards)
Can increase network traffic
15. Why a Repository Standard?
Portability → no vendor lock-in
Shared vocabulary for developers
Reuse of experience, code, tools, …:
True content repository infrastructure
Increased independence, reduced risk
16. Customers
Now: „Vendor A had a nice GUI, but the
back-end doesn‘t scale. Vendor B had a great
back-end, but the front-end is unusable.“
With JCR: „We can choose the front-end
vendor independently from the back-end
vendor. And when we need a bigger back-
end, we can exchange it without having to
train the users again.“
17. Vendors
Now: „It‘s such a PITA to fix all those
concurrency bugs in the back-end. I‘d rather
work on this nifty AJAX stuff.“
With JCR: „Since we can just include
whatever back-end the customer wants, we
can concentrate on providing a magnificent
user experience by continuously improving
our front-end.“
18. What is a Content Repository?
Application data „super store“
Generic API for content storage:
CRUD + locking, versioning, transactions,
observation
Access control
Powerful search
19. API, not Product
Well-defined, closed set of features
Documentation about expected behaviour
Abstraction from implementation:
Choose whatever storage facility is
appropriate - file system, RDBMS, …
or even mix them in your repository
23. Choosing a Back-End
How easily can I implement a connector?
Versioning: FS easy, RDMBS difficult
Transactions: FS difficult, RDMBS easy
Performance
Manageability
24. Repository Deployment
Models (Jackrabbit)
A) Inside the application
B) As application inside the container
Referenced via JNDI, accessed via JCR
C) As standalone server
Communication via SOAP, DAV, RMI, …
Accessed via JCR stub
25. Content Model Features
Structured: Mandatory/optional elements
Unstructured: Store what you like
Content types (textual, binary, …)
Relationships with integrity control
29. Node Types
Hierarchical (inheritance)
Child node definitions:
Default+required node types for children
same name siblings allowed (true|false)
Property definitions:
Required type, multiple (true|false),
value constraints, default values
30. Level 1
Initiate a session with a workspace (login)
Retrieve and traverse nodes and properties
Read the values of properties
Export to XML
XPath queries
31. Level 2
Add and remove nodes and properties
Write the value of properties
Assign node types to nodes
Import from XML
34. Jackrabbit
Persistence managers (back-ends):
In-memory: fast, but not persistent
Serialized objects: good performance
XML: human-readable, good for testing
RDBMS: good performance, scalable
Hibernate pers. mgr. from JBoss project:
Clustering, transactions, better caching
Lucene for indexing
