I'm starting an JBoss to use on the development, and I'm using it as standalone.
I read that on the production environment the JBoss should be as a domain.
I searched for that to understand what's the difference between than. But I didn't found any document well explained.
That's not really correct. Standalone is fine for production. It's commonly used in production, especially when you only need one instance of the server.
Domain is used when you run several instances of JBoss AS and you want a single point where you can control configuration from. You can read more about it in the documentation.
Update
The link has been changed to the latest version of WildFly as the JBoss AS 7 documentation has been archived, but is still available at https://docs.jboss.org/author/display/AS71/Admin%20Guide.html#8094211_AdminGuide-StandaloneServer
Standalone mode
each JBoss server has its own configuration
single JVM process
Domain mode
central control of multiple servers
central configuration for multiple servers
It's important to understand that the choice between a managed domain and standalone servers is all about how your servers are managed, not what capabilities they have to service end user requests. This distinction is particularly important when it comes to high availability clusters.
So, given all that:
A single server installation gains nothing from running in a managed domain, so running a standalone server is a better choice.
For multi-server production environments, the choice of running a managed domain versus standalone servers comes down to whether the user wants to use the centralized management capabilities a managed domain provides.
Running a standalone server is better suited for most development scenarios. Any individual server configuration that can be achieved in a managed domain can also be achieved in a standalone server, so even if the application being developed will eventually run in production on a managed domain installation, much (probably most) development can be done using a standalone server.
For the Above explanation and more follow this link
Related
Background Context:
Due to enterprise limitations, an uncooperative 3rd party vendor, and a lack of internal tools, this approach has been deemed most desirable. I am fully aware that there are easier ways to do this, but that decision is a couple of pay grades away from my hands, and I'm not about to fund new development efforts out of my own pocket.
Problem:
We need to send an internal file to an external vendor. The team responsible for these types of files only transfers with SFTP, while our vendor only accepts files via REST API calls. The idea we came up with (considering the above constraints) was to use our OpenShift environment to host a "middle-man" SFTP server (running from a jar file) that will hit the vendor's API after our team sends it the file.
I have learned that if we want to get SFTP to work with OpenShift we need to set up of our cluster and pods with an ingress/external IP. This looks promising, but due to enterprise bureaucracy, I'm waiting for the OpenShift admins to make the required changes before I can see if this works, and I'm running out of time.
Questions:
Is this approach even possible with the technologies involved? Am I on the right track?
Are there other configuration options I should be using instead of what I explained above?
Are there any clever ways in which an SFTP client can send a file via HTTP request? So instead of running an embedded SFTP server, we could just set up a web service instead (this is what our infrastructure supports and prefers).
References:
https://docs.openshift.com/container-platform/4.5/networking/configuring_ingress_cluster_traffic/configuring-externalip.html
https://docs.openshift.com/container-platform/4.5/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-service-external-ip.html#configuring-ingress-cluster-traffic-service-external-ip
That's totally possible, I have done it in the past as well with OpenShift 3.10. The approach to use externalIPs is the right way.
Can embedded tomcat or any such embedded server be used for microservices in production environment? How, embedded server is different wrt the normal standalone full fledged server (performance . reliability wise)? Is the embedded server light weight compared to standalone? What are the features that embeded servers do not have compared to their standalone ones? Can we change the default security settings, tls ciphers etc advanced things in embedded tomcat?
Well, it's a matter of choice. I've seen some services which use embedded tomcat in production and some services which rely on standalone tomcat container which is directly provided by the platform. Some platforms might not have a java runtime, in such scenarios you're bound to use embedded containers for tomcat or jetty.
The key difference would be that standalone containers can host multiple java deployments whereas for single deployments you can stick to the embedded ones. And yeah reliability and performance won't be a huge concern, although I believe that standalone containers are designed to be more scalable. From my personal experience, embedded deployments are easier to manage, since we can custom configure the tomcat setting specific to that deployment (might be the answer to your last question)
I have a server on which should running several Demo Applications on JBoss. The applications are exactly the same like each other. Only the ports for the web access, used database and so on should be differ (so each customer has an separate access to his demo system). All demo applications should be running on the same machine / operating system.
Whats the best/correct way? Standalone (with different JBoss instances for each demo application; see also here)? Or the domain mode with different JBoss server/server-groups for each demo application?
This depends on if you want to manage your servers from one location (so called Domain Controller) - it will give you the ability to control all servers (hosts in this case), deploy apps and configure them from one management console. If you need this, you could benefit from Domain Mode. If not, there is no reason why you shouldn't have separated instances of JBoss in standalone mode and control them separately, both options are perfectly fine.
I know there are cache products supporting cluster, JBoss Cache etc.
But the JBoss Cache only works for JBoss server and it's not application-level component.
Is it possible to write own cache for cluster in my application? Each application instance cannot know other instances in cluster, is it true?
Have you checked infinispan? It's from JBoss too, but it has an api to control it programatically. To be clear, you don't need to run JBoss, you just need to add the infinispan jar in your app.
In a few words: terracotta.
Brilliant solution. Works fantastically, good support on the forums. Good error messages.
No source footprint, it's all a matter of configuration. Tc will instrument your code with bytecode needed to communicate with the tc server.
Backside: is hub and spoke design. Needs a designated terracotta server.
Why do we need Application Server in Java like JBoss or WebSphere. Is it possible that we develop large scale website only with Java (Apache Tomcat). Where thousand of user connect on site at a moment. An example is a website like b2b.
What is the cost of a Application Server? I will be thankful if you compare price among different application server and if there is any free version kindly highlight it.
Application Servers are mostly used if you want to use advanced features like transaction management, hot code swapping and advanced persistence.
There are application servers that are open source. E.g. GlassFish and JBoss.
I don't think you need an application server for building a popular web site, you'll also be fine with a servlet container like Tomcat or Jetty.
In short Application Servers provide you with few services like
Transaction Management
Load Balancing
Security
Threading
etc.
You have to take care of these things yourself in a Web Server.
There are few Open Source Application servers which are free of cost.
I have used Glassfish.
Apart from answers given above, App Servers are required for EJBs.
You need Application Server as follow:
It provides you useful services like automatic transaction,Authentication,Authorization,Lifecycle management.
To remember large user data across pages using ejb's pertaining to a client.
Load balance the user request and buisness logic.
To interact with different Client UI like Java Swing,Browsers.
It is possible to handle the httpheaders yourself. We have done socket servers in java for 20 years. You do not need a container for java swing.
Persistence can be done through databases or server side files unless you need real high speed stuff. I have yet to find a real requirement for an ejb
except that some systems simply require them
This may be because jboss can provide better after-sales service, and jboss, etc. can provide operation and maintenance support, etc. This may be the reason why many large companies choose commercial versions of servers.
But you must know that tomcat and netty are not bad. For example, many large B2B or C2C or B2C companies still use tomcat, such as Internet companies such as Alibaba.
Choose a server
Operation and maintenance costs
Scalable costs
Server cost