12 Replies Latest reply on Jun 13, 2018 5:12 PM by Jason Miller

    Jetty: What features use it?

    Thad Esser

      I'm new to ARS 9.1.04 and jetty, and was curious what features make use of the jetty server?  I'm aware of the REST API and the new CMDB Admin console:


      Are there others?  I looked through the jetty config files, and couldn't find where the contexts are defined (not even sure if "contexts" is the right terminology).




        • 1. Re: Jetty: What features use it?
          Rahul Singhai

          Hi Thad,


          I'll be happy to help you. As you rightly mentioned REST APIs and CMDB Admin Console are deployed on Jetty. There is no other application deployed on Jetty.


          I'm curious, is there any specific use case, scenario you need this information for, or if you are encountering any issue in Jetty? Probably that will help us to provide you elaborate information and help you out.


          Thanks, Rahul

          2 of 2 people found this helpful
          • 2. Re: Jetty: What features use it?
            Ganesh Gore

            Jetty is webserver for REST APIs, nothing else.

            3 of 3 people found this helpful
            • 3. Re: Jetty: What features use it?
              Eric Wuensche



              I would also like to know the web applications deployed with 9.1.04 - not only the applications but also the different web servers.

              It is actually a real nightmare as an administrator to keep track of all the different app servers and configurations that are being used - especially in terms of securing or disabling those applications.

              SmartReporting, SmartIT / DWP, MidTier, RSSO, CMDB Admin Console, AR REST API, CMDB REST API all are mostly only available via the installer and different application servers are installed at different locations.

              This makes it almost impossible to get those applications deployed in a standardized and automated way in an environment where you don't have direct root access to servers - additionally it is hard to migrate between systems, if there is no centralized configuration possible for the applications, but an installer needs to be run, which manipulates many configuration files.

              Is there a possibility to get all these applications harmonized and deployable as a standard WAR file (MidTier is a good example)?

              Or am I missing that there are already such methods available?


              In regard to the CMDB Admin Console, I also don't understand why the 3-tier architecture gets mixed up now and is not differentiated between frontend/backend.

              Is there a possibility to integrate the CMDB Admin Console with RSSO?


              Thanks, Eric

              • 4. Re: Jetty: What features use it?
                Stefan Hall

                Me too,

                I had already asked these questions and had not yet received an answer. Just take a look in Everything that you need to know about accessing new CMDB UI, maybe someone from BMC will answer. I took the chance to remind Stephen Earl.


                You could also vote for the idea of Henrik Hauchwitz, the embedded Tomcats are the problem: install with an external Tomcat instance

                • 5. Re: Jetty: What features use it?
                  Thad Esser

                  Mostly, it was curiosity, but I was weighing the pros and cons of two different options with respect to networking for the jetty server.  Currently, we have our mid-tier servers and AR servers behind load-balanced names, such as "midtierLB" and "arsLB" (not the real names).  The two options I was considering:

                  • First Option:  Set up a new load-balanced name, something like "ars_API_LB", which would listen on port 80/443, and redirect the traffic to port 8008 on one of the AR Servers.  This would give customers a specific name to use for building integrations, without having to specify a port.  It would also allow us to change the jetty port without having to update any integrations.  The downside would be that the CMDB Admin console would be accessed through a URL that has "API" in the name, which could be confusing.  Although, that'd be a small user base - unless there were other contexts that were needed by a larger user base.
                  • Second Option:  Have the customer use the mid-tier load balanced name for integrations, which they are already familiar with.  Configure the network so that mid-tier traffic with the relevant contexts (such as "midtierLB/api/" and "midtierLB/cmdb/") redirect to port 8008 on one of the AR servers.  This option takes away the need to set up a new load balanced name and keeps the customer using what they are familiar with.  The downside, and what prompted my question, is that we'd have to be aware of all possible contexts and set them up prior to using them.


                  I think the first option probably will be the easiest to maintain, so my question was more out of curiosity than anything.  I had recently found out about a kettle status page that I didn't know about, so I was prodding for other little gems with regard to jetty.  :-)




                  • 6. Re: Jetty: What features use it?
                    Rahul Singhai

                    As stated by Stefan Hall there is a discussion on deployment of Jetty and other web servers. You may like to follow that for further queries and clarifications.

                    Nevertheless let me provide you a quick info on few things.

                    In regard to the CMDB Admin Console, I also don't understand why the 3-tier architecture gets mixed up now and is not differentiated between frontend/backend.

                    A > There is a clear segregation between frontend/backend in CMDB Admin Console architecture. Although both are not sitting on different web server like it appears to be in case of Mid-tier. I am assuming you are perceiving Mid-tier as a front-end layer in 3-tier architecture. You are almost correct though, however we may not like to consider Mid-tier as pure front-end as it indeed has its own back-end (servlets, listeners, session management, authentication etc.) sitting on same web server, and it is communicating with AR server through RPC APIs.


                    Is there a possibility to integrate the CMDB Admin Console with RSSO?

                    A > Yes. RSSO can be well integrated with Jetty; starting from 91SP4 and therefore CMDB Admin Console be accessed with RSSO authentication route as well.


                    Regards, Rahul

                    • 7. Re: Jetty: What features use it?
                      Eric Wuensche

                      Hello Rahul Singhai,


                      thank you for your explanations.

                      Yes the CMDB UI is still a front and backend server application, but there is no choice for us as a customer where and how to set it up - and isn't that flexibility a goal of that architecture? I'm looking at this topic from the perspective of an administrator who needs to specify each port and connections in the network clearing. Therefore I would also like to see web applications to be deployed on the web servers, where standard ports are applied and necessary configurations can be done in a consolidated way.

                      Opening all different ports on different servers is a first pain point, the other is maintaining security options for those different web application servers (and I rarely see security updates for these being included in Patches).

                      And as Thad Esser mentioned, those applications are more or less hidden with the default installation.

                      With SmartIT / DWP there exists a Port List for all the applications and interconnections - maybe someone can provide the same for AR / ITSM setup, as it is not just AR and MidTier since a while now (or does it already exist?).

                      • 8. Re: Jetty: What features use it?
                        Thad Esser



                        Now that 18.05 is out, I have a follow up question.  After reading the docs, and watching the YouTube videos, it appears that the new Atrium Explorer uses the jetty server as well.  Is that correct?  I would guess that it uses the same /cmdb/ context as the admin console?




                        • 10. Re: Jetty: What features use it?
                          Thad Esser

                          Thanks for the confirmation.  That's what I was guessing, but didn't want to assume.  That changes the user base that would be accessing the jetty server.


                          I had read the article you mention before posting my original question and just re-read it.  Unless I'm totally missing it, that article addresses the CMDB Administration console, and my current question was about the new version of Atrium Explorer in 18.05.  You answered my question though, so thanks.

                          • 11. Re: Jetty: What features use it?
                            LJ LongWing


                            I think they appear to be one in the same....If I start here

                            18.05 enhancements - Documentation for BMC Atrium Core 18.05 - BMC Documentation

                            Under the section that says 'New CMDB Explorer to view CIs and relationships' it gives you a link

                            Searching and viewing CIs and relationships in the CMDB Explorer - Documentation for BMC Atrium Core 18.05 - BMC Documen…

                            still talking about CMDB Explorer....then under 'If A Problem Occurrs' there is a link to

                            Configuring the URL and user permissions to access the new CMDB UI - Documentation for BMC Atrium Core 18.05 - BMC Docum…

                            which provides the same link/reference to /cmdb/index.html


                            So 'New CMDB UI' may be synonymous with 'CMDB Explorer'

                            • 12. Re: Jetty: What features use it?
                              Jason Miller

                              In light of this, it is a bit more work on your part but I am leaning toward option 2. This give you full control to do things like send rest traffic to your integration AR Server(s) and user traffic to user-facing AR Servers. Who knows, maybe SRM will be the next thing re-written to run in jetty and then that needs to be accounted for (more likely SRM will end up in Smart IT/DWP but still you have control to send traffic to the appropriate host(s) using option 2).

                              2 of 2 people found this helpful