Details

    • Type: Feature Request Feature Request
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: Server, Web Application
    • Labels:
      None
    • Environment:
      Java EE 5 certified environment
      Java SE 5 certified environment
    • Estimated Difficulty:
      Medium
    • Similar Issues:
      Show 10 results 

      Description

      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

        Issue Links

          Activity

          Hide
          Sergiy Litsenko
          added a comment -

          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).

          Show
          Sergiy Litsenko
          added a comment - 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).
          Hide
          Brian Carothers
          added a comment -

          The WAR/REST-based deployment model was addressed as part of MODE-52 (DNA-55).

          Show
          Brian Carothers
          added a comment - The WAR/REST-based deployment model was addressed as part of MODE-52 (DNA-55).
          Hide
          Brian Carothers
          added a comment -

          The need to provide a JCA package for DNA is covered in DNA-255

          Show
          Brian Carothers
          added a comment - The need to provide a JCA package for DNA is covered in DNA-255
          Hide
          Brian Carothers
          added a comment -

          The specific deployment models (WAR-based, standalone, JCA-based) discussed in this bug have been split out into separate (linked) issues, some of which have already been completed. Resolving this defect and tracking progress on the specific topics in the associated specific issues.

          Show
          Brian Carothers
          added a comment - The specific deployment models (WAR-based, standalone, JCA-based) discussed in this bug have been split out into separate (linked) issues, some of which have already been completed. Resolving this defect and tracking progress on the specific topics in the associated specific issues.
          Hide
          Randall Hauch
          added a comment -

          Marking as closed.

          Show
          Randall Hauch
          added a comment - Marking as closed.

            People

            • Assignee:
              Unassigned
              Reporter:
              Sergiy Litsenko
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: