28. • Provides…
– CRUD methods (Create, Retrieve, Update, Delete)
• Allows…
– Save time (↘ copy-paste-adjust) on technical
layers
– Improve efficiency on the development of
business layers
> Focus on business
Java Middle Stack
DAO & Business Services
29. @Entity
public class StandaloneEntity {
private Long id;
private String name;
// ... getters and setters
}
How to … obtain a complete DAO layer for my POJO?
Java Middle Stack
StandaloneEntity entity = new StandaloneEntity ();
entity.
Example
Serializable
StandaloneEntity
« implements »
30. public interface StandaloneEntityDao extends GenericDao<StandaloneEntity, Long> {
// ... specific methods addition
List<StandaloneEntity> findByName(String name);
}
How to … obtain a complete DAO layer for my POJO?
Java Middle Stack
@Named("standaloneEntityDao")
public class StandaloneEntityDaoImpl extends GenericJpaDao<StandaloneEntity, Long>
implements StandaloneEntityDao {
// ... specific methods implementations
@SuppressWarnings("unchecked")
public List<StandaloneEntity> findByName(String name) {
String queryString = this.getQueryString("from %s where name = :name",
getDomainClass());
Query query = this.getEntityManager().createQuery(queryString);
query.setParameter("name", name);
return query.getResultList();
}
}
Example
31. How to … obtain a complete DAO layer for my POJO?
Java Middle Stack
@Inject
@Named("standaloneEntityDao")
StandaloneEntityDao standaloneEntityDao;
standaloneEntityDao.
> Allow Progressive Complexity
Example
32. Embeded database
Multi-modules JPA entities scanning
JSR 303 Bean validation
Generic DAO & Services
Generic tests
JEE6 Dependency injection
3
Generic DAO
Hades 2
Validator1.2
JPA2 Persistence engine
3.5
Java Middle Stack
DAO & Business Services
38. • Provides
– Generic methods to test your DAO, Business
services and webservices
– Better protection against side effects caused by
code changes
• Allows
– Focus on testing your project functionnalities
Java Middle StackJava Webservice Stack
Generic Tests
39. How to… entirely test my DAO layer ?
public class SampleResourceDaoTest extends
AbstractResourceDaoTest<SampleResource, SampleResourceDao> {
@Inject
@Named("sampleResourceDao")
@Override
public void setResourceDao(SampleResourceDao resourceDao) {
// Allow to override DI by annotation
super.setResourceDao(resourceDao);
}
// custom tests
}
Java Middle Stack
DAO example
40. Java Middle StackJava Webservice Stack
Webservice example
public class TestWebSampleResourceController extends
AbstractResourceControllerTest<WebSampleResource,
GenericResourceController<WebSampleResource,
GenericResourceService<WebSampleResource>>> {
@Inject
@Named("webSampleResourceController")
public void setController(GenericResourceController sampleController) {
super.setController(sampleController);
}
// custom tests
}
How to… entirely test my webservice layer ?
41. 1. Done for you
– CRUD are already tested !
– Ready to « plug » your domain
– Technical tooling
2. Extensible
– Abstract classes to plug your own tests
– Extended CRUD & complex business methods
> Simple now, Advanced tomorow
> Focus on business added value
Java Middle StackJava Webservice Stack
Generic Tests
46. • Provides…
– Script loader
– Route manager
– Templating language
• Allows…
– Use the latest web technologies consistently
– Create lightweight RIA WebApps based on jQuery
– Reduce traffic and server load
Javascript stack for RIA Webapps
Javascript Stack
47. Application server
SOAP
Web Services
DAO
Business Services
MVC framework
based Web GUI
Web browser
Reloading page for each action
Dynamic pages
SOAP proxy
to JSON
Webservice
SOAP
session
HTTP server
Javascript
CSS
Images
Javascript Stack Java Middle StackJava Webservice Stack
Well known webapp software design
48. Application server
Web browser
Changing the state of one widget on each action
HTTP credentials
JSON/XML Data
HTTP server
Javascript
CSS
Images
DAO
Business Services
REST Web Services
Other
REST
Webservices
HTML 5 based
session
Script loader
MVC Framework
HTML
Static pages
Javascript Stack Java Middle StackJava Webservice Stack
RESThub fullstack based software design
49. Route 1
Route 2
Route 3
Route 4
Controller A
Controller B
Controller C
View A
View B
View C
JavaScript HTML
Business services
DB
Web services
DAO
ClientsideServerside
URL Sammy
Controller D View D
Events
Client side routing
Javascript Stack
52. • Server is stateless
– No session needed for anonymous webservices
– Session or similar mechanism needed for AuthN
– Hability to add/remove servers with no impact
• Client is statefull
– Recent browser provides « session storage »
– Manage the reloading of the page (F5)
Consequences on the architecture
53. • Clear separation between static and dynamic
– Static: interface HTML5, JS, CSS
– Dynamic: stateless secure webservices
• Out of the box caching compliancy
– Even when pages are user-customized
• More operations are computed on client side
• Better scalability thanks to stateless servers
RESThub on hosting side
63. RESThub, now !
• Work started about 1 year ago
• We are now close of the 1.0 final release
– Before the end of November, 2010
• Build iteratively on concrete business cases
• Used in multiple projects in production
– Different versions
• Don’t hesitate to join on http://resthub.org
64. OAuth2 based security
Identity manager
CouchDB persistence
Accessibility
Serverside template rendering
Xlink support
Semantic web
OSGI support
Client side validation based
on JSR 303 annotations
What’s next ?
Why, not how (Martin Fowler, USI 2010)
We will not start by explaining how RESThub is made but by resuming the fundamental reasons for which it is born
To do that, let’s start by a quick context analysis …
Few time ago, we were still alone and we used to always re-do things ourselves with our own hands. We manually managed transactions, database connections and mappings and so on.
Then we understood that tools can help and started to developp internal tools
Progressively, we learned to communicate, exchange and share experiences, tools and solution with our communities, a set of people working on the same problematics, in the same and convergent way.
This is incontesable that it is a positive, constructive and efficiency-oriented evolution but this leaded to a paradox …
The apparition of an always growing set of specialized and complementary technologies helped us to focus on our real needs. We don’t manage transactions ourselves because there is no added value for us or our clients, we delegate it to dedicated components that are often widely used in our technical world.
Moreover, the global quality of these components is really better than that we were able to produce by ouselves : cannot be a specialist in every domain !
This is called separation of concerns and allowed us to focus on business and added value and that is, I think, a good thing for everyone.
But …
The born of all these specialized components leads also to a constantly growing complexity
Less programing
More technologies
Initialization
Configuration
setup
Leraning curve
Gap to undestand all aggregates technologies
Difficulties to sort, identify these technologies and integrate everything in a global architecture
Starting is difficult
These difficulties could, paradoxaly, leed to non productive situation whereas these technology are designed to facilitate technical preoccupations – and they really do !
Even when started (helped by an architect), we often have difficulties to advance in a compact fog made of a multiple of complementary components…
Sometimes (rare) could leed to a real project fail !!
Often because Knowledge management failed, etc.
How to resolve this problem ? Ie. using multiple technical solutions allowing us to focus on business that means using most efficient solutions and, on the same time, being able to reuse parts and technologies of a given solution on a totally different context, keeping a good efficiency and quality ?
We came at the conclusion that an upper toolkit is needed
Provide complexity abstraction
Simplify problematics
Help to start
And…
match all these needs
Extensibility
Plugability
Reusability
Independance from the context (projects characteristics)
Simplicity
Pragmatism
And resolve a complex equation between simplicity and complexity
Start simple to accelerate initial efficiency and facilitate knowledge acquisition and technology adoption
While …
Preserving technology performance and added-value
Keep the capacity reuse in multiple contexts
Keep the capacity to increase complexity later
Concept of progressive complexity
Start simple on basis able to handle later more complexity
For these reasons, we didn’t whant to reinvent the wheel by using
Widely used technologies
Standards
Cannot choose each time a different toolkit for each different need but not exactly the same tool … common basis, specific approch for specific needs.
We wanted to reuse parts of our toolkit on multiple contexts
No new « dedicated » framework or language but …
a « global toolkit » to rule them all
- simplify the integration and the learning of each dedicated technology
- in order to simplify access to technology, startup
But with progressive complexity possible
Selection of coherent technologies
Generic DAO & Business Services
Generic REST Web Services
JavaScript libraries for RIA WebApps
A security layer for its services
Modular: use what you need, no more!
Tool for quality: follow the best practices
Reliability helper: generic tests on each layer
Selection of coherent technologies
Generic DAO & Business Services
Generic REST Web Services
JavaScript libraries for RIA WebApps
A security layer for its services
Modular: use what you need, no more!
Tool for quality: follow the best practices
Reliability helper: generic tests on each layer
Selection of coherent technologies
Generic DAO & Business Services
Generic REST Web Services
JavaScript libraries for RIA WebApps
A security layer for its services
Modular: use what you need, no more!
Tool for quality: follow the best practices
Reliability helper: generic tests on each layer