[dna-issues] [JBoss JIRA] Commented: (DNA-256) Packaging and deployment

[ https://jira.jboss.org/jira/browse/DNA-256?page=com.atlassian.jira.plugin... ] Sergiy Litsenko commented on DNA-256: ------------------------------------- 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. 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. What's the DNA overall deployment strategy? I've mentioned it here https://www.jboss.org/community/docs/DOC-12952 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). -- 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