IT-eye

Some people claim you can achieve business agility by using SOA. Agility meaning that IT can quickly deliver what the business needs. And that the business has the freedom to move. You need to be able to change your plans if you want to successfully operate in dynamic competitive markets.

There are two main reasons why SOA would help achieve agility: reuse and loose-coupling. By reusing existing systems you can quickly create new applications. And by applying loose-coupling you can minimize the impact of change, and therefore it’s easier to make changes to your software.

Now, i agree that these are important design principals, and applying them is essential, but i really doubt that you can achieve Business Agility just by using SOA.

What exactly is SOA? I think three words characterize SOA: reuse, heterogeneity, and processes.

SOA is a way to deal with heterogeneity. You can build applications on top of your existing applications. Using xml you can bridge the heterogeneity. It makes your applications data implementation independent. So you build a layer of xml on top of your existing systems.

For some people SOA is about processes. Being able to implement business processes as a first-class citizen in your IT solution. By making processes explicit, it should make it easier to modify the implementation when the business process changes.

But the main part in SOA isn’t about xml or processes, it’s about treating your existing systems as services and building applications on top of them by using these services.

This isn’t exactly a new way of thinking. It is an existing design pattern at the core of most JEE applications (see Service Facade), mostly implemented using EJBs. EJBs promised many of the same benefits now attributed to SOA. EJBs also promised reusable, distributed business logic, enabling you to quickly build new applications by reusing existing logic.

Did this happen? Not really. Reuse is hard. It actually limits your agility in some ways, because you can only use what’s already in the EJB. Or you have to get it changed, which is often a difficult route to take, especially if you are not the owner of the service. Other people, with goals different than yours, have to agree with your changes. And they have to make time to implement these changes. And all the other applications also using the same service need to be regression tested. Reuse and agility not always go hand in hand.

Another reason why we didn’t see a lot of reuse with EJBs was the complexity of EJBs. People disliked using EJBs because of their complexity. They disliked the complexity so much that a lot of alternative frameworks were created. The Spring Framework is one such example. Currently, Spring is probably the default way to build JEE applications. But now that EJBs have been simplified by copying a lot of good ideas from Spring and other frameworks, the use of EJBs is picking up again.

Recently Rod Johnson wrote a blog entry about Hoare: Happy Birthday Tony Hoare. One of the things Rod mentions about Hoare is that he warned about the complexity of software systems. Rod argues that this can be seen as an early warning against the complexity of J2EE.

One thing we learned from Spring is that testability is essential. You need to be able to create unit tests to test your application. This is key for agility. The faster you can test you code, the shorter your coding fase will be, the faster you will be able to deliver new functionality. The easier it is to regression test your system, the easier it is to make changes.

Current SOA solutions are often hard to (unit) test. This is largely caused by the fact that you can’t run your tests out of container, just like with EJBs before version 3. We need to be able to unit test our composite applications out of the BPEL or ESB containers. The current Oracle BPEL test framework doesn’t allow you to do this. Doing automated unit tests is really hard with Oracle ESB. But the situation is improving. For example, compare Apache Camel to Oracle ESB. Routing rules in apache camel can be tested easily, whereas routing rules in oracle esb are very hard to unit test. Guess which one is a better choice if you’re looking for agility.

Today, the java world seems to agree on the fact that simplicity is good. To build reliable systems quickly, we need simple technology, not complex. Complex technology isn’t going to enable agility. The more dependencies you have, the harder it will be to achieve agility. Simple technologies are necessary for agility.

But there’s more to agility than technology. I think technology isn’t the most important factor. Most SOA projects are complex because of the multiple ownership. Who creates what, who pays for what, how do we align all the different agendas? This complexity is hindering agility much more than technical complexity.

