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 fourth in a series of blogs on the development of our framework, and discusses the features it provides. The one that was announced last time, about building blocks, is momentarily postponed.

So far I’ve discussed the goals & challenges surrounding the development activities, but I’d like to focus more on the framework itself now, and what it brings to those that are using it.

As soon as a new party (be it service consumer or service provider) connects to our framework, it can profit directly from the wealth of functionality we deliver out-of-the-box. These ‘generic features’ are exactly what one would expect from a (logical) ESB, and are partly based on the Expanded Enterprise Service Bus Pattern.

 Read more

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 third in a series of blogs on the development of our framework, and discusses the challenges we had to meet.

In the previous blog of this series I mentioned the goals we had to reach. Succeeding in doing so of course meant we had to overcome a lot of challenges. In order to keep this blog from reaching the size of one of the books of the ‘Lords of the Rings’ trilogy, I’ll keep it limited to the five below, which together form a pretty good picture of what we had to deal with.

 Read more

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

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

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

Unlike announced in my previous post this one is neither soon nor on a surprise topic. It is about a general aspect of Android that is, to my opinion, very powerful but often under utilized.

Android apps are not monolithic but rather a collection of components of different kinds. I suspect android took inspiration from the concept of midlet suites in j2me and believe it expanded on that quite well.
These components (except for provider) can be exposed through intent filters in the package’s manifest and can be used by other components in different packages. This allows apps to accomplish tasks together which a single app could never do.
 Read more

In a previous blog I talked about the integration we’ve achieved between XebiaLabs’ Deployit and IBM’s Workload Deployer (still called WebSphere CloudBurst Appliance at the time) to allow users to deploy Java EE packages straight to a private cloud environment managed by IBM Workload Deployer. An IBM developerWorks article with more details is in the publishing queue. When it’s been published, I’ll post a link here. In this blog, I’d like to discuss another integration we’ve been working on.

IBM’s WebSphere DataPower appliances are a family of appliances that provide valuable services for SOA architectures such as XML acceleration (XA35), XML security (XS40) and data integration/ESB (XI50 ). While the DataPower appliances provide a powerful web-based management GUI, they are not easy to automate. The only command line available is an interactive command line that requires you to telnet into the appliance and the other way to automate the system is a SOAP/XML based API that requires quite a lot of coding.

(more…)

A flexible architecture can only come to its full potential when the organization itself is flexible. Read more

This Blog is a kick off to for many writings about architecture in an Agile World. We will explore the topic from all the views possible, in order to gain a better understanding about it. By doing so, we hope to create a community of followers, who would also like to contribute or discuss about this topic.

Xebia is helping many organizations in the Netherlands, France, the United States and India with implementing an agile way of system development. In most of the cases the Scrum method is applied and very good results are achieved. Business and IT are working much closer together, resulting in more quality and much more customer satisfaction. However, lately we also see a trend in problems that seem to occur in (almost) every organization. Software is developed in a fast way with high quality, but it takes forever to get it in production. The more teams are being formed, the more interdependencies between the teams occur Read more

Last week I got a presentation for a security device I had never heard about.
Most times this means it is something which is not commodity, or has no real use-case.

But this time I was really impressed. The device is a possible replacement for IBM Datapower XML Security Gateway. But the way they designed the device is totally different.

What CrossCheck networks did was creating a device with just security as main use case. First of all it was an XML gateway, nowadays is does support HTML, XML, SOAP, FTP, JMS and others.
It also translates different flavors of JMS to each other, it can even convert from IBM MQ to JBoss MQ directly.

 Read more