Boiler Plate

Oracle ADF Powerkurs - 15. Dezember in Bern

2011-11-30T19:23:00.000+01:00

Am 15. Dezember findet in Bern ein 1-tägiger Powerkurs zum Thema Oracle ADF Entwicklung statt. Durchgeführt von Frank Nimpius, dem Experten der Oracle für das Thema. Weitere Details und Anmeldung unter: http://www.ipt.ch/veranstaltungen/javaee-applikationsentwicklung/.

JavaEE-Applikationsentwicklung

Schnell und effizient mit Oracle ADF

Am 15. Dezember 2011 in Bern

Suchen Sie ein effizientes Framework für die Entwicklung Ihrer Rich-Enterprise-Applications im Web- und Mobile-Bereich? Oder planen Sie eine Rapid-Application-Development-Initiative in Ihrer Organisation? Wir zeigen Ihnen an diesem Event, wie Sie mit Oracle ADF signifikante Effizienz- und Qualitätssteigerungen in der Java EE Applikationsentwicklung erreichen können. Ergreifen Sie die einmalige Gelegenheit Frank Nimphius persönlich kennenzulernen, den Experten für Oracle ADF im deutschsprachigen Raum.

Nach einer Einführung in die Herausforderungen bei der Applikationsentwicklung zeigen wir Ihnen, wie das auf Standards basierende End-to-End Framework Oracle ADF aufgebaut ist. Dann vergleichen wir es mit anderen Frameworks für die Applikationsentwicklung und zeigen auf, wie Oracle ADF Sie bei der Realisierung der Rapid-Application-Development-Konzepte unterstützt.

Die Demo nach der Mittagspause setzt die am Morgen präsentierten Ansätze praktisch um und zeigt wie schnell eine Rich-Enterprise-Application mit den visuellen und deklarativen Werkzeugen der ADF-Plattform entwickelt werden kann.

Ride the Cloud at Lightning Speed

2010-11-06T03:52:00.004+01:00

How can you make your computationally intensive application run like lightning on the cloud? Use Cloud Parallel Processing!

Some computational tasks are so demanding that a single machine cannot process them within a reasonable amount of time. Applications that leverage massive amounts of data from the Web, a social media network or any other large-scale system can easily overwhelm a single machine. Many other examples exist of analytical tasks that operate on large data sets.

Parallel processing has been automated and widely practiced at the processor level. In order to utilize the cloud efficiently it is necessary to scale out. Scaling out means that multiple nodes share the workload and therefore get things done faster. Parallel processing at the application level is necessary to harness the power of the cloud.

Creating a Scalable and Elastic Application

With the advent of cloud computing a large-scale and virtually unbounded grid of compute nodes becomes a reality. In principle, this makes the cloud an ideal substrate for on-demand high-performance parallel processing. The cloud can adapt elastically when CPU requirements change and spin-up or tear-down nodes accordingly.

In the latest Gartner Hype Cycle for Cloud Computing (July 2010), Cloud Parallel Processing is an entrant of the Cloud technology adoption curve. They note that “as cloud-computing concepts become a reality, the need for some systems to operate in a highly dynamic grid environment will require these techniques to be incorporated into some mainstream programs. [] The application developer can no longer ignore this as a design point for applications.”

Parallel Programming is hard!

This points to the caveat of parallel processing: it is very hard to build scalability and elasticity into general purpose applications. But if you cannot make multiple nodes share the workload then the cloud will not help you get things done faster.

How can you make your computationally intensive application run in parallel on several nodes? A parallel programmer must address these steps:

Partition the workload into smaller items
Map these onto processors or machines
Communicate between these subtasks
Synchronize between subtasks as required

Note that synchronization is a real bugger – because it is anathema to parallelism. Yet it is unavoidable in most applications.

Shift of Programming Model

Even with the use of toolkits that offer communication and synchronization primitives (such as PMI) parallel programming is a bit like rocket science. Without a shift in programming model parallel programming will stay elusive. Programmers will have to deal with parallelism to some degree at least – they can no longer rely on middleware, databases and operating systems to exploit parallelism.

Chris Haddad mentions the following programming model shifts that happen with the cloud:

Actor Model: Dispatching and scheduling instead of direct invocation Queues and asynchronous interactions
RESTful interactions Message passing instead of function calls or shared memory
Eventual consistency instead of ACID

Fortunately, parallel programming has been a research topic for some decades already – long before the cloud existed. Demand for high performance computation stemmed from various domains, such as weather prediction, finite element simulation and other data analysis. During my PhD I worked on object-oriented parallel programming using COTS (commercial-off-the-shelf) workstation clusters. These are called distributed memory machines in parallelism jargon. The cloud is nothing else than a distributed memory machine - albeit at a much larger scale. And my work also touched the Actor model that Chris mentioned.

Watch this space

The principles and models that apply to distributed memory machines would also apply to the cloud (essentially, the cloud is a very large distributed memory machine). In a follow-up series of posts I will look at those topics in more detail and examine how they can be applied to Cloud Parallel Processing. I’ll dig deeper into programming models shifts (such as Actors) and outline some parallel algorithms (such as map reduce, n-body and others of the 13 computational dwarfs).

Welcome to Giovanni Scheepers - Asset Liability Management for SOA

2010-10-08T23:25:00.000+02:00

Welcome to the Blogosphere to Giovanni Scheepers! Am looking forward to a good discussion and espeically looking at your idea of asset liability management in the context of SOA. Am very excited!

Offroad Google

2010-08-22T23:38:00.000+02:00

While mountain-biking in the Swiss alps we met this man recently. What looked like an ice cream bike from the back turns out to be an e-bike with Google equipment mounted. I'm really curious to see these pix show up on Google street view (or trail view).

SOA Symposium 2010 in Berlin - CFP

2010-06-12T23:10:00.001+02:00

The SOA Symposium 2010 is taking place in Berlin this year. The Call for Papers is open until June 30. Themes and topics this year:

Exploring
Modern Service Technologies & Practices

• Service Architecture & Service Engineering

• Service Governance & Scalability

• SOA Case Studies & Strategic Planning

• REST Service Design & RESTful SOA

• Service Security & Policies

• Semantic Services & Patterns

• Service Modeling & BPM

Scaling
Your Business & Infrastructure Into the Cloud

• The Latest Cloud Technology Innovation

• Building and Working with Cloud-Based Services

• Cloud Computing Business Strategies

• Case Studies & Business Models

• Understanding SOA & Cloud Computing

• Cloud-based Infrastructure & Products

SOA Forum 2010 - Asset-based SOA

2010-06-11T13:36:00.000+02:00

A total of 203 attendees met at the annual SOA Forum in Zürich last week. The pre-conference day was made up of four half-day sessions around the topics of SOA Security, BPM, Business Service Modelling and SOA Testing. 175 attendees came for the conference main day. The topic of this year's event was the industrialization of SOA based on reusabel assets.

As keynote speaker Massimo Pezzini of Garnter pointed out: assets come in many flavours. They can be infrastructure (SOA backplane), documentation, process templates, organizational templates, skills ... and people! Massimo differentiated three different SOA-flavours: RPC, WOA (request-driven, REST) and Event-driven SOA.

Keynote speaker Anne Thomas Manes talked about the reincarnation of SOA. 18 months ago Anne published a eulogy on SOA. This eulogy wasn't praise more than lamentation at the demise of a promising development - that met it's untimely dead because of hype and wrong application. A talent wasted?

Well - SOA's resurrection happened. Although the connotation here is somewhat religious. Anne suggests to avoid all religious and fundamentalist mindsets when applying technology and architecture. SOA is a logical choice and sine-qua-non for many problems. But it's not a panacea. An opinion that was reflected in the panel discussion.

The wrong approach to SOA - according to Anne - consisted of too strong a technology focus (ESBs, appliances, WS-stacks, governance tools and so on) and too little focus on architecture. Frequently systems were built with an integration mindset which is akin to putting lipstick on a pig (Anne has a lovely picture in her slidedeck). Ultimately this led to high maintenance costs. According to her figures the development of a system is only 7-15% of the TCO - the rest is maintenance. IT budget cuts mean that innovation comes to a screeching halt because there is not much opportunity to reduce maintenance costs.

The reincarnation of SOA consists of seeing the big picture rather than technologies and point solutions. She recommends to learn from the Web 2.0 technologies and help enterprise software break out from the firewall. Externalization, consumerization and democratization of IT are the keywords here. A sentiment echoed by Zapthink and others.

