One of Pivotal’s field engineers, Dan Carwin, recently began a series of posts breaking down differences between Pivotal tc Server and Apache Tomcat. In this post, we outline the five key configuration differences that Dan reported on with more detail. The upcoming, second post will cover the second category of differences—extensions to functionality.
The five key differences in configuration with Apache Tomcat and tc Server:
Most importantly, tc Server has been designed to be completely interchangeable with Tomcat—you can run the same codebase on either one, and we provide a 100% compatibility guarantee. The tc Server engineering team includes Apache contributors, committers, and team members—we are part of the community and know that integrity here means that our version must be completely interchangeable. Since we have been supporting Tomcat since 2001 (version 3.x), we can stand by our word.
Anyone who wants to make configuration changes to the ASF's Tomcat can do so, and you might see that this list includes some of the same configuration changes that you have already done. Of course, we run into many people who aren’t aware of the options. Each of these five items helps take Tomcat to another level of enterprise readiness—together, they make it easier for admins, improve scale, and enhance security.
Traditional Java EE (JEE) app servers bring complexity to the mix. In addition, they are costly and consume a lot of resources. Forrester wrote an article in 2011 about the costs saying, “Use Apache Tomcat. It is free.” IDC’s research from 2011 points how enterprises are moving “toward lower-cost application platforms that shift them closer to private, public, and hybrid cloud offerings.” Of course, you can find plenty of historical posts and debates from practitioners on costs and resources from past years.
So, if you are looking at middleware support for mobile apps, in-memory databases, auto- scaling, and virtual/cloud infrastructure, then you might want to check out our webinar coming up on Thursday, October 25th. In this session, we will cover quite a bit about vFabric tc Server:
Tomcat supports multiple instances, and you should consider installing Tomcat so that a single binary runtime directory supports multiple instances as a means of adhering to security best practices.
While the documentation on multiple instances is in the RUNNNING.txt file at the root of the Tomcat binary distribution file hierarchy, many people aren’t necessarily aware of the feature or why you might use it. To provide some insight, let’s look at how this functionality works and provide some insight to the related best practice for security.
EMC Consulting is hosting a customer facing webinar covering heavyweight to tcServer migration. The objective is to drive vFabric product and joint service revenue.
Migrating Java applications from Websphere or Weblogic to vFabric TC Server helps IT to reduce the cost and complexity of applications. Bruce Snyder will share best practices and use real life examples to explain how to transform your applications quickly and easily. Learn More/Register Now
Secure Socket Layer, or SSL, certificates are frequently used to confirm the identity of a server before consuming its services and to secure communications with the server. Typically, when an Apache web server is used to load balance requests to one or more Apache Tomcat servers (including VMware’s commercial version, tc Server), the SSL encryption and certificate authentication is terminated at the web server. Communication between the Apache web server and Tomcat is then trusted and in clear text.
However, there are organizational security policies and B2B scenarios that could mandate secure communication between Apache web server and Tomcat. Furthermore, it could be important to restrict access to Tomcat to known instances of Apache web server.
This tutorial will provide details for a configuration option that enables SSL communication and client certificate authentication between Apache Web Server and Tomcat.
At a high level, this tutorial provides instructions to
Working software is the primary measure of progress for software development teams. This is one of the principles of the Agile Manifesto and has led agile software teams to focus on implementing the most important features of a system early and efficiently. These teams usually provide frequent deployments of the software in order to receive feature validation from the business and to show project progress. The benefits are quick and frequent feedback for the developers and congruous applications for the business.
The practice of automated continuous deployment ensures that the latest checked in code is deployed, running, and accessible to various roles within an organization. Project managers can have a place to check on project progress, testers have a view into the latest builds, developers can see the their modules working with the modules from other team members, and stakeholders can see how their requirements have been translated into working software. Tomcat and tc server easily integrate with continuous integration servers to allow agile teams to realize continuous deployment while utilizing a lean application server (another practice of agile teams). You can start practicing continuous deployment very quickly using Tomcat or tc server, Jenkins, and your source control system of choice.
It's not exactly accurate to use words like "legacy" when describing systems like IBM's i5 (it will always be the AS/400 to me). Our "legacy" systems are so critical to our ($1B) business it's not an overstatement to say that our restaurants could not transact business without them. The simple majority of our development time, energy, and money is spent writing new RPG code, introducing new green screen applications, and finding new ways to make the 400 work with the rest of our expanding private cloud infrastructure. Calling something legacy has usually implied that newer systems are taking the place of the "old" way of doing things. I suppose you could say that programmers use the word "legacy" interchangeably with "obsolete".
Our AS/400 is not going away. For that reason, it's silly to call it obsolete.
I've gotten some great feedback from the session on private cloud infrastructures I did at this year's SpringOne 2GX in Chicago. People are very interested in how these traditional systems can work with the new cloud services many are introducing into their enterprise. Plenty of organizations have decades of business knowledge and data tied up in "legacy" systems and they want to know how in the world they can get a fancy new cloud application server like tc Server to talk to their AS/400 (through more than SQL and JDBC).
If you have existing ASF Tomcat servers running on the same machine as tc Server, you will not be able to configure AMS to manage the application deployment, nor server configuration. AMS cannot manage ASF Tomcat to the same degree as it can for tc Server.
With the Apache Tomcat, there is a default service.bat script in the bin\ folder which allows configuration customization. For example, you can configure JVM settings and environment variables that are needed to run Tomcat as a service.
For tcServer there are couple of ways to add additional variables and/or JVM options when running tc Server as a windows service. The most common approach is to modify the Tomcat service wrapper.