Another big challenge in agility is process. Does your process allow you to be agile? Or do your project management methods only allow you to deliver a year after business has requested something? How do you cope with changing requirements? Business agility means that business should be able to change requirements. You need a process that enables agility. You’re not going to be agile if you’re still using a waterfall methodology, no matter what technology or architecture you use. You need something that will enable business to continuously reprioritize their needs. And you need something that will deliver the top priorities fast.

Minimize the number of owners in your project. Use the simplest technology possible. And use the correct project management method. This is the way to deliver business agility.

Oracle just announced that they will acquire BEA: Oracle and BEA. This means that in the application server stack Oracle now has at least two of everything. For example, you now have at least three ORM choices: ADF Business Components, Toplink (JPA) en BEA Kodo (JPA). Maybe now Bea will start to actively support JSR-227.

I can’t imagine that they are going two integrate the 2 stacks. Maybe they’ll open source some of the frameworks they acquired, like they did with Toplink. Although i think a lot of the Bea pieces are already open source as Bea is a big supported of Spring. Kodo is also opensource, if i’m not mistaken.

More info: Surprise! Oracle buys BEA Systems, Oracle Strikes Deal to Buy BEA Systems for $8.5 Billion.
Also just announced: Sun is buying MySQL.

Some good advice in this article on SOA: Interview and Book Excerpt: Nicolai Josuttis, “SOA in Practice”.

Some quotes, first about user-interfaces:

The most critical misuse of SOA I currently see is to use SOA to separate user-interfaces from business logic.

Avoid SOA when you can:

Because the prices of distribution usually is high, in general I recommend to avoid SOA where you can avoid it. But there are enough requirements where you have to connect distributed systems with different owners.

Not all logic needs to be implemented in BPEL:

Of course, over time you will use different BPEL engines and other ways to orchestrate services (including implementing them in your favorite programming language).

It’s not that you shouldn’t use SOA, it’s that you should only use it when required. SOA is a solution for distributed, heterogenous systems owned by different owners.

Hope his book is as interesting as this interview.

A very often heard question of customers is; “can we change the header/footer of our reports with this or that…?”. Of course we can change this, but it can be a timespending operation. If you have a couple of reports than it is not a problem to change each report manually, but most organisations have dozens of reports. The magic word for this situation is: subtemplate.

What are subtemplates? Subtemplates are pre-defined templates with a default header, footer and other recurring reporting objects. The most common situation is a default header with a logo, report-header and a page navigation.



Which elements do we declare in a subtemplate:
1. – header: between the start and end-tag we just insert an image, declare a variable and insert the page navigation.

< ?template:Header?>
	insert your text and/or image
< ?end Header?>

2. – footer: In the footer we alse can define just the text or graphics we want. In this example I wrote the company missionstatement.

< ?template:Footer?>
	insert your text and/or image
< ?end Footer?>

Now we have created the subtemplate all our reports should use it. In the template you can refer to defined report-objects in the subtemplate. In this example we can refer to the header and footer. Beside refering to the report-object we have to declare where the subtemplate resides. When generating the report from the server the subtemplate should also reside on the server or a network-drive which the server can access.



The template can call so called inlines from the subtemplate. In this example we call the footer and the header. These statements are made in the actual header of the RTF-template.
In the body of the template we declare where the subtemplate resides. This import statement looks like this:

< ?import: file:///D:OracleBIDatasubTemplate_a4.rtf?>

Be aware of the three forward slashes!

The option “Disable external references” is default disabled for a BI-pubisher report. If you want to make use of the subtemplate this option should be enabled.

When your reports are using subtemplates than the question above is not timespending at all. Just change your logo or some text in the subtemplate and your reports have the new layout!

You know the situation:you’re the only programmer on what is supposed to be a very small project. So small, it seems overkill to install a version control server. And it’s too much trouble to install the server software on your workstation.

So you start working in a local folder without version control. But soon enough you wish you’d used version control. Maybe because you’d like to read your old commit logs to find out why you made that change some weeks ago. Or maybe because you wish you’d be able to undo that change that didn’t really fix the problem.

