[
https://jira.jboss.org/jira/browse/DNA-256?page=com.atlassian.jira.plugin...
]
Sergiy Litsenko commented on DNA-256:
-------------------------------------
From Sergiy:
My thoughts that we would want to anticipate wide
range of customer's different deployment scenarios with minimum efforts, right?
This is especially true with SOA-Platform and JBoss Enterprise Data Services Platform
which includes JBoss ESB, JBoss jBPM, JBoss Rules and JBoss Enterprise Application
Platform (JEE App server). So in addition to Embedded and MicroRepository we would
certainly need "Enterprise" Repository that may be deployed as EAR into any JEE
compatible server, and may be accessble through RMI in addition to HTTP, HTTP+REST, etc.
IMO, we would still need to develop few "reference deployment packages" and I
can participate in these efforts. Even more, we can integrate Jackrabbit transparently
into web/app server - thanks to JackRabbit has JCA connector and JNDI, so DNA clients
(REST API, web UI) will think they talking to JBoss DNA JCR. Jackrabbit also allows
loading previously exported XML content into JCR repository - so we can test DNA
predefined graph structure. That will also help with integrated and functional testing of
our stack without waiting for DNA JCR implementation. For instance, REST API and web
applications will require at least basic functional testing - I was thinking about using
SOAP UI to test WS services and REST API.
WAR packaging scenarios aree OK, but if you have multiple session facades (your business
logic) plus multiple web apps (e.g. REST API, web admin UI based on Flex, web app based on
RichFaces, web app based on XXX, etc) + shared code - the right approach would be to use
EAR that was designed for that purpose and stores multiple WAR files, shared libs, session
facade EJB3 artifacts all together. Actually this resembles MVC paradigm, right?
Plus, remember that EBJ3 artifacts are just POJO with annotations - so that makes them
simple and thin while benefiting from standard services like resource pooling, thread
management, security and transaction propagations, JMX, etc. Same Stateless Session Bean
could be accessed locally, remotely through RMI, and as WebService with absolutely no
extra effors needed.
On the other hand, JEE App servers getting smaller, becoming embedded like JBoss Embedded
and small like Glassfish embedded. It's no longer monolithic 100Mb thing - we can
prepare deployment with just few megs. Not to mention that nextJEE6 is talking about
different profiles to support more lightweight scenarios.
From Randall:
I completely agree that DNA will can anticipate
many different scenarios. But I also am concerned about over-engineering and adding
complexity or intent where we don't need it yet.
From Sergiy:
What's the DNA overall deployment strategy?
I've mentioned it here
https://www.jboss.org/community/docs/DOC-12952
From Randall:
There will be several. One is an embedded case,
where an application wants to use a local repository and will access it through the JCR
API. This repository may be federated from multiple sources, including the file system,
and may use sequencers, allowing the application to have a repository with a mixture of
the content it wants.
A variation of this is the MicroRepository. This is also embedded, but uses just a few of
the DNA artifacts plus very minimal dependencies. The idea is that an application could
use the repository as the bootstrapping mechanism. Think of an OSGi repository, or Maven
repository, or JBoss Microcontainer.
Another case will be a shared resource, much like a database. I foresee this being most
easily deployed as a .war file, or actually a choice of .war files that range from a
simple RESTful service on top of multiple repositories, to including other web services
and web applications). This is probably closest to your architectural diagram, but
I'm not sure I know exactly what kind of technologies will be used - I presume
we'll try to pick the best tools for the job, once we know more about the
requirements. Also, I don't want to go too far with this, as there are plans within
JBoss to use DNA inside the SOA-Platform and JBoss Enterprise Data Services Platform. It
may be that the open-source DNA remains mostly a set of artifacts and maybe some tools,
leaving the more "integrated stacks" of technologies for products (from JBoss
and others).
Packaging and deployment
------------------------
Key: DNA-256
URL:
https://jira.jboss.org/jira/browse/DNA-256
Project: DNA
Issue Type: Feature Request
Components: Server, Web Application
Environment: Java EE 5 certified environment
Java SE 5 certified environment
Reporter: Sergiy Litsenko
Fix For: Future Releases
Define flexible packaging and deployment scenarios that satisfy both Embedded/Standalone
and Enterprise deployments.
Maven plugins can package the project as different deployment artifacts:
http://maven.apache.org/plugins/maven-ear-plugin/ JEE Enterprise Archive (EAR) file
format
http://maven.apache.org/plugins/maven-rar-plugin/ JEE Enterprise JCA Resource
adaptor Archive (RAR) file format
http://maven.apache.org/plugins/maven-ejb-plugin/ JEE Enterprise Javabean (EJB) file
format
http://maven.apache.org/plugins/maven-war-plugin/ JEE Enterprise Web Archive (WAR)
file format
http://maven.apache.org/plugins/maven-assembly-plugin/ Custom packaging
http://maven.apache.org/plugins/maven-dependency-plugin/ Custom packaging
Examples of deployment scenarios/packaging:
http://jackrabbit.apache.org/deployment-models.html
Apache Jackrabbit deployment models - including embedded, Shared J2EE Resource, and
Repository Server accessble through RMI over JRMP or IIOP or WebDAV.
http://docs.jboss.org/seam/2.1.0.GA/reference/en-US/html/configuration.html
JBoss Seam framework packaging scenarios:
29.3. Configuring Seam in Java EE 5
29.5. Configuring Seam in Java SE, without JBoss Embedded
29.6. Configuring Seam in Java SE, with JBoss Embedded
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira