[Pub] Enterprise Service Bus - Concepts

For our German speaking audience: Markus wrote a very good article about Enterprise Service Bus concepts for jaxenter. This article gives a good introduction on ESB concepts, Integration Patterns, Binding, Transformation... the whole program :-)

It is freely available, so...

[Misc] Google App Engine

Today I came in contact with a post writing about the Google App Engine.

"[...]Google App Engine is designed for developers who want to run their entire application stack, soup to nuts, on Google resources.[...]"

Focusing on service oriented architecture, this approach can be interesting, because companies can host their services on google and service consumers have a common way to access these services. By using the google platform developers can do the following:

• Write code once and deploy
  Developers write the code, and Google App Engine takes care of the rest
  
• Absorb spikes in traffic
  Automatic replication and load balancing with Google App Engine
• Easily integrate with other Google services
  Using built-in components provided by Google

The service is now launching in beta and has a number of limitations. The first 10 000 developers will get a committment for development.

"The service is completely free during the beta period, but there are ceilings on usage. Applications cannot use more than 500 MB of total storage, 200 million megacycles/day CPU time, and 10 GB bandwidth (both ways) per day. We’re told this equates to about 5M pageviews/mo for the typical web app. After the beta period, those ceilings will be removed, but developers will need to pay for any overage. Google has not yet set pricing for the service."

At present applications must be written in Python, because Googles infrastructure is based on it.

Update: Christoph wrote us a comment and refered to the Google App Enging Blog as good resource!

[Event] Sustainability and IT

Today, on Monday 7, we invite to an event at the Austrian Computer Society with the topic "Sustainability and IT", the rest of this posting is in German, so is the event:

Ich möchte alle Mitglieder des Open Source Arbeitskreises der OCG sowie alle anderen Interessenten und Spätentschlossene (!) zu folgender Veranstaltung Einladen:

Heute, am Montag den 7. April (!) 2008, 16:30

Zemanek Saal der Österreichischen Computer Gesellschaft (OCG)

Wollzeile 1-3, 1010 Wien

"Nachhaltigkeit und IT - Eine Neuorientierung"?

Folgende Programmpunkte sind geplant:

• Alexander Schatten: Einführung zur Veranstaltung, und Idee der Neuorientierung des Arbeitskreises
• DI Friedrich Schmoll (Umweltbundesamt): "Green IT---Nur ein Marketingschlagwort?"
• DI Georg Meixner (IBM): "IT-Nachaltigkeit und Kosten"
• Diskussion mit den Vortragenden
• Diskussion über zukünftige Aktivitäten und OCG Arbeitskreis-Ausrichtung
  

Für alle weiteren Vorschläge bin ich natürlich offen, bitte entweder hier diskutieren, oder persönlich per Email an mich. Weitere Details auch im neuen Blog: Forum Nachhaltigkeit.

[Pub] Open Source ESB Mule

In the current issue of the Java Magazin I published my second article focusing on Enterprise Service Bus. This article illustrates the concepts and basic functionalities of an ESB based on the Open Source ESB Mule. In order to make the illustration more manifest I (supported by Werner Guttmann) implemented a prototyp with Active MQ, JBPM and Mule. A description and a download of the prototyp is available here.

Mule ESB is one of the most used Open Source integration platform in the Java community. This article describes the major components of Mule, such as:

• Mule Architecture and the programing model of Mule
• Service Components (alias Universal Message Objects)
• Endpoints, Routers, Filters
• Available Transports and how a transport is organised
  

On March 31, Mulesource announced the major Mule 2.0 release. The new version of Mule comes with a complete new schema-basd configuration style based on Spring 2.x (Enxtensible XML Authoring). Configuration should be easier as before.

As Mule 2.0 uses Spring as default configuration mechanism Mule user can also use Spring cababilities without thoughts, like:

• Spring AOP
• Springs transaction management
• Resource handling of Spring
• and many other features (DI, ...)

A full list of what is new in Mule 2.0 can be found here. At present many extensions around Mule, available on Muleforge, will be updated to Mule 2.0. After updating the prototyp on Mule 2.0 I will write an extra blog with my impressions about the new version. So for this time, I'll suggest to download the prototyp and see the power of Mule.

[Misc] Registry vs. Repository

In present software projects you encounter buzz words, such as SOA, Registry, Repository and many others. Today I took some time to look at the differences between Registry and Repository. From understanding I always had some "question marks" about:

• Are there any differences between them?
• Sharing concepts?
• Is there a relationship between a Registry and a Repository?
• Why is it necessary for a SOA, or does an SOA also work without an Registry?