Today i was reading up on some of the new distributed version control systems, where every developer can have his own repository. Dave Dribin has written some interesting posts comparing Git, Mercurial and Bazaar: Choosing a Distributed Version Control System and Why I Chose Mercurial.

I used to think that distributed version control systems were mostly useful for very large projects, with large numbers of developers. But creating a local repository with mercurial is so easy, you don’t even have to install some server repository process, that it’s also ideal for solo programmers. Basically you just create a folder for your sources, initialize it for version control, and now you have a version controlled project.

You can download the windows version of Mercurial (or Hg as it’s also called) here: Mercurial binary packages for Windows and Mac OS X. There are also versions available that include Tortoise for Hg.

Run the installer, and then open a command prompt. Create a folder for your project and initialize it for Mercurial:

> mkdir myproject
> cd myproject
> hg init

Mercurial will create a .hg folder where it will store all version information. You can now add and commit files like you’re used to with any other version control system. For example:

> notepad readme.txt
> hg add readme.txt
> hg commit -m "Initial release"

There’s no excuse not to use version control on every project! For more information on Mercurial you can start here: Mercurial Quickstart, and Distributed revision control with Mercurial (book).

Building SOA applications in 2007 mostly evolved around building BPEL and ESB components on top of Web Services. Even though this works, it’s not perfect. One of the biggest problems we experienced was the sheer number of components that we had to deploy and manage.

One technology that will make life a lot better in 2008 is SCA, Service Component Architecture. End of last year Apache released the first version of it’s implementation of SCA, Tuscany. And Oracle will also include an SCA implementation in it’s SOA Suite 11g.

SCA will enable developers to truly deliver composite applications. Modules that can be deployed and managed as a whole, instead of tens of separate pieces. This means that you’ll be exposing less complexity. It’ll be easier to deploy and manage. The paradox of 2007 has been that the IT industry has been promising the Business improved agility using SOA, by using more technology. But more technology usually means less agility. The more complex something becomes, the harder it is to change it. Hopefully by encapsulating all this extra technology in composite applications (yes, by using even more technology) we can deliver on the promise of improved agility.

Reuse will also improve. You’ll be able to define interfaces at the composite application level. There’s no need to expose all the interfaces of all the internal parts. And less means more. Less and clearer interfaces, more reuse.

Another big benefit delivered by SCA is that your communication protocol is now a configuration issue. You don’t have to hard code your method of communication into your implementation. This means that you have more freedom to choose the protocol that make sense for your application. Using web services and SOAP is not always the best solution. In some cases JSON or JMS or something else is a better choice. Not everything needs to be a Web Service.

The SCA standard is being developed by the Open Service Architecture Organization. SDO is another standard that’s being developed within this collaboration. SDO defines a language independent data access API that works both with XML and relational data. This will make the trip from XML to the database and back a lot easier to implement. SDO will be a very useful technology, especially when you need to work with detached data, but i don’t think it will have as big an impact as SCA this year.

I think the combination of Glassfish and Netbeans will also make a big impact this year. I’ve recently testdrived the new Netbeans version 6. I must say i’m very impressed. A high quality free and open source SOA stack, with full support for BPEL, ESB and SCA, including visual editors in Netbeans. Many companies that are currently starting with SOA are starting with small scale SOA applications. A free and open source SOA stack makes a lot of sense when you’re still test driving SOA.

And finally a small framework that i think we’ll be using this year: Apache Camel. It’s an implementation of the patterns in the well known Enterprise Integration Patterns book. It enables you to do much of the same things you do with JDeveloper mediation components (ESB), but using a java based DSL (domain specific language), which means you can write most ESB components in a couple of simple lines of java code. And the biggest benefit: easy to test using junit tests.

In het december nummer van de optimize stond een verhaal van Ronald Doelen en mijzelf over Scrum. Je kunt de pdf versie van dit artikel nu ook hier downloaden: Scrum.