Installing Tomcat on Mac OSX (Snow Leopard)

November 12, 2009

Complete fresher here, and I guess there might be guys out there in the same boat. Here are the steps I needed to go through to make it work. Following some pointers on the way there:

Start by downloading what we need from

For the latest version see the Which version , but I used 6.x and got the core zip.

After you have downloaded it , most likely to the downloads folder unpack it and rename the folder to Tomcat for simplicity

Copy the complete folder to $$your_profile$$/Library

After you have done this , and got stuck here for a bit, run the following command to enable you to execute the commands from terminal.

chmod a+x /users/$your_profile$/library/tomcat/bin/*.sh

If you don’t expect to see the following:

Peter-Versters-MacBook-Pro:~ Peter$ /users/peter/Library/Tomcat/bin/

-bash: /users/peter/Library/Tomcat/bin/ Permission denied

This will make the files writeable and allow you to start the service.

Then execute the following:


Provided you are still with me navigate to http://localhost:8080 to test if the services is running.

Final step to give you admin access to the site:

is to set up the users as per the following:

conf/tomcat-users.xml in your installation. That file will contain the credentials to let you use this webapp.

You will need to add manager role to the config file listed above. For example:

<role rolename="manager"/>
<user username="tomcat" password="s3cret" roles="manager"/>
Happy Tomcatting...

SOA and Why it Matters

November 4, 2009

Services, clouds, and mashups: Why buy enterprise software?

In previous ZapFlashes, we talked about how the emergence of services at a range of disparate levels combined with evolutions in location- and platform-independent, on-demand, and variable provisioning enabled by clouds, and rich technologies to facilitate simple and rapid service composition will change the way companies conceive of, build, and manage applications.

Instead of an application as something that’s bought, customized, and integrated, the application itself is the instantaneous snapshot of how the various services are composed together to meet user needs. From this perspective, enterprise software is not what you buy, but what you do with what you have.

One outcome of this perspective on enterprise software is that companies can shift their spending from enterprise software licenses and maintenance (which eats up a significant chunk of IT budgets) to service development, consumption, and composition.

This is not just a philosophical difference. This is a real difference. While it is certainly true that services expose existing capabilities, and therefore you still need those existing capabilities when you build services, moving to SOA means that you are rewarded for exposing functionality you already have.

Whereas traditional enterprise software applications penalize legacy because of the inherent cost of integrating with it, moving to SOA inherently rewards legacy because you don’t need to build twice what you already have. In this vein, if you already have what you need because you bought it from a vendor, keep it – but don’t spend more money on that same functionality. Rather, spend money exposing and consuming it to meet new needs. This is the purview of good enterprise architecture, not good enterprise software.

When you ask these people to show you their enterprise software, they’ll simply point at their collection of Services, Cloud-based applications, and composition infrastructure.
The resultant combination of legacy service exposure, third-party service consumption, and the cloud (x-as-a-service) has motivated the thinking that if you don’t already have a single-vendor enterprise software suite, you probably don’t need one.

We’ve had first-hand experience with new companies that have started and grown operations to multiple millions of dollars without buying a penny of enterprise software. Likewise, we’ve seen billion-dollar companies dump existing enterprise software investments or start divisions and operations in new countries without extending their existing enterprise software licenses. When you ask these people to show you their enterprise software, they’ll simply point at their collection of services, cloud-based applications, and composition infrastructure.

Some might insist that cloud-based applications and so-called software-as-a-service (SaaS) applications are simply monolithic enterprise software applications deployed using someone else’s infrastructure. While that might have been the case for the application service provider (ASP) and SaaS applications of the past, that is not the case anymore. Whole ecosystems of loosely-coupled service offerings have evolved in the past decade to value-add these environments, which look more like catalogs of service capabilities and less like monolithic applications.

Want to build a website and capture lead data? No problem — just get the right service from or your provider of choice and compose it using web services or REST or your standards-based approach of choice. And you didn’t incur thousands or millions of dollars to do that. [From You'll be far better off in a future without enterprise software | Dana Gardner’s BriefingsDirect |]