SOA's reincarnation is driven by the application of design principles and architecture instead of focussing on technology. SOA principles are applied through:

When these principles are applied correctly a system should exhibit the following characteristics:

Modular
Distributable
Discoverable
Swappable
Shareable

The SOA Forum presentations can be accessed under the following URI:

www.ipt.ch/downloads

Username: soaforum_main

Passwort: assets

ESB Book - New Cover

2009-06-19T12:24:00.003+02:00

The book "Modern ESB Architecture for SOA" I am writing together with Mark and Arnaud now has a new and final cover.

SOA Forum 2009 is history

2009-05-15T22:43:00.003+02:00

On Wednesday the SOA Forum 2009 (http://www.soa-forum.ch) came to an end. We had a spectacular crowd of 175 attendants. Below are the slides that I presented in Track 2 together with Martin Kräuchi:

End-of-time Prophecies on Middleware, SOA, ESB and else

2009-05-09T23:35:00.009+02:00

When Nostradamus pronounced and published his famous prophecies in the 16th century he did not need to worry about target consumer categories. His predictions - some of them interpreted as end-of-time prophecies or just plagues, earthquakes, etc. - where all-encompassing. Unfortunately, none of his writing was ever interpreted as predicting an event before it actually ocurred. :-)

So, what about those target consumer categories? I came across these when reading an excellent article by Steve Vinoski with the title "Is Middleware Dead? (IEEE Internet Computing, vol. 8, no. 4, 2004, pp. 94-96). This article is also about predictions -- in the technology and market domain this time.

Steve Vinoski wrote this article in response to "The End of Middleware", where Jonathan Schwartz of Sun touted middleware to be dead. The assumption behind this pronounciation: everybody would use Sun's Java Enterprise System then there would be no need to integrate with other middlewares. Of course, it did not pan out this way.

Similar pronouncements about the death of CORBA, SOA, ESB and many other technologies have been made. Steve points out that such predictions frequently do not take the target consumer category into account. According to Crossing the Chasm, there are five such categories in a technology adoption lifecycle (- innovators, - early adopters, - early majority, - late majority, - laggards).

When an "early adopter" feels that a certain technology is dead -- it may be alive and kicking from the point of view of the "laggard". One-size-fits-all solutions are therefore impossible. Where are ESBs on that adoption bell curve? Pretty much at (or slightly after) the peak, I'd say.

Stateful vs. Stateless Services

2009-05-06T12:37:00.004+02:00

From a runtime point of view it is advantageous to have stateless services. Statelessness - from a conceptual point of view -- means that the service does not "remember" state between consecutive invocations. Of course, the service may still store information in the DB backend. The important point, however, is that this state is not within the service instance or the service volatile memory.

Clearly, stateless services do scale better: Additional instances of the service can be fired up to cope with increased load. They can also deal better with failover situations. A client request may be routed to an alternative instance transparently when the original instance goes down.

However, sometimes stateful services do make sense from a modelling perspective. Nicolai Josuttis, for example, describes a shopping cart service. For this type of service, a client would expect to successively call operations to add new items.

A stateful service may be implemented as a stateless service: either by sending all relevant information (eg the shopping cart contents) with every request or by sending a session ID with every request and keeping the shopping cart contents in the DB. Or a "real" stateful service keeps the shopping cart state in memory - this requires session affinity: ie, each successive request by a given client must be routed to the same service instance. When this instance goes down, the user must start their shopping trip all over again -- possibly an acceptable tradeoff in an eCommerce application. Nicolai Josuttis works out the associated tradeoffs (state in frontend, state in service, state in backend) really nicely in his book (p.195).

Oracle aims for a Slice of Cake

2009-04-28T08:47:00.008+02:00

Frank Martin of Oracle quipped that after the takeover of Sun, Planets and Moon might follow soon. Meanwhile, The Economist had another very good high-level story about the Sun takeover by Oracle titled "Mr Ellison helps himself". Great analysis with the conclusion that our industry is going from horizonal/modular to vertical/integrated with the Sun acquisition being just one indicator of the overall trend. The cake (market) is more segmented into slices than into layers. This has significant repercussions regarding the IT value chain that all players wil need to adapt to.

Message-Driven SOA = Robustness

2009-04-27T16:33:00.005+02:00

I love Bill Poole's blog - In a post last year, Bill describes a service model that is built around cohesive business areas/capabilities and along the following principles: large grain services; asynchronous reliable communication; no centralized data; no cross-service transactions.

In the past I've worked as architect on an eGovernment project that followed just these same architectural principles. That was by design and also by necessity -- since the underlying product (SonicESB) naturally guided developers into modelling services as entities with a purely message-oriented interface (of course, that was putting the horse before the cart). Services in SonicESB aren't really services in the conventional sense -- they are written against an API and can communicate with other Sonic services only using that API. The API binds onto a JMS abstraction layer that exercises the underlying MOM implementation. However, some queues that drive services may be exposed via Web service interfaces to the external world. Sonic also offers a light-weight process construct: itinerary-based routing includes a routing slip with every message and describes which queues/services must be traversed in what order.

The project team really bought into the benefits of temporal decoupling and came to see it as godsend -- they also came to accept the unusual asynchronous communication style that goes with it.

individual service may be taken down for maintenance without negatively affecting the rest of the system -- messages simply get buffered until the service comes up again
as a corollary to the above: services do not need to handle peak loads -- just the average load. When bursts of messages arrive they are simply backlogged in the queue until the service can process them.
non-blocking for the message producer: fire-and-forget with reliable messages; producers "know" that messages eventually arrive - SLA of the recipient is can help in giving a deterministic timeframe
monitoring of queues: analyze queue utilization over time; detect usage patterns and adapt to and/or predict load situations;
inspection of in-flight messages: analysis of messages; remove and store individual messages; replay them at a later stage (or for testing); isolate poison messages and use them for failure analysis

While this particular system was built on top of Sonic, the general principles can be carried over onto any technology that supports reliable asynchronous messaging. Examples are JMS, AMQP, XMPP, WS-Notification, and others. The problem here is: how do you schema-describe your messages? This can be done by out-of-bounds mechanisms, albeit unsatisfactorily.

Virtualization at the Endpoint?

2009-04-23T11:25:00.006+02:00

Aaron Skonnard describes the Microsoft Managed Services Engine (MSE) over at MSDN.

Service virtualization is nothing new, of course - it's a pattern that underlies most SOA middleware products (ESBs) and agents (Actional, AmberPoint,..). Hosting platforms (WCF, App Servers) also provide rudimentary virtualization on top of the business logic.

The strength of virtualization lies in its power to isolate consumer and provider and decouple them -- more so than what would be possible if they interacted directly (somebody once said - not without irony - that "any problem can be solved by another layer of indirection" - was it an R. Johnson?). This shields a service developer from the requirements of the consumer and allows her to focus on business logic -- rather than getting multiple stakeholders to agree on the non-functional aspects of the service interface.

ESBs place service virtualization "in the middle" - the MSE that Aaron Skonnard describes places it at the endpoint. Endpoint-based virtualization is becoming a new trend. WCF does it and some other containers - to a limited degree. Some LOB packaged applications start to offer this functionality at the endpoint (e.g., Siebel with the inclusion of Fusion Middleware). This is also in support of pure SOAP architectures that describe the enterprise as just a collection of SOAP-speaking endpoints (with reliability, security, etc. all being controlled through WS* protocols).

Virtualization at the endpoint, however, is not equivalent to virtualization in the middle. It limits you to those aspects of a communication that occur -- well, at the endpoint -- just before hitting the business logic. All aspects that are more centralized conceptually, are more difficult to address. Think about location transparency, for example. If this aspect is implemented on a central, shared intermediation layer it is simple to move backend service providers to new locations. If there is no such infrastructure, then every consumer must be able to directly address the provider endpoint. Either you configure these addresses in peer-to-peer fashion (which is a mess) or you do some kind of lookup: this could be via DNS (only works with HTTP), a registry or a centralized resolver service. The two latter solutions require that the consumer endpoint (either the stack or the business logic) handles the address resolution.

Then, think about content-based routing -- and things get more difficult. This would be a functionality that the consumer endpoint would provide -- or an intermediate infrastructure service. Other examples for virtualization/intermediation requirements taht map more easily onto a (conceptuall) centralized implementation, rather than onto a set of distributed smart endpoints:

messaging patterns (pub/sub, reliable, async) - reliable queueing can be done at the endpoint but it's a maintenance nightmare (think trapped messages, poison messages, ...)
complex event processing - for correlation/pattern detection, all events must be brought together at the event correlation engine for the application of rules
message routing (addressing, CBR) - as mentioned above
layered security defense - combination of multiple security mechanisms where threats are filtered out at multiple policy enforcement points (PEP) along the communication path
control point for runtime governance (can you really rely on your distributed containers?) - to some degree, since you can monitor messages in progress, but not the availability of services that are not in use
Provididing multiple interfaces to different clients at different network locations - maybe you only want to make a certain "engineered" interface (different operations, different policies) available to another department, DMZ-external, etc.

The following diagram gives a conceptual idea of where intermediation/virtualization can take place when looking at the consumer-provider communication path:

Developer Summit 2009 - Stockholm

2009-03-13T13:34:00.007+01:00

I'll be speaking together with Herbjörn Wilhelmsen at the Developer Summit 2009 in Stockholm about How to Survive the Bermuda Triangle of Legacy, Services and ESB.
Developer Summit, Scandinavia’s leading developer conference is turning 5 years! This year 40 sessions on 6 tracks, key-notes and workshops are planned.

SOA Forum Schweiz 2009

2009-02-15T13:43:00.003+01:00

The SOA Forum 2009 will take place May 12-13 in Zurich Sihlcity's cinema mediaplex. The motto this year: "Beyond the hype and theoretical discussions. Use SOA right – succeed in practice”.

Be sure to mark the date in your calendars! We'll have some really interesting and controversial keynote speakers at the start this year - wrapped up with a panel discussion.

Thomas Erl: "Next Generation SOA"
Anne Thomas Manes (Burton): “What Becomes of SOA During Though Economic Times?”
Michael von Uechtritz (Gartner): final keynote

I'll do a talk on mediation strategies in SOA and have a look at a SOA reference architecture.

SOA-ESB book page & interview

2009-02-04T11:53:00.004+01:00

Thanks to Thomas Erl for just setting up this brand-new page on the upcoming ESB Architecture for SOA book. There is an associated audio podcast on InformIT where Joe McKendrick interviews Mark Little and myself about some of the ESB-related patterns that made it into the SOA design patterns book.

SOA Design Patterns book released

2009-01-20T09:53:00.001+01:00

The SOA Design Patterns book is now released. Mark has the details.

Zotero

2009-01-06T22:51:00.003+01:00

In the past I've used various bibliography tools, such as EndNote (when on Word) and BibTex (when on LaTeX). Eventually, however, I've found bibliography heaven - a tool called Zotero. It's free, open-source and integrates nicely with Firefox. The more I use it the more I come to like it.

Steve Jones on the Business Service Bus (BSB)

2009-01-05T22:24:00.010+01:00

I've read the post about Business Service Buses (BSB) by Steve Jones and the associated GoogleDoc with interest. Steve describes how a enterprise-wide BSB mediates multiple lowever-level and more domain-specific buses (DSB). I've seen such a model (I call it "hierarchical ESB topology") used in practice by at least one client.

pro arguments:

divide and conquer philosophy: hide and package structural complexity, only expose services to the upper level that are required there -- hide domain-internal services
the bus infrastructure effectively models the organizational structure
distributed governance -- i.e., each business unit can manage and control governance according to its particular requirements (also see the IBM article Choose an ESB topology to fit your business model)

cons:

extra complexity ("middleware for your middleware")
heterogeneous technology mix - leads to duplicate license costs, operational & maintenance costs

An alternative?
An alternative to the hierarchical ESB topology that Steve proposes would be the "intermediary layer" pattern: Only the business-unit or domain-specific services are encapsulated by an ESB or other type of intermediation layer (legacy wrappers or adapters, domain-specific intermediation services, XML appliances, etc.). This intermediation layer is necessary so that a standard SOAP + WS* protocol can be exposed to the upper level.

Instead of using the BSB one would then rely on the SOAP stack plus the advanced WS-standards to govern the reliability, security, availability, location, routing and other non-functional aspects of the message exchange. The endpoints exposed by the different intermediary layers would also need to agree on messaging patterns and on data formats (see www.soapatterns.org: canonical schema (158)).

I've modified Steve's diagram and replaced the BS with "SOAP and WS*" so that it looks like this:

Now I'd be really curious: what are the pros and cons of this alternative model compared to the original hierarchical topology pattern?

Meeting Herbjörn

2008-12-31T16:36:00.003+01:00

Herbjörn and I met up in Sala yesterday. What great fun exploring the cafes of town and eating some very authentic Swedish food called pytt-i-pannan and discussing ideas for our article and book authoring activities.

Herbjörn also recommended two books which I shall read soon:

Domain Driven Design by Eric Evans
Enterprise SOA Adoption Strategies by Steve Jones (CTO of Cap Gemini) -- this book is available online after registration on innoq.

New Gartner Magic Quadrants

2008-12-22T08:19:00.011+01:00

Gartner has just published new magic quadrants for the SOA/integration application infrastructure. They divide them into three different markets - although some products by the big-name vendors fall into multiple categories:

New Systematic SOA Application Projects - this market represents the grand, all-encompassing SOA suites, which - in a way - contradict the "best-of-breed" appraoch that most SOA advocates propagate. These products are positioned as overarching, complete SOA stacks. Integration is less of a requirement in this category than modeling and design, service implementation (from scratch), UI and orchestration/BPM.Gartner sees IBM WPS and Portal, Oracle Fusion Middleware and Microsoft .net/Azure as leaders -- with the JBoss Enterprise SOA Platform a close call. SAP NetWeaver is considered too ABAP/SAP specific to serve as the basis for a corporate-wide SOA initiative.All the plus points that Oracle can gather (except for BPM) seem to come from the BEA acquisition.
SOA Composite Application Projects - this market covers tools that can deal with a Brownfield situation, where most business logic is preexistent and independently deployed. Gartner defines a composite application as "a software assembly that implements a set of independent but related functions — each meant to be perceived by users as indivisible — and where the component parts are heterogeneous in their information architecture." Integration can occur either at the user-facing logic ("integration at the glass": mashup, (personal) portal and screen scraping, Web scraping) or in the backend (invoking services or the business logic of the backend app directly using a variety of communication protocols, while guaranteeing reliability, scalability, manageability and security). "A composite-application-oriented platform that is narrower in functionality, but also more deeply integrated and less-expensive than general-purpose suites". IBM, Oracle, Tibco, SAP, Software AG (webMethods) and Microsoft are in the leader's quadrant, whereas Red Hat is still considered a niche player here.
Back-End Application Integration Projects - this market came about as the cross-fertilization between EAI, MOM and WS-platform/management products. Its most prominent product representative are ESB platforms. Gartner sees the following drivers in this market: "1) companies expanding their SOA initiatives, 2) the trend of creating services by using existing business logic and data assets and 3) an emerging recognition that there is a huge overlap in the features required to support the deployment of SOA-based applications and those required to support data consistency, multistep process and composite application integration styles". Minimum criteria for membership in this category are: integration services, SOA and BPM support, management, dev environment, B2B, CEP, BAM, data integration. MS, IBM, Oracle, Tibco, Sun and Software AG are in the leader's quadrant again; Progress, Red Hat and surprinsingly -- good old Fiorano -- are kicking around as visionaries.

The Power of Network Intelligence

2008-12-17T09:45:00.004+01:00

Forbes CIO Magazine ran an interesting article recently titled "Networks aren't just Data Highways" - lamenting the tremendous untapped compute power of the Internet's underlying infrastructure of routers, switches, firewalls, LBs, etc. Since all enterprise relevant information (email, CRM and ERP entries, etc) flows through the network, this is the one place where all data meet

Dan Woods predicts a development of the network towards an integral part of the application with the following tasks:

value added functionality (auditing, monitoring)
policy compliance monitoring (products by SAP, Cisco)
prevention of information leaks, intrusion detection
event mining for business intelligence purpose
devices with intelligence can act as event sources (GPS, RFID, WLAN hubs, user presence, smartcard readers, cameras, etc.)

two new (free) SOA books

2008-11-21T14:18:00.006+01:00

Two new SOA books have just come out recently. Both are available as free PDFs (after registration):

An Implementor’s Guide to Service Oriented Architecture: Seven vendor representatives offer their views on the constituting parts of SOA and best practices. The aspects they examine are service design, registries and repositories, ESBs, runtime management, organizational structures and capability development (team, training). I especially enjoyed the ESB section by Hub Vandervoort of Progress. Hub details different mediation requirements that enterprises have today. He then goes on to demonstrate how these can be addressed with different infrastructure choices, such as ESB.
SOA Adoption for Dummies (courtesy of Software AG): The author liken SOA adoption to a space journey: keep the pointy end of the rocket up until you reach weightlessness. I quite like the view on ESB presented in this book - ESB is only one of a kind of SOA intermediation infrastructure - and it doesn't sit in between consumers and providers tying everything together. Rather it exposes services of different size, smell and colour in a homogeneous fashion to the consumer layer.

Some SOA nerds may squirm after reading the ESB sections in this chapter. If you’re one of them, you may be inclined to have a near-religious belief in the classical view of ESB. In the classical view, an ESB is a critical piece of SOA infrastructure that sits between service providers and consumers. The services themselves are not hosted on the bus. We also strongly believe in the need for such infrastructure and address it in the later section “Understanding Service Mediation,” but we don’t believe that only products with an ESB label have a special right to be that piece of infrastructure.

I also like the following statement on the need for an intermediation layer in an SOA in order to increase flexibility and loose coupling:

In order to achieve maximum flexibility in your SOA, service consumers should never connect directly to the service implementations in the service-enablement layer. Instead, they should connect to the service interface hosted in a separate service-mediation layer.

Microsoft ESB Guidance v 2.0 out

2008-11-16T16:18:00.001+01:00

Congratulations to Dmitri Ossipov and his team. They've just released version 2.0 of the Microsoft ESB Guidance.

MSDN site: http://msdn.microsoft.com/esb
Community Extensions: http://codeplex.com/esb

From Adlai Maschiachs MS blog:

The Microsoft ESB Guidance provides architectural guidance, patterns, practices, and a set of BizTalk Server and .NET components to simplify the development of an Enterprise Service Bus (ESB) on the Microsoft platform and to allow Microsoft customers to extend their own messaging and integration solutions. The Microsoft ESB Guidance consists of a series of interoperating components that support and implement a loosely coupled messaging environment that makes it easier to build message-based enterprise applications. The services and components fall naturally into the following seven categories:

Web services. These expose internal services such as itinerary processing, exception management, resolution of endpoints and maps, BizTalk operations, UDDI interoperation, and transformation of message content.
Itinerary services and centralized store. These include agents for performing transformations and message delivery. You can resolve itinerary from the store and create custom services that participate in Itinerary processing.
Itinerary on-ramps. These receive external messages using either SOAP or WCF. On-ramps expose the itinerary SOAP header and perform itinerary processing, using the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
On-ramps. These receive external messages in a range of formats and transports, such as HTTP, JMS, WMQ, FTP, Flat File, and XML. They are typical BizTalk receive locations that optionally use the Microsoft ESB Guidance pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
Off-ramps. These implement send ports for the delivery of messages using formats and transports such as SOAP, WCF, JMS, WMQ, FTP, HTTP, Flat File, XML, or any other custom formats. They are typical BizTalk send ports that optionally use the Microsoft ESB Guidance pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
Exception Management Framework. This includes the exception Web service, the exception management API, and components that enrich, process, and pass exception details to the ESB Management Portal.
ESB Management Portal. This provides registry provisioning, exception mediation, alert notification, and analytics.

SOA Symposium 2008

2008-09-23T13:26:00.003+02:00

Early next month I'll at the SOA Symposium 2008 in Amsterdam, presenting two talks on the topic of ESB. My friend Jim calls them "enterprise manboobs" in his hilarious talk.

Stolen Bike

2006-09-27T21:37:00.000+02:00

When coming back from the US last Sunday I was informed by police that a burglary had had happened at my house. Agony: my mountain bike had been stolen! I'm gutted, especially because I had never expected anything like this to happen in Bern and the bike was not yet 6 months old and lovely!

Here are the details, please look out for it:

Colour: Black/Carbon, Yellow
Model: Scott Genius RC10
Frame Nr: TM34120097

ICWS/SCC 2006 Chicago

2006-09-20T22:38:00.000+02:00

In Chicago for the IEEE ICWS 2006 Conference: Arnaud and I are presenting a paper on the topic of service contracts. We demonstrate how a "service contract template" can help to express concerns that go beyond WSDL.

Interesting chats with Ali Arsanjani about his work of using rule evaluation to take service authorization decisions based on a client's call context.

Chat with Tony Shan about high-performance messaging.

Talk by William R. Cook about Web Service vs. Distributed Objects.

The team from Newcastle Uni won the SCC06 Service Computing Contest - congratulations!

Chicago ist eine tolle Stadt – so viel Kultur und Abwechslung und schöne Lage am Lake Michigan, der durch seine Grösse wie das Meer wirkt, nur eben Süsswasser.

Am Wasser entlang führt ein 17-mile Walk, viele Radfahrer, Rollerblader, Jogger dort unterwegs. Unser Hotel ist nur zwei Blocks davon entfernt, also waren Arnaud und ich gestern abend dort joggen: schöne Stimmung mit Sonnenuntergang über dem Hochhausmeer, Reflektionen von gleissenden Sonnenabbildern in den Fassaden, rosagefärbte Woken über Lake Michigan. Danach Indisches Restaurant (ausgezeichnet!) und hoch in den 95. Stock des John Hancock Towers. Auf 300m Höhe eine Bar, stockwerkhohe Fenster über die ganze Fassadenbreite verteile. Es eröffnet sich ein überwältigender Blick über die Stadt, in unmittelbarer Nähe weiter Wolkenkratzer (die plötzlich klein erscheinen) und bis zum Horizont zeichnen sich die Planquadrate der Stadt ab, die Hauptverkehrsachsen, man könnte stundenlang gucken und staunen. Auf den Handybildern erscheint das unscharf, aber tatsächlich sieht man feinste Details.

Hotel ist direkt an der Magnificent Mile – sozusagen die Chicago High Street. Hier ist alles was Rang und Namen hat mit einem Signature Shop vertreten. Leider nicht genügend Zeit zum Shoppen: Weil die Konferenz in einem doofen Airport Hotel stattfindet müssen wir täglich 2x1h pendeln!

Seattle

2006-09-16T22:00:00.000+02:00

Ich bin hier bei Savas zu Besuch, einem alten Newcaste-Freund, bevor es dann für eine weitere Woche nach Chicago geht.

Schon ein paar erkundungstouren hinter mir. Ganz hübsch war der pike place market, ein gedeckter markt mit fisch, gemüse, blumen, honig, schmuck, nippes ... ähnlich grainger market in newcastle. Dann weiter über die hillclimb stairs zum hafen. Leider geht entlang der gesamten waterfront ein zweistöckiger expressway über brücken; lärm, gestank, sieht aus wie eine grosse Zahnspange vor der Stadt. Der blick über puget sound dafür sehr schön: in der ferne sieht man mehrere inseln, berge, interessante wolkenbilder. Seattle ist von puget sound und west lake im inland zu einer art sanduhr-form zusammengeschnürt. Sehr gut sieht man das vom Observation Deck der Space Needle auf 200m Höhe. Unglaublich viel wasser rundherum und nationalparks, berge, meer. Gute lebensqualiltät wenn man es sich leisten kann, aber man merkt auch dass man in amerika ist: überall eine verschwendung von energie, schrecklicher verkehr, armut, bettler. Eine strassenüberquerung zu fuss kann zum abenteuer werden.

Als ich dann genug hatte von der stadt bin ich mit der fähre auf bainbridge island gefahren. Nett, provincial, quaint dort. Die überfahrt dauert 40 minuten incl. toller blicke auf die seattle skyline. Drüben ein nettes küstendörfchen mit vielen "antiques stores", seafood, naherholungsgebiet eben.

Savas Freundin Cherie arbeitet als Fitness-Trainerin (und macht nebenbei einen PhD in Comp-Lit). Mit ihr war ich gestern auf einer Thaibo Session und zusammen waren wir ein paar Mal Karaoke-Singen (my world first). Savas wohnt gleich neben der Space Needle, dem wahrzeichen von seattle. In der unmittelbaren Umgebung gibt es einige klasse Restaurants (vor allem seafood, sushi – klar gleich am Meer). Ein anderes Wahrzeichen ist der Microsoft Campus -- Dort war ich am Donnerstag zum Lunch mit Dave, einem ehemaligen Arjuna-Kollegen aus Newcastle. Der Blick in die brodelnden Küchen, wo die nächsten Windows- und Officeversionne hergestellt werden, ist aufschlussreich. Basketballkörbe, Tischtennis, Billard, T-Shirts, schlapprige Hosen trifft man dort an: es geht sehr locker zu.