Many people use these words as synonym, but there are two different worlds as I found in a blog. On this blog I've found a statement:

"[...] webcast on the topic of registries and repositories, the consensus was that registries hold references to things and repositories hold the things. [...]"

Based on this statement we can say, that Service Registries contains Meta Data about the services available in a repository. A Repository can then be used without an registry, but a registry without repository makes less sense, or does it?

"Design-time data typically reflects artifacts such as code -- and thus typical design-time repositories use standards such as CVS (Concurrent Versions System). Runtime repositories typically store messages and provide query, audit, logging and a variety of archiving capabilities."

	Design-time	Runtime
Registry	Discovery Description	Contracts Policies Versioning
Repository	Code versions Documentation	Queriable message store Logging Auditing

A RDMBS is a good example for a repository at runtime. You can save your data and query this data by using SQL for example or other query languages. A phone book for example can be seen as a registry.

I hope the difference is clear between them. Some hints from other people about the key differences between a Registry and Repository?

[Tech] Enterprise Integration Patterns with Active MQ 5

In december 2007 the Apache ActiveMQ community released version 5.0 of their message broker. A couple of new features have been added to the broker. One very interesting feature that has been implemented is the complete integration of Camel into ActiveMQ.Camel is a subproject of ActiveMQ, developed by the same community which provides an implementation support for enterprise integration patterns. Patterns can be used by either coding them with a specific Java DSL or by using Spring XML configurations. The Camel project website provides a full list of supported patterns and coding examples for them.

Before the release of ActiveMQ 5.0 the following procedure had to be went through when deploying Camel rules:

1. Start the message broker
2. Create a CamelContext, either in Java or Spring configuration
3. Add all required Camel rules to the context
4. Start the context

But now it is possible to configure all rules directly in ActiveMQ. The configuration file (conf/activemq.xml) contains an element camelContext where one can specify rules in XML or a package which contains all rules written in Java DSL. When using Java DSL all routes have to be put into a jar file which has to be copied into the lib folder of ActiveMQ.

A simple routing configured in XML could look like this:

The Java class for implementing this route looks like this:

In the ActiveMQ configuration this class can be referenced by using the package XML Tag in the Camel configuration. Thus, there are two ways to configure Camel rules directly in the ActiveMQ configuration file.

I think the prefered way should be to use Java DSL for coding all routes as it is more readable than long complex XML statements. Furthermore the usage of Java DSL splits the configuration of the broker and the implementation of patterns apart which leads to a better clearness as the configuration is not blown up with long Camel XML routes. However for very simple rules the XML approach is faster to configure and to deploy than writing a Java class. But as soon as rules are getting more complex the Java approach should be prefered.

Conclusion

The integration of Camel adds routing and mediation capabilites to ActiveMQ which one would usually expect from an enterprise service bus, but not from a message broker. Thus for business cases where only routing and transformation of messages are needed, ActiveMQ can replace an ESB framework like Mule or ServiceMix.

However if orchestration or choreography are required the use of ActiveMQ alone is not enough. Nevertheless the new release of ActiveMQ makes it a good player in the EAI domain because not only messaging- but also capabilities of an ESB are provided.

Article by Robert Thullner, edited by Alexander Schatten

[Tech] Two Cultures: iPhone and Android

Finally, the iPhone SDK is out and the development community showes mixed emotions. Apple seems to have difficulties in providing the SDK (that costs about 100$ per year) to all developers who show interest, and particularly non-USA developers seem to be disregarded. Then there are questions whether third-party developers can use the full functionality of the iPhone, e.g. the "iPod" functionality seems to be locked; then what about development of "services" that run permanently in the background (like chat applications) and so on. Additionally Apple provides a very specific way of distribution of applications: iTunes. This is good and bad news, depending on the viewpoint: On the one hand it takes away a lot of infrastructure problems for developers as they do not need to deal with sales infrastructure (servers, payment, distribution, installation...), on the other hand, Apple decides in the end which applications will be listed and how (plus of course takes a share from the sale).

Now, I have to say, that I share great sympathy for Apple's design in general; specifically I love the iPhone platform (I do not need a mobile phone, so I "just" have an iPhone touch, which practically the same platform): it is a great system, excellent user interface and applications.

Having said that, I have mixed emotions about the platform lock-in. And here comes Google Android, and we really see two sides of a coin:

• The iPhone started as a completly closed-up system under the hardware and software "control" of Apple and is apparently very well "tuned". The API is just released step-by-step to "third party" developers (and not to all of them as yet).
• Google Android starts with an elegant top-to-bottom open (source) API and development tools based on Java (which has a huge development community), but without hardware
• The iPhone is rather tightly coupled to the Mac platform (OS, API), Android is based on OS operating system (Linux)
• From all applications are equal (Adroid) to some applications are more equal than others (iPhone)
• One hardware/handset producer (iPhone) versus anyone can produce handsets (Android)
• Long and successful experience in mobile products (iPods); but neither Google nor Apple have a history in mobile phones (which could be seen even as an advantage, when we look into the mobile phone market...)
  
• Software distribution "laissez-faire" in Android versus clear conditions and company driven distribution channel (Apple)

I think, we see here a clear clash of cultures; Apple has a very proven platform based on years of iPod experience and even longer experience with operating systems, yet drives the iPhone project in a very traditional "top-down", one might even say paternalistic manner. I am sure there are good arguments on Apples side. E.g. a the demand for a consistent user experience.

On the other hand we have a bottom-up, as I already said "laissez-fair" approach that Google suggests. I personally (who would have thought otherwise) prefer the Google approach, despite the fact, that I believe that the iPod/iPhone platform is very well designed. Having said that, Android has still a long way to go to come to be comparable to the iPhone. I really hope that the mobile-phone dinosaurs are finally blown away by proper technology and platforms that allow solid software engineering. The past has proven that the open source model can attract a huge number of developers and great products, but it also showed (but this is a topic for a different posting), that the open source model also had a problem in providing a consistent and user friendly UI experience (particularly for non-experts); this is where Apple is "at home".

And the winner is...? Yet to be seen.

[Misc] Dave Rosenberg on Open source's business opportunities

I've found an interview with Dave Rosenberg, CEO and co-founder of Mulesource the company behind Mule ESB. There is much noise around Mule and SOA and why Open Source technologies can be used to set up a lightweight SOA. In this interview Dave Rosenberg discuss the opportunities of Open Source in business and what the future brings. I've summarized some interesting statements:

• Open Source challenge continues to be innovative while delivering high-quality products
• Open source distribution puts software closer to customers
• Wide-scale adoption of open source in mission-critical applications as open source products continue to mature
• Open source is no longer a matter of "if" but instead, a matter of "when"
• Enterprises have accepted open source as part of the core infrastructure
• The biggest business misstep is probably the obsessive focus on licensing, which, while important, distracted people for way too long
• Future of software is a combination of open source and SaaS

I think Open Source technologies are still growing in importance and many companies build on open source technologies. In my opinion the most interesting thing about Open Source development is the possiblity to meet, discuss, analyse and develop with great developers, architects from all over the world.

[Arch] Architecture Patterns

Markus sent me an interesting link to a paper from Markus Völter (who is well known through the Open Architectureware project) that I would really like to share with the Blog audience: In his paper "Architecture Patterns", Markus Völter suggests a pattern language and a methodology to define a Software architecture that is not "based" or depending on specific technology. In the abstract he writes:

"The craft of defining an architecture – independent of buzzwords – has gone out of fashion. Designing architectures on a conceptual level is not something people learn, or read books about (there aren't many books on this topic!). The view for the essential aspects of an architecture is obstructed by all the technology crap."

Strong words indeed, not only in the abstract, yet I believe this article provides good material for discussion!

[Arch] Developing in a SOA world- Developer Perspective

Gregor Hohpe, author of Enterprise Integration Patterns talks (May 2007) about developing in service oriented world, while focusing on developers perspective, and what does it mean for developers work on SOA. The first part of the talk gives an introduction to Service Oriented Architecture, where does it come from, including there main drivers, such as:

• Distributed component architecture
• Transparency to developer (marshall, unmarshall, and all the low level things)
• Loose Coupling of components

He also points that SOA is not a technology. SOA is an architectural style with some main characteristics, like:

• Simplicity of interaction
• No notion of object oriented issues
• No lifecycle control
• Self contained documents (XML)
• Asynchronous interaction

As a consequence of these characteristics developers will be forced to rethink in software design, because the programming model in SOA is somethink like:

• Event Based and Asynchronous Programming
• Declarative Programming
• Object/Document Mapping (like O/R mapping)
• Process Modeling (long running instances, complex transaction models, correlations between running processes)

To summarize the talk I would say, that he see some aspects in SOA critical from developer perspective and points to the complexity that comes with the new architecture style. But the presentation gives a very compact overview about SOA and what does it mean for developers to work on SOA projects.