Middleware

Take the Application Release Market Survey

cbaart

We're conducting a survey to take the pulse of the Application Release market. We will reveal the top challenges and key initiatives effecting you, your business and the Application Release market in a report to be published in early 2013. The report will offer a comprehensive view of what challenges your peers are facing, the latest trends in application development and key initiatives currently being planned.

This survey will take just five minutes of your time. All personal details will be kept anonymous. Participant will receive a copy of the finding and be entered to win 1 of 3 gift certificates valued at $100, $250 and $500! Take the survey now >

VMware vFabric Application Director 1.0 demonstation setup at Xebia

fbezema

Xebia's expertise with middleware and application deployment automation led to the wish to explore new tools handling these area's.
Along came VMware's Application Director 1.0 beta and later GA, and together with VMware Netherlands we built a demo environment at Xebia.

The setup did not go real smooth, mainly because we had some infra setup troubles and the interfacing between software components did not work directly.

After all was working, I compared the vApp director 1.0 with Xebialabs' DeployIt deployment tool.
Conclusion: vApp director 1.0 is nice, but more operations/infra oriented than developer oriented. With DeployIt, when parts of the deployment (say, only a war & datasource) is changed between deployments, only those steps are done in correct order. With vApp dir, you have to script this out, or deploy everything from scratch, which takes a long time. On the other hand, DeployIt cannot create VM's by itself.
 Read more

Developing a SOA-based integration layer framework: goals

Marco Fränkel

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the second in a series of blogs on the development of our framework, and discusses the goals we had to reach.

In the previous blog of this series I mentioned the business needs that we had to address:

  • Efficiency in business processes
  • Consistency in data representation
  • Flexibility and time-to-market accelerated by the IT department.

Based on these the goals described below were set.

 Read more

Mutual SSL authentication using Websphere Application Server and CXF

Vincent Lussenburg

Outline

At my current project, some of the webservices we need to connect to are running in a non-firewalled environment. In order to prevent unauthorized clients from connecting to these services, the administrators decided that is was a good plan to use mutual authentication using SSL. Since these are all connections running within the intranet environment of my customer, the certificates are not signed by a globally trusted certification authority (like VeriSign) but by an internal certificate authority which is not trusted by default.

Globally, the picture looks like this:
[WAS]--https->[[IHS]--http->[WAS]]

WAS = Websphere Application Server
IHS = IBM HTTP Sever (Apache with extra's)

We have webservice clients running in WAS which use Apache CXF, an open source services framework, to communicate with webservice providers. These providers are running on another WAS instance. The HTTPS connection terminates at the IHS which runs on the same machine as the WAS instance to connect to. The WAS instance then is configured to allow only connections from localhost.
 Read more

Setting up your own LDAP server with Apache DS

Misja Alma

The LDAP protocol has been around for quite a while. Today it is mainly used for authentication but you could use it to make almost any kind of information available in your network.
In this article I’ll show you how to set up your own LDAP server using the open source Java based Apache DS server.
 Read more

Developing a SOA-based integration layer framework: introduction

Marco Fränkel

A few years ago I was asked by one of our customers to help them make better use of their integration layer. At that time it consisted of 2 or 3 integration platforms, some home-made software running on top of those, and a few minor rules about how to use it all. None of the benefits of a ‘real’ ESB were reached, even though that was always the idea.

Ever since then me and my team have been working on a framework that could fulfill the ‘business needs’:

  • Efficiency in business processes, such as automatically coupling sub processes into a whole.
  • Consistency in data representation, such as the representation of a customer in a CRM system and in a financial system.
  • Flexibility and time-to-market accelerated by the IT department.

 Read more

Connecting Continuous Integration to Continuous Delivery

Andrew Phillips

At XebiaLabs, many of the questions we get about our enterprise deployment automation solution Deployit are from users looking for automated deployment as a prerequisite for Continuous Delivery. Often, this the result of initiatives to extend existing Continuous Integration tooling to support application deployments.

Increasing the frequency of whole-application testing, decreasing time-to-production and delivering greater business value faster and more regularly are goals we definitely share, and in this post we'd like to pass on some key experiences and lessons from working together with our users to help them realize Continuous Delivery.
 Read more

The ultimate continuous delivery deploy(it) toolkit

Maarten Kennis

Putting software in production can be a challenge, often the frequency of going to production is low and the amount of changes/features involved is high. This usually results in a long and painfull deployment process. The release probably contains as many changes as possible because if you do not get your change/feature in this release the next release may very well be in 6 - 12 months.

To create the illusion of being able to prevent this and have more control the deployment department is often confronted with huge, 100+ pages, deployment guides decribing the deployment process in numerous, usual manual, steps. Incidents occur in the newly deployed software. Since there were so many changes in the new release, how are we going to find out which part of the newly deployed software is causing the problem.
 Read more

Scaling the hybrid cloud horizontally

Vincent Partington

After being derided as "unpure" by cloud enthusiast when the idea was first presented, we can now safely say that the hybrid cloud is here to stay. The mix of dynamic requirements within the enterprise related to government/industry regulations, security and performance require a more flexible environment than the public cloud can offer. So what does a hybrid cloud actually mean? A hybrid cloud is a composition of a private cloud and public cloud. There are two types of scaling patterns when using a hybrid cloud: vertical and horizontal.


A vertical scaling pattern is the better-known scenario. This pattern spreads different components of one application across different clouds. An example of this would be where one part of an application, typically the data, is kept private, while another part is run in the cloud, such as the web front end or calculations being made on the data.


A horizontal hybrid cloud scaling pattern, on the other hand, spreads different instances of applications across different clouds. In this scenario, enterprises develop their own applications and run them in multiple environments, some on-prem, some in the cloud. Developers run it in a test environment, testers test it in a QA environment, and users access the version that has been deployed to the production environment. Each of these environments can be in the cloud or on-prem depending on the security, performance, flexibility and scalability requirements of that environment.

read more

Cost Effective, Fast and Scalable: Is It Time You Considered Automated App Deployment?

cbaart

Our approach to software development has changed in the last few years. IT professionals and software developers are working more closely together than ever before. The DevOps trend also extends to an acknowledgement that automation is a key factor in reducing costs and increasing release speeds.

Striving to be cost effective is a constant for any business but the increased focus on speed of deployment is a product of the growth of the Cloud and Agile development methodology. The bottom line is – the faster new features, fixes and improvements reach the customer, the greater their satisfaction. The same principle applies in an enterprise environment – the faster the latest version of an application reaches users, the more productive they can be.

Both environments require scalability. As your product offerings grow and branch out, the delivery method must be capable of handling the changes. In the enterprise environment a large portfolio of software applications is the norm and any deployment solution must be able to scale.

Automated app deployment can reduce costs, increase speed and scale as needed, but before we take a look at the solution let’s discuss the problem.

App Deployment Nightmares

There are a lot of potential problems in deploying applications manually. Not least of which is the time it can consume for developers and IT support. Configuration is the first challenge. Where is the application stored? Which version should be installed? Where should it be installed? Where is the configuration file and how is it applied?

Read More