Zu meinem Geburtstag waren wir dann heute morgen noch in einem Seafood-Restaurant (Salty's) mit Blick auf die Skyline. Buffet: Krebse, Krabben, Austern, Hummer bis zum Abwinken. Highlight: der chocolate fountain sprudelte warme Schokolade aus und man kann seine Erdbeeren, etc. mit einem süssen Überguss versehen -- klasse Geburtstag also.

Ski Tour Turtmann

2006-04-02T16:20:00.000+02:00

My ski tour in the Swiss Alps was unfortunately marred by bad weather and high avalanche risk. In the end we had to quit early--the mountain guide didn’t feel it safe to proceed as originally planned to Tracuithütte and Bishorn (which is visible in the distance on the left).

So we were stuck for three days with bad weather in Turtmannhütte and didn't climb a single summit. Pity that, but a week with lots of fun, nice people and a some great skiing nevertheless. I learned some Swiss games and yet more Swiss-german language gems. Also learned how to build an igloo and how to dig in the avalanche transceiver without being able to recover it again.

Gault Millau

2006-03-18T10:02:00.000+01:00

Thanks to Thomas Meier I got my initiation to haute cuisine last night. I was invited to Fribourg's best restaurant, Le Perolles, which features with 17/20 points in the Gault Millau. What a difference to the usual daily bite :-). It's hard to describe the sensation of tastes and decorations in words, but anyway, here's the menu I devoured:

* * *

Amuse-bouche

* * *

Carpaccio de lapereau du Pays, sa cuisse en gelée aux légumes oubliés

* * *

Coussinnet de St-Jacques aux endives et noix, crème mousseuse de pleurotes

* * *

Filet de rouget barbet doré sur peau, tagliatelle fraîche au curry, petits légumes et moules

* * *

Tournedos de selle de renne en croustille de céleri, fond réduit au vin rouge

* * *

Chariot de fromages

* * *

Rouleau de printemps aux fruits exotiques

* * *

Brownies à la mousse choco-gingembre, tuile au miel, sorbet oranges sanguines

* * *

New Bike

2006-03-17T20:36:00.000+01:00

After looking at full-suspension carbon bikes for a while and having a shortlist (Simplon Stomp, Spezialized Epic, Scott Genius) I eventually stumbled upon a really great offer I could not resist. In Ski and Velo Centre they had a 2005 Scott Genius 10 RC that was marked down considerably from its original retail price because of its previous live as a test bike. The carbon frame tips the scales at a mere 2.1 kg (and that is including the rear suspension). Am really looking forward to riding.

Powder Weekend

2006-02-13T00:26:00.000+01:00

Last weekend was full of ski-touring (.. backcountry-skiing -- what's the proper term?). Saturday afternoon it was a quick trip to Laseberg (1910m) close to St. Stephan/Simmental.

On Sunday I decided to follow Christophe & Antonella's suggestion of skiing Gemmenalphorn. Initially, when reaching the Northern shore of Lake Thun, I regretted this decision very much: The warm micro-climate around Beatenbucht means that there wasn't a single flake of snow, but instead spring-like temperatures and palm trees growing happily. Getting off the bus I felt a little inadequate with anorak and ski equipment.

What a surprise then to find 20 cm powder on the top of Niederhorn (1950m) shortly after, accompanied by magificent views across Lake Thun. I made the first tracks down towards Unterburgfeld, then climbed up 500m to Burgfeldstand (2063m) for a final ski run to the little village of Habkern from where a postal service runs to Interlaken.

Sonic Synergy TechDays Cologne

2006-01-28T00:58:00.000+01:00

I'm just back from the presentation of Sonic's new product suite (Sonic Workbench 7.0) which took place in Cologne 26/27 January). Here's a summary of what's the new product features and some critical comments (in italics).

Whitepapers

SOA Maturity Model

5-step layered pyramid, similar to CMMI

ESB covers levels 2-3

Levels 4-5 are addressed through acquisitions:

Apama ESP & Dashboard,
Actional Looking Glas & SOAPStation.

Architecture/Positioning

ESB vs WS*: How relevant is ESB in the context of maturing WS*-standards?

Mother Russia

2005-11-02T17:32:00.000+01:00

Russia 2005

what an amazing country -- how many surprises -- and how many stereotypes that i carried around and had to adjust. Most of all impressed me the extremely friendly people; such a difference to the rude folk you meet at the russian embassies. then the rich cultural heritage and the strong european influence (and cross-weaving). there was so much cross-fertilization: e.g. napoleon - aleksander II, voltaire, josephine (napoleon's wife) - kathrine the great. peter the great studying in holland and italy, etc ....amazing all this history! all this certainly awakened my taste buds and i'd love to go and explore more of this beautiful country in the future. e.g. the provinces further east of Moscow, etc ....

ST PETERSBURG

Dostojewski Haus (crime & punishment)

Eremitage: Da vinci?? Madonnas …?

Peter & Paul Fortress: the fortress was the first building in St P. constructed and designed 1703 by Peter the Great. The original timber construction was over the next few years replaced by a stone building. Under the protection of the fortress the town rapidly developed. Never used as a fortress, but served over two centuries as the country’s main political prison: Tsarevitch Alexey, son of Peter I who was against the policies of his father was incarcerated here. And princess Tarakanova who claimed to ascend the throne died a horrible death (see paintings) when the prison was flooded by the Neva.

Cathedral of Peter & Paul: The golden angel on top of the spire is said to watch over St. Petersburg. Served as a royal burial vault: Peter the Great, Alexander II. The last Russian Tsar Nicolas II and Alexandra Fedorovna + their children and servants (the Romanovs). ???

Princess Tarakanova:

Claimed to be Elizabeth’s daughter

Seduced by count Orlov, Kathrine the Great’s lover who secuded her to come with him from Paris?? To St. P and on the ship imprisoned her.

Peter the Great – 2m tall, traveled incognito to many European countries, e.g., studied shipbuilding in Holland; big modernizer of Russia

Cathedral – architect was chopped off his hands

Tsarskoye Selo (literary - "tsar's village") – Pushkin:

Preferred palace of Catherine the Great

Lyceum where Pushkin studied

Great damage during WWII – the Nazis dismantled the Amber Room which mysteriously disappeared after the war. Sunk with the Wilhelm Gustloff? The reconstruction opened in 2003.

Saviour of the Blood Cathedral :

Built on the site where Alexander II was assassinated 1 March 1881. the original part of canal fencing and cobblestones is still visible in the middle of the church. Built 1883-1903.

Archangels in orthodox churches: Gabriel with 8 wings symmetrically attached to a bodyless, cherub-like pink face.

Gipsy taxis: riding at 120km/h through Moscow! Lots of traffic accidents at night. Overturned cars, head-on collisions with Mercedes and all airbags deployed.

Smolny Cathedral and monastery: Built by Elizabeth, dauger of Peter the Great.

Like many other churches used as a storehouse during communist times.

Alexander Nevsky Monastery:

- Tikhvin Cemetery: Dostoevsky, Mussorgsky, Rimski-Korsakov

Kaviar & Vodka & champagne :

Swan Lake Ballet:

Bridge Opening Neva:

St Isaac Cathedral: like St Peter’s in ROme

Plattenbauten: in the 50s/60s super: running warm water, heating, bath rooms

Kunstkammer:

Lomonossow Museum; first observatory of Russia; Riesenglobus: transport from Germany; first in Peterhof

Curiosity collection of peter the great: aborted fetuses, grim!

Nevsky Prospect

Peterhof:

Conceived by peter the great in 1714 he took an active role in the construction and design of the palace (incl. intricate details of the architecture and of the fountains).

100s of remaining

Russian Hydrofoil

Sea canal – like mirror pond in Versailles but oppeninig out onto the sea

Monplaisir

Practical jokes: hidden water jets in trees and in the ground.

100s of fountains

Samson fountain with the spewing lion is a monument to the Russian victory over the Swedes in 1709. Its symbols can be easily interpreted as the lion was depicted on the coats of arm of Sweden and Peter the Great was often compared with Biblical Samson. This victory was significant as it opened naval access to the Baltic sea (“window to Europe”) and was the beginning of the royal Russian navy.

Lots of reconstruction work necessary after WWII.

MOSCOW

Metro:

Gorki Park

Gorki Leninskije :

- Lenin Statue und originalappartments from Kremlin ; brought here by Yeltsin

Jaroslavl:

Madame Butterfly (Puccini) in Bolshoi Theatre.

Torquato tasso: tankred & Herminia

Kremlin:

Jonah and the Whale

Stalin-gothic skyscrapers (The Seven Sisters): Kotelnecheskaya appartments is one of seven Stalinist-Gothic towers that were built just after WW2. The architects used a "wedding-cake style" construction, to give each building a sense of "upward surge" toward a central tower. Built by POWs, it is said that when prisoners expired while working on site, their bodies were immured!

The towers owe their design to a monumental building that was never built, the Palace of Soviets. Starting in the early 1930s, planning competitions were held for the proposed 1,410-foot-high structure, which was intended to stand on the banks of the Moscow River where Stalin had destroyed the Cathedral of Christ the Savior in 1931. But despite 25 years of plans and revisions, the gigantic palace never materialized. On the same site today, Moscow Mayor Yuri Luzhkov rebuilt the original cathedral. ( In between swimming pool!)

Testing Outside the Container

2005-09-27T12:48:00.000+02:00

At JavaOne I've heard a talk by Jim D'Ambrosio on the problems of EJB testing. Frequently, unit testing is done after deployment onto an application server which creates a set of nuisances:

configuration and setup is time-consuming
debugging is complicated (remote debugging)
Too much time waiting for the server to start
Bugs in other areas slow you down

Jim concludes that it is better to unit test EJBs outside of the application server. For this purpose, mock objects can simulate the EJB container's runtime environment. EJBs are unit tested as plain Java objects. This should make developer's lives easier and more productive (see the article Streamlining Your EJB Tests With MockEJB).

These arguments are equally true for ESB service development! Deploying service types into an ESB container before unit testing them makes the development process slow and complicates debugging. Mock objects to the rescue! One problem remains though: there are no off-the-shelf mock object libraries for ESB containers. ESBs are still less wide-spread and there's no standardised API yet for ESB service implementations.

In my current project we are working with the Sonic ESB container. Given the lack of mock libraries for this container, we just built one ourselves. We are now in a position to simulate the Sonic ESB Service Container and therefore greatly improved our development lifecycles and code quality.

Because there’s no time required to start up the container (and no resources consumed), this streamlines testing -- a fact that makes test-driven development feasible. Since services are tested in isolation, there’s no dependency on other system components. Sometimes we test several services within one unit test when they act as counterparts of each other (e.g. FileDropServices/FilePollServices, FTPPut/FTPGet).

However, this approach is no panacea for developer woes: Integration testing must still be done on the container.

IBM entering ESB market

2005-09-18T12:16:00.000+02:00

Two articles on IBM's latest ESB strategy announcements:

IBM trots out muscle-bound SOA
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1124772,00.html

ESB Guru Dave Chappell Welcomes IBM's Big SOA-Related Push
http://webservices.sys-con.com/read/129795.htm

In this article Dave calls IBM's current product offering a "Sargasso Sea" of components.

Enterprise Service Buses Hit the Road

2005-08-24T23:10:00.000+02:00

Just noticed via Ramesh that InfoWeek has a comparison of different ESB products in its latest issue.

Bern under water

2005-08-24T22:33:00.000+02:00

Have been through Bern on the bike this afternoon: The damage on the Matte quartier is huge. From the safety of the high level bridge I watched in awe with other "disaster tourists". Draft wood blocked off one of the normal water passage ways, so the flood took another route: straight along the Matte main road! All 1.100 inhabitants of the Matte area have been evacuated from their houses -- some by force.

The water is still 1-2 metres high and there's a very strong current (20km/h?). I saw one house where water came in through the front and came out gushing through the rear. It looked like this house had been built bang in the middle of a torrential river! Lots of cars totally submerged with only the antenna sticking out of the water – some of them badly damaged and with the roof torn off (wonder how this happened?).

Bern Matte Film 1
Bern Matte Film 2

Java Business Integration (JBI)

2005-08-23T01:00:00.000+02:00

For ipt I've given a talk on the topic of JBI recently. The rationale behind JBI is the current lack of standardization on the concept of ESB. Services developed for Sonic cannot be migrated to Iona or BEA. Different vendor’s ESB buses cannot seamlessly be integrated. This seriously hampers the adoption rate of ESBs in their current incarnation. The following statements are maybe a bit cynical, but let’s say I’m playing devil’s advocate:

ESBs are proprietary:
While most ESBs are standards based in their low-level implementation (XML, XSLT, BPEL, etc), they are proprietary at the level where custom services and integration components (such as BPEL engine, XSLT engine, BRE) live. Custom services developed on the basis of one ESB product cannot be migrated to another product without modification. Sonic's service API is incompatible with Iona's or BEA's, for example. Integration components, such as process engine, XSLT engine, BRE are tied to the vendor; no choice is possible. This may be perceived as risking vendor lock-in: who wants to build their enterprise infrastructure on a technology from a single vendor?

Different ESBs are incompatible on the transport level:

Most current ESB implementations are built on JMS. JMS guarantees reliable and guaranteed delivery of messages between components, an important basis for critical business processes. Since the JMS specification does not define a wire protocol, different ESBs are incompatible on the transport level.

On the other hand, it is unrealistic to assume that just a single ESB product will be available or can be deployed enterprise-wide. In most situations there will be variations in the installed software base, possibly as a result of mergers. What happens if external business partners want to join the service network but have invested on a different, incompatible bus? In such situations, interoperability can be established only via message bridges that link together the different ESBs. This can hardly provide the illusion of a seamless ESB service network.

Is JBI the solution?
JBI is out to change all that. JBI doesn't require a J2EE stack. This means that third-party vendors of integration components can plug their wares into the JBI framework even without having a full J2EE stack. Customers can therefore build "their" ESB server using a best-of-breed approach, e.g., take the XSLT engine, a BPEL engine, BRE engine of their choice. These might all come from different vendors who focus on their core strengths. Since components are portable between different JBI implementations, this approach avoids vendor lock-in. Different transport implementations can also be plugged in. This makes incompatible wire protocols much less of an issue.

JBI Overview

Service Engines (SE) from different vendors (e.g., an XSLT engine, BPEL engine, container for custom ESB services) plug into the normalized message router (NMR). The NMR mediates all communication between SEs. If the destination SE happens to be on a foreign host, remote communication is initiated via an appropriate protocol binding component (BC). The BC might provide JMS transport, WS-RM transport, even CORBA or EDIFACT. The meta-container maintains a routing table for this purpose. Proxying of JBI services to remote consumers is transparent at the SE-level.

Disadvantages (or why didn’t IBM and BEA join the initiative?)

Do we still need it or are WS-frameworks sufficient? They don’t see it as a sufficient step forward and believe that the area covered by JBI can equally well or better be addressed with upcoming WS-* Standards.

It is still early days to predict whether JBI will catch on or end up as yet another container architecture. The inceptors’ vision is to see JBI play an important role in enterprise integration as J2EE did/does today for application development. They also envisage the emergence of an ecosystem of pluggable SEs from different (niche-) vendors.

A few articles on JBI:

Biking the Himalayas: Lhasa - Kathmandu

2005-08-18T22:13:00.000+02:00

In October 2002 I did a Bike Trip Lhasa - Kathmandu. This has been a dream for a long time and it was the experience of a lifetime --- well worth all the physical exhaustion! Recently many people have been asking questions on my experiences and recommendations for repeating such an adventure. I've collected a few of the answers in the hope that they're useful to others.

- How hard was the trip (how good does one's physical condition need to be)?
It's hard but absolutely feasible if you are trained and physically fit. Factors to take into account are the altitude, wind, dust in the air (be prepared to wear a dust mask for severeal sections), sun impact, lack of humidity. All these can be compensated for, but you feel what you've been missing on the 4000-m descent back to Nepal!

- Did group members experience severe signs of altitude sickness?
No, just minor

-Over a longer period?
The response is very individual. For some people the symptoms come back with every 500-m climb, for others it's just one/two days upon arrival in Lhasa. I've heard that sometimes people need to fly back again, but it's very rare. I've complemented my diet with iron and vitamin tablets and found this useful.

- What month did you do the trip and how were weather conditions?
October - fine weather - cold at nights (-15 degree Celsius on everest base camp), comfortable temperatures during the day. The support team were fantastic - on the coldest night they even brought us hot-water-bottles into the tent and every morning we were awoken with freshly brewed tea delivered straight to the tent.

- Would you recommend Makalu trekking for this trip?
Absolutely! They were fantastic and I'm still in touch with some of their staff. They are very competent and efficient.

- If you have any knowledge of other organisations offering this tour, how would you compare Makalu to them?
DAV Summit Club is offering a similar trip but I don't know the details.

- Would you travel with Makalu again for similar trips?
yes

- How would you rate the accommodation and the food?
Superb - given the circumstances.

- How would you rate the logistical support?
Excellent - we had one truck and one jeep with us over the whole distance. Food and all supplies were brought in from Nepal in advance to our arrival in lhasa.

- Did you have many problems with your bike? Could the guides help you to fix your problems? What spare parts should we bring?
Bike problems were minor: a few flat tyres and loose bottom bracket. I carried standard replacement parts (inner tubes, tyres, brake and gear cables, plastic click-on pedals for SPD, lube, oil, spokes) and tools (pump, all allen keys for my bike, spoke key, chain tool, etc.) with me. In Tibet it's impossible to get spares! If something breaks en route the only chance is to find a good/creative mechanic/welder in one of the few towns.

- Did you find your bike guide useful or is it also possible to do it without bike guide (only land cruiser support)?
By chance we joined a group led by a bikealpin guide. This was useful, especially since we had fantastic mueslis and sausage flown in from Germany as well as the more bulky tools (e.g., sprocket remover, crank puller) and extra spare parts available.

The SOA Triangle

2005-08-16T23:49:00.000+02:00

Recently I’ve worked on a SOA Readiness Assessment for a client from a data-centric perspective. Some deficiencies I observed there are probably representative of other enterprises with a heterogeneous IT system landscape that has grown organically and was integrated as need arose in an ad-hoc and piece-meal fashion:

Limited Flexibility

mainly batch base file integration between a fragmented system landscape
difficult to implement new services and answer to customer needs in an adequate time

Data Duplication and Inconsistencies

Data assets are stored in a wide array of disparate systems and sources ranging from mainframes to relational databases;
Data is replicated between individual systems that each use disparate databases and directories. Data replication takes place with time delay. Consequently there’s a window of time where conflicting changes to replicated database records can happen. This makes it a challenge to maintain an aequate level of data quality. Manual intervention is frequently necessary.
Every disparate system has its own master dataset. There‘s no clear concept of what information is relevant where at what point in time. Data is fragmented, no unified view of enterprise data exists; in some instances this becomes obvious to the customers (e.g., multiple call centers, letters going to two different addresses).

Unreliable Data Exchange

Risk of losing in-flow information during a crash (ad-hoc and often batch-file-transfer based processes).

To address these issues I came up with a graphical representation that I want to call the "SOA triangle" (not to be confused with the Bermuda triangle -- although you can get lost in both):

Data Access Services (DAS) : A critical foundation and abstraction layer for the access of enterprise information. They isolate both applications/service and underlying datastores/directories from change by acting as a layer of abstraction.

Data Ownership

Role- and area-based access concepts can be implemented based on a multidimensional CRUD matrix
Fine grained access control based e.g., on process-level authentication tokens
Tighter management/operational controls

Encapsulation

Provide a data model that is specific to the operational unit or a process
Shield applications from the complexities, location, access protocols and consistency requirements of underlying enterprise data source
Useful to percolate updates simultaneouosly to multiple backend datastores (see performance/caching later). This improves the consistency/integrity/quality of enterprise data.
Basis for a step-wise enterprise architecture transformation: Applications/services and underlying datastores are not directly dependent on each other. Therefore, applications are isolated from structural changes/merges/etc of underlying datastores. At the same time, applications can be modified to use the new DAS-interfaces without modifying the databases.

Avoid impedance mismatch

The DAS can offer an multiple process- or OU-specific interfaces to the same backend datastore with high level, business-event oriented semantics.
This is more realistic than a unified company-wide data model on which everybody must agree (or face a winner-loser situation with some OUs being forced to use a model that doens‘t fulfil their expectations)

Messaging/ESB : Serves as the SOA Communication Backbone/Infrastructure

Abstract Communication Layer with Virtualised Service Endpoints

–

Avoids "SOA Spaghetti" : Services are connected declaratively. Crosscutting concerns, such as delivery guarantees, security, messaging patterns should not be in the responsibility of services.
Reliable Information Exchange between Disparate Systems: Once-and-only-once semantics guarantee that messages are not lost during machine or network failures.
Asynchronous Communication: Failure of a component in a business process delays the process rather than failing it.
Improved overall system reliability. This is important, because in a complex IT landscape like Cablecom‘s the chances of individual components failing increases exponentially. Store-and-forward means a process can continue once a failed component comes back online.
Different message exchange patterns (point-to-point, publish-subscribe) possible

Straight-Through Processing (STP)

–

Improved agility through harnessing the real-time data that are flowing around the business
Ability to quickly acquire, analyze, and act on both opportunities and issues within the SOA implementation.

Caching : A caching layer can decrease the frequency of interaction with backend data stores.

Performance is of concern in a SOA

DAS require frequent interaction with backend datastores
In addition, services ideally are statless; i.e., services keep their state in persistent storage rather than in-memory (see next slide)

•

This issue can be addressed by software caching:

Products like Times10 offer in-memory replicated reliable caches with persistence guarantees comparable to database.
Physical database access is therefore reduced (since most requests can be served from the cache)
greatly improving data access performance.

Extra Special Bitter

2005-08-15T00:25:00.000+02:00

ESB

- Naturally leads to a document-oriented processing model

- document-oriented vs. RPC: Not separate methods are called, but instead a document is passed around asynchronously between various steps that make up a business process

- Integration on the level of business events (STP) rather than nightly batch file transfers

- Are data services more RPC-oriented, whereas higher-level business services are document-oriented?

- Virtualisation of service endpoints; therefore a more flexible adaptation of business processes. In addition, the connection complexity is reduced to attaching a service to the bus and then defining the message flow declaratively using high-level graphical tools (see screenshot).The ESB mediates all communication between services – services never communicate directly (although such optimisations can be used internally, as e.g., in SonicESB).

- ESB is a distributed system in contrast to the hub-and-spoke architecture of typical EAI-products. This offers advantages in terms of reliability and scalability.

- Because of ist distributed nature, ESB deployment can be Step-by-step.

- Disadvantages: unrealistic that a single ESB product can be rolled out across the enterprise. It’s likely that there will be multiple ESB products installed (e.g., mergers, fragmented IT strategies, organic development)

Message-Oriented Middleware (MOM)

- guaranteed delivery semantics (e.g., exactly-once, at-most-once, best-effort)

- different messaging domains: point-to-point, publish-subscribe

Possible process steps within the ESB

- intelligent message routing based on message contents (content-based routing)

- transformation (XSLT) between different technical formats

- enrichment of data with additional information

- archival of entry data

- access control verification

- logging

- throughput monitoring

- delegation to existing applications or web services

Paragliding "Schnupperkurs"

2005-08-14T22:04:00.000+02:00

A message especially for my mate Jim: Eventually I've done it -- a whole day of paragliding, on my own. Last Saturday I went together with Stefan to Flugschule Diemtigtal where we completed a one-day "schnupperkurs". I came directly from Spicherweid cottage where I stayed the night before with Thomas and his family.

I’d done two tandem flights in the past, but this is the first time that I was on a glider just by myself. The experience was both scary and exciting. Flying 5-10 metres above ground in the flying school was not something I had expected from a beginner’s day! I managed to look stupid with one botched start (landing on my tummy!) and two crash landings.

Our teacher Andy (who’s a test pilot for Thun-based paraglider manufacturer Advance) was excellent and never got out of the calm (despite me constantly ignoring his radio instructions J) --- thanks a lot for a great day!

Altogether it was great fun and hopefully I can repeat it sometime again. On the other hand, I've decided against taking up a full course, because it's too time-consuming for me right now (waiting for the right weather/wind conditions, etc ...), a bit expensive and I'm not convinced about safety. Let's see, maybe I come to another conclusion next year :-)

New MTB

2005-08-06T18:36:00.000+02:00

After riding hardtail bikes for the best part of the last 15 years and fervently disapproving of fullies I've eventually changed my mind. I now believe that the technology is good enough to avoid any bobbing going uphill and the only disadvantage of full suspension is the extra weight and less reliability.
I've been convinced that rear suspension is a great advantage downhill and can even be beneficial on tough uphill sections with very rough surface --- you can pedal more evenly and therefore safe energy. And the rear shock is so much fun that you actually start looking for obstacles! I've gone for the Specialized Epic Marathon 2004 with Fox Terralogic Fork and Brain IQ rear suspension.

Aare Marzili Fun

2005-07-28T19:19:00.000+02:00

It's very hot in Switzerland at the moment -- so for lunchtime I went running along the Aare river but then for the way back couldn't be bothered and just jumped in with my running gear on. Water temperature has reached a record 22"C (live recordings here). Even on a weekday like this hundreds of people are on the river floating downstream. Sometimes the speed is around 15 km/h. great fun!!!

Next plan is to go Waveboarding on the river. I've seen some people do this with home-made boards and elastic ropes attached to the trees. Tension is built up on the rope by drifting downstream (stalling the board against the flow); then they get quite some speed as the rope contracts again. Excellent! Now i just need to find somebody who can teach me how to build one of these ....

WorldWind: Aletsch Glacier

2005-07-28T09:47:00.000+02:00

An amazing satellite image of Aletsch Glacier from WorldWind: Aletsch is the largest glacier in the Alps. It emerges from a giant snow bowl called Konkordiaplatz where three ice streams meet. This bowl is surrounded by the Bernese Oberland's highest mountains: Eiger, Jungfrau, Mönch.

Lake Thun and Lake Brienz are visible in the background. The Aare river emerges from Lake Thun and from which it makes its way to Bern. The city itself is just clipped off the top of the image.

JUnit Testing von Sonic ESB Services

2005-07-26T18:08:00.000+02:00

Da Services ja nur via Message-Austausch (im Idealfall) kommunizieren faende ich es ideal, wenn man die korrekte Nachrichtenverarbeitung eines Services durch In/Out/Fault/Error Endpoints simulieren koennte. D.h. der Test wuerde Messages auf dem In-Endpoint produzieren und korrekte Resultate auf den anderen Endpoints ueberpruefen.

Ich koennte mir folgende Vorgehensweisen vorstellen:

JUnit standalone Testing der einzelnen Services: Befuellen der init(…) und service(…) Methoden via Mock Objects. Exit/Fault-Endpoints koennen ueber weitere Mock Objects simuliert werden. Vom Service produzierte Messages koennen damit wieder dem Test zur Verfuegung gestellt werden.

ESB-basiertes Test Framework fuer Einzelservices :

Automatisches Deployment des Einzelservice in einen ESB Container incl SonicFS Eintraege, Service Configuration;
Automatische Verbindung und Konfiguration von Service Endpoints, notwendigen Queues und Verbindung der Endpoints mit dem Service;
Eine solche ESB-Konfiguration fuer einen Service koennte z.B. in XML (oder einem XAR File – ausser Queues) beschrieben werden und automatisch via esbadmin-Skripting bereitgestellt werden.

Sonic at CERN

2005-07-21T17:41:00.000+02:00

SonicMQ has been used by CERN from the early days. They started developing the architecture on SonicMQ 2000.1. The deployment platfrom is OC4J and currently they have 2 projects running. The 2 projects are called TIM (Technical Infrastructure Monitoring) and LASER.

TIM is responsible for the monitoring and reporting of alerts triggered by malfunctioning smoke detectors. LASER is resposible for the monitoring of the particle accelerator's state and event display. Note that shutdown during malfunction is managed entirely at the hardware level.

The Kaif is in Switzerland

2005-07-20T17:36:00.000+02:00

A while ago my friend Tusitha told me the Sri Lankan story about the elephant and the monkey:

The monkey jokes with an elephant, asking for a ride up the elephant's trunk. Annoyed, the elephant sucks the monkey up through his trunk. Somehow it gets trickled and loses control and so the monkey passes all the way through the elephant's internals until it reappears at the elephant's backside. Both, elephant and monkey are a little surprised but then decide that it was fun and that they should give it another spin. After repeating the procedure a couple of times, they have the glorious idea of connecting the elephant's trunk to his backside. an infinite loop of pleasure or as Tusitha says they call it in Russia: "Kaif"! The ultimate feeling of well-being ;-) [Not so good Kaif is called "Bale" if I remember correctly]

Well, seems I discovered Kaif swimming in the Aare river. There is an incredibly tight bend just a few k below Bern. The loop is about 1.5k long, but at its extreme points connected by a 150m pedestrian tunnel. You can jump in the river, swim all the way round and then race through the freezing tunnel to do it all over again!

Excellent weekend

2005-07-18T23:34:00.000+02:00

I spent an excellent weekend packed so full with events that it seemed like a mini holiday:

Friday evening straight after work we went to Montreux for a swim in Lake Geneva and afterwards attended the famous Jazz Festival. What an experience even staying on the fringe and not attending the "official" concerts. We saw a Swedish a capella group that had 20 singers and about that many voices. Lovely food too!
Saturday BBQ and swimming in the Aare in Bern. We went to the amazing Aare loop in Felsenau.
Sunday mountain biking in Valais. Thomas and I cycled from Fiesch to Kühboden and on to Märjelensee with views across the Aletsch glacier (26km long, 81sqkm surface), then back downhill via a single trail above the Fiesch glacier. From there, Thomas in his usual kamikaze manner took an almost vertical downhill. Having sweated enough with fear already I descended more leisurely over Riederalp and Bettmeralp towards Brig and also took in the panoramic views from the top of Eggishorn.

Loss of Agility?

2005-03-03T13:32:00.000+01:00

In many software projects the business goals are poorly understood, in flux and hard to communicate. That’s where the agile/iterative approach comes in. Because you can quickly adapt to moving targets it’s much easier to deal with unstable requirements. Now consider a company that wants to put into place a new software system. If they were to start from scratch, they’d probably start playing around with a prototype, throw this at pilot-users and iteratively adapt according to feedback and a more mature requirements. What however, if they decide to build on top of a commercial platform and customise in-house? Then they need to decide for a commercial vendor that *fulfils their requirements* and that’s where the crux lies. How can they evaluate and decide for one or the other vendor when the requirements are everything but clear and stable? Furthermore, a decision is irreversible (more or less, after the licensing fee has been shelled out).

Effectively, you are forced to switch back to the good old “requirements-design-build-test-deploy-manage” approach for this step of the process. All agility is lost! As far as I can see, the only solution to somehow mitigate the problem lies in playing around with open source software before making the vendor-decision. This way you can establish some need-to-have requirements on the basis of which to pick the commercial vendor.

What do you think about this problem? Am I overlooking something, stretching the agile methodology too far? Can you see a solution consistent with the premises of agile development?

Also see Item 6. on the "Overly Long Guide to Being A Software Architect"

Batch File Rename By File Extension in Unix

2003-12-18T11:51:00.000+01:00

Batch File Rename By File Extension in Unix

These are one-liners which batch rename files meeting a certain criteria under unix
These are very powerful command line tools. They have been used on FreeBSD, Linux, and MacOSX with success. But as with any batch file changing, you are advised to use them with caution. Backups are your friend!

# change .htm files to .html
for file in *.htm ; do mv $file `echo $file sed 's/$.*\.$htm/\1html/'` ; done

# change .html files to .htm
for file in *.html ; do mv $file `echo $file sed 's/$.*\.$html/\1htm/'` ; done

#change .html files to .shtml
for file in *.html ; do mv $file `echo $file sed 's/$.*\.$html/\1shtml/'` ; done

#change .html files to php
for file in *.html ; do mv $file `echo $file sed 's/$.*\.$html/\1php/'` ; done"

Sun[tm] ONE Message Queue 3.5 Enterprise Edition, Beta

2003-08-27T11:53:00.000+02:00

Beta release of Sun MQ 3.5. The feature list describes lots of technical details, especially considering their clustering approach. eg info about every cluster node (broker) must be available to the client for load balancing and fail-over.

here are the release notes.

interesting:

enhanced auto-reconnect
broker memory management
monitoring via special JMS destinations
resource adapter for integration with j2ee server

Recovering a Lost BIOS Password

2003-08-25T11:56:00.000+02:00

Google Answers: Recovering a Lost BIOS Password

really good answer -- bios passwords don't seem to offer a lot of protection!