dinkatron

xmlsoap.org having a bad day.

Fergal — Tue, 22 Apr 2008 14:04:00 +0000

Microsoft is doing fun stuff to the xmlsoap.org site.

The schema for WSDL, which used to be located at: http://schemas.xmlsoap.org/wsdl/
(okay it's in the text of the spec at http://www.w3.org/TR/wsdl), has gone AWOL. This is probably winding it's way through multiple build servers as we speak.

Luckily wayback engine to the rescue: http://web.archive.org/web/*/http://schemas.xmlsoap.org/wsdl/

Fantastic. Now if they could only get svn working so I can do internet checkins.

iPhone IE vs UK - guess who is being ripped off

Fergal — Thu, 28 Feb 2008 12:33:00 +0000

The iPhone tariffs for Ireland are out. Unlike US and UK tariffs the data is not an all-you-can-eat affair.

Here's the Irish one:

and here's the UK one:

Notice 1Gb cap on the Irish one and incredible difference in minutes and scabby texts. And are they really charging for voicemail, that doesn't sound right?

New Laptop

Fergal — Sat, 23 Feb 2008 10:19:00 +0000

Upgraded my laptop at home to XPS 1530. Of course I considered an Apple (given that I'm in the US regularly), but even at dollar prices it is still well overpriced. The build quality is really nice (never thought I'd say that about Dell) and the screen is really good (although you cannot get 1920x1200 in the 15.4 form-factor - whereas you can get it if you switch to the much lumpier Dell Precision Laptop).

Overall I found the dell site pretty annoying to navigate when purchasing. For me the key features are:

Screen Resolution - I develop in Eclipse and anything sub 1600x1050 just doesn't cut it, but the Dell site doesn't let you filter/narrow on screen resolution, just overall form-factor (15 / 17 inch). For me this is the most important feature.
Processor (obviously)
Hard-drive speed. This is really confusing - different models support different drive speeds (annoying).
Weight - for instance check out this rather amusing sales line on the XPS 1710: "8.71kg of media muscle". nearly 9Kg!!! They should develop some sort of "Dell-Fit" exercise program to go with it.

So what about the supposed crappiness of Vista. Well I've shoved 4Gb into it, so Vista runs very, very smoothly. So no problems yet.

Does McCreevy have no shame?

Fergal — Sat, 16 Feb 2008 09:58:00 +0000

You really have to question whose interests McCreevy serves. It certainly isn't consumers. The irish commissioner for Europe's Internal Market is backing a proposal to extend copyright from it's current life+50 (expires 50 years after the death of the artist) to life+95 (note in the UK it is life+70). Now I'm for Copyright for artisitic works, but what is patently missing from the proposal is any real justification for why the terms need to be extended (that is beyond the fact the the BPI and their European counterparts are lobbying hard). Is it just me, or shouldn't an internal market commissioner be mostly against extending protectionist measures. But given his previous position on software patents, we really shouldn't be surprised.

Hilariously the Tory opposition in the UK has agreed to back the proposal provided the BPI provide ""positive role models for young kids to look up to, draw inspiration from, and aspire to be". So lots more X-factor for everyone - brilliant.

Workday Acquires Cape Clear

Fergal — Wed, 06 Feb 2008 17:35:00 +0000

Workday has bought Cape Clear. So from today I'm a Workday employee. This is very exciting, not least because Workday are an amazing organization, but for me the real win here is being able to focus our software on making integrations simpler to write, run and manage. Workday are a Software-as-a-Service (SaaS) ERP player (HR, Financials, ..). They figured early-on that integration was a key requirement when selling SaaS solutions. People love SaaS, but how do they connect it to their own systems? Workday's acquisition of Cape Clear is a signal of just how critical that requirement is.

BPMN and BPEL suing for divorce

Fergal — Wed, 05 Dec 2007 13:05:00 +0000

Interesting article over on InfoQ: "The Seven Fallacies of Business Process Execution" which makes the argument that combining BPMN and BPEL is a waste of time. I have to strongly agree here. I have many objections to suggesting that your analysts write a Business Process in BPMN and then generate BPEL for execution. Firstly, is that you expect analysts to write correct BPMN processes. Secondly, only a subset of BPMN is actually compilable to BPEL. Thirdly, round-tripping isn't possible. However, mainly this whole approach is doomed for simple fact that BPMN is complicated and BPEL is complicated. So even if you could do it, debugging, problem-resolution and maintainance would render such solutions unsupportable in practice.

However, it makes the contention that everything you need to solve BPM already exists. The magical solution consists of:

BPEL
SCA - Service Component Archtiecture (composite application framework).
Human Task 1.0 - Web service for defining and scheduling tasks to be completed by humans (e.g. soliciting input / approval).
Web Services (that do other stuff in the business process).

So the solution seems to be BPEL to model the business process, Web Services to implement specific functionality (e.g. createCustomer), Human Task to represent tasks that humans are required in the loop for (e.g. approve this loan decision ? ) and SCA as a means to deploy all these various bits together a composite application. While I agree with the sentiment here, I would caution that Human Task is unproven and ditto for SCA. But we can boil this down to the basic message of BPEL orchestrating Web Services (where some of those Web Services are concerned with interacting with Humans).

This is the approach Cape Clear advocates and the message is fine as far as it goes - but here's the problem. Where do you start to design your process? It is BPEL outwards? Do I describe things in WSDL and then define them in BPEL and invoke on Web Services. What about interface design? Sure even Human Task can be coupled with some rendering technology to allow simple forms to be generated, but that is for back-office work. What about front-office / customer-facing web site, where does this fit in. So this isn't a development framework, but a collection of things that you could cobble together to form a solution. How are such solutions extended and maintained (new tasks, modified task descriptions, etc, etc). For me, quite apart from the unproven status of Human Task and SCA, it seems very early days for this approach - but in theory it has merit.

Zombie Cockroaches

Fergal — Fri, 30 Nov 2007 13:14:00 +0000

Checkout slashdot for links about wasps that create Zombie Cockroaches (including a movie).
What's next? An ant wielding a sawn-off?

Building a Android Application

Fergal — Mon, 12 Nov 2007 20:26:00 +0000

Interesting YouTube - A first hand look at building an Android application about building a Android application. Highlights:

Eclipse project support. With emulator support.
Write Java to develop a new application - pattern is to extend an existing class for controller / behaviour, use XML for visual layout (view).

What is apparent from looking at this, is that the capabilities provided by the API are nice, but basic. I think someone needs to Spring-ify this API a bit more - a lot of the code (and to be fair there isn't much required) looks like stuff that could be configured rather than programmed (freeing developers from having to know specific API's - at least for basic stuff like listing contacts and tie-ing these to actions).

Still it is nice to see this kind of capability. Will be interesting to see how this compares to the Apple IPhone SDK when it arrives next year.

Re: The ESB Question

Fergal — Mon, 08 Oct 2007 21:32:00 +0000

Steve Vinoski’s asks do we need ESB's? Since Steve used to work for Iona, he'll definitely have a point worth listening to. His main argument boils down to:

ESB's are useful for a limited set of circumstances - dealing with legacy systems that cannot be replaced. Well this is certainly true.
Echo's Patrick Logan's Opinion on ESB's - "just use the base libraries instead and where possible use REST"
Dynamic languages (Ruby, Python) are better than static ones for integration.

I'm going to ignore the last point. It believe it is silly to make such a black and white distinction. If you want to use dynamic languages to integrate two systems together use that. If you don't for whatever reason, then don't. I think the static vs. dynamic language argument is a red herring on the level of VI vs Emacs.

Personally, I prefer dynamic languages, they seem freer (but that is mainly a preference issue for me). Interestingly, most of the first integration problems I encountered in the early 90's I solved using Email + Perl. Later it was Perl + XML + Java + Email/HTTP. Then Perl + XML + Java + XPath + XSLT + Email/HTTP/JMS. Things kept growing like that. It was never a case of static vs. dynamic languages - it was a mix of what do I know, what code / libraries can I find. This is why Patrick's opinion above resonates with me. Now I think there should be a simple easily-to-understand rule that we can use here:

If your problem looks like a simple thing that an ESB can solve (potentially faster than you can code comfortably against the collection of libraries that you may or may not know), then it might be worth downloading and trying it out. If it doesn't solve your problem, or you don't like the look of the solution, then you should not use it.

Now the important points here are whether you are comfortable and whether the ESB actually saves you some time and effort (for surely this is the point of using a framework). There are other points to using a framework (for example consistency, but these are secondary and may not apply to your particular integration problem). So this is the well rehearsed "framework vs library" debate - and when you look at it this way, the main problem with ESB's is that they are all different - which is a problem. Still from a framework point of view we can draw an analogy between MVC and ESB. Do you need an MVC to write a dynamic web-page? Nope. Is it overkill? For one page? Definitely. What about a lot of them? What about pages that load stuff from a database? etc. etc. You can see where this is going.

One interesting thing about frameworks though is that they are generally replaced by other frameworks - they rarely devolve back to code-against many libraries.

This brings me to the second part of Patrick Logan's point: REST. I'll admit it, I'm somewhat confused at REST vs ESB debate. It was REST vs WS* wasn't it? Anyway, seems we don't have enough to argue about. The reason I'm confused about REST vs ESB is that REST is a style of writing and/or consuming Web Services, whereas ESB's are an integration technology for mixing together messages, protocols and web services (WS-* services, REST services and REST's poor relation: XML/HTTP services). So clearly REST on its own is not really what's being described here. So widening it, is this debate "Are REST + APP + Some-other-framework better for integration problems than ESB's?". I think this doesn't make the issue much better. They may be for some problems, but not for all. Why? It is the keyword 'integration'. Many integration problems mix protocols, Web Services WS-* and REST together (no, apparently it isn't illegal). Some even use, you may need to sit down at this point, Microsoft's MSMQ. So clearly a REST+APP+something else isn't going to solve all problems (unless the something else starts to offer features suspiciously similar to those provided by an ESB e.g. protocol adapters/mediators).

The correct way to think of this is back to the REST vs WS-* debate. Which style of web services do you want to write/use? ESB's should be neutral on this question: Have it your way and if you need to mix these and other stuff (e.g. Email) so much the better. Interestingly if you did think that REST+APP on it's own are the only way to integrate systems together, then by definition everything else is legacy. Which brings me neatly to Steve's first point. ESB's are good for legacy. If this is the definition of legacy, then I'm more than okay with that. I work for a company that sells an ESB, so obviously I'm biased
here, but hopefully not too much.

7.5 hits the bricks

Fergal — Tue, 25 Sep 2007 17:11:00 +0000

Cape Clear 7.5 Released - Huzzah! So what is new? Along with all the usuals (faster, better, more stable, more stuff) the main feature is Assemblies. I've put an example of these up before. So what are assemblies? They are:

stateless,
high-performance,
soap-agnostic,
spring-configured,
message-oriented,
micro-flows

Assemblies allow you to create processing chains that wire transports, processing steps, routing strategies and web services together in the one file. They accept any kind of message: (SOAP, XML, Text, binary, whatever)
over multiple transports (SOAP/HTTP, REST/HTTP, XML/HTTP, JMS, File,
FTP, Email, etc) and allow it to be processed and routed along.

A natural question to ask is why would I need Assemblies when I have BPEL? The answer is that they are complimentary technologies. BPEL's sweet-spot is modeling stateful, recoverable processes that orchestrate Web Services - a task it does extremely well. However, not all integration problems have these features. Assemblies by contrast are about stateless message processing - taking a message, transforming and routing it. Assemblies also provide a much simpler to create and understand than BPEL.

Anyway, try it out for yourself.

SOA and ESB's - cue backlash

Fergal — Wed, 29 Aug 2007 08:54:00 +0000

In a pretty funny article titled "ESB-oriented architecture: The wrong approach to adopting SOA", Bobby Woolf of IBM points out, rather sanely, that if you think that an ESB is some magic wand you can wave at your project Harry Potter style, mumble a SOA incantation and expect a fully formed SOA architecture to emerge then you deserve everything that is coming to you. I couldn't agree more. An ESB is a useful tool, but it isn't magic. If you think you merely have to deploy an ESB to SOA-ify your project, then you are putting the cart before the horse.

Repeat after me "There are no Silver Bullets".

SOA is an architectural approach, you need to concentrate on building services, services that align with business needs. The promise of SOA is business agility. It may be that an ESB will help you realise your vision quicker, since they are fundamentally useful, but you need to have the vision first. Then you can choose the right tool for the right job.

This is much the same message being put forward by Jim Webber on Guerilla SOA. Define what is it that you want to do and choose the right tool for the right job. It may be that you need an ESB, it may not. Definition will at the very least help you choose between ESB products.

This is also the message coming from Cape Clear : The End of Big SOA. Over the last years we have seen increasingly bloated and complex products and perhaps more disturbingly increasingly bloated RFI's. I've lost count of the number of RFI's that specify requirements for technologies I know that customers don't understand and more importantly will never, ever use. So good riddance to this trend. Part of the attraction of SOA was a move to simplicity. And the industry is now re-asserting this message.

Also the refocusing on SOA and not on the ESB, will hopefully shift the focus back to producing services. ESB's mix a couple of features:

connectivity (email, HTTP, FTP, File, JMS etc, etc).
mediation (transformation, routing, micro-flow).
service-creation
service-orchestration

Message-Oriented Middleware (MOM) typically refers to message-queue systems such a JMS. However, ESB's do enable a superset of MOM, which can accept messages in any format,from any transport and route and transform them. This is related to Jim Webber's MEST acronym which stands for Message Transfer. This is supposed to be a message analogy to REST. Wouldn't MT have been a more appropriate acronym (but then it wouldn't rhyme with REST I suppose).
These are the connectivity and mediation parts of the ESB (the bus parts). They are a generally useful tool. You can use them to:

build an MO-system
mechanism for versioning services.
mediate different clients of services.

However, many people when they think of an ESB, focus only on these features rather than service-creation and service-orchestration. This is wrong. SOA is about creating services, the connectivity and routing part is important but should be considered secondary to services. Or put another way, routing / mediation is important, but you need something to route / mediate to.

So clarify your vision, define your business process, define your services, identify your clients and data formats. Then choose the right tool for the job. Most of the time you'll choose an ESB to help you implement the project, but this is not ESB-first. That would be like saying "I want to create a Real-time Flight Simulator! Step 1: I need a Java compiler" - you will most likely, but Step 1, is define the problem to be solved.

Is BPEL universal?

Fergal — Sat, 04 Aug 2007 09:04:00 +0000

Jeff Davis blogs about some of what he sees as the short-comings with BPEL: What's wrong with BPEL?. It is a mixed-bag - somethings are correct, some aren't. Here are they points:

BPEL only works with SOAP-based services. This isn't true. With BPEL 1.1 spec, BPEL required WSDL as a means to specify a partner's API. Now WSDL can support SOAP bindings, but other bindings exist (e.g. WSDL-HTTP). So at a spec-level SOAP wasn't a prescription. However, in practice many BPEL 1.1 engines only supported SOAP-bindings. With BPEL 2.0 even this dependency on WSDL has been removed. - BPEL 2.0 doesn't require WSDL, and it already didn't require SOAP. The standard has deliberately and in my view correctly moved away from the WSDL/SOAP heritage. BPEL is a process workflow language about manipulating XML documents - so now it requires only XML Schema. I think over the next year many of the existing BPEL tools will support creating partner descriptions from REST+XSD, WADL and POX. The next version of Cape Clear supports inclusion of REST-style services directly in BPEL (no SOAP required). We've also greatly simplified connecting to JMS, Email, FTP, etc from BPEL with or without SOAP.
Passing of data between activities requires XML and WSDL constructs. Again BPEL 2.0 removes the WSDL part. You only need XSD knowledge. Admittedly this is confusing for developers - so I think this is mostly a valid point.. Looking forward, good tool support can help. BPEL 2.0 also supports expression languages. I think innovative companies will provide good Java-XML bindings automatically to make them amenable to Javascript or Groovy manipulation.
BPEL is a closed standard. This is the point that if you use an proprietary extension then you are no longer vendor neutral. While this point is true in the general sense, many BPEL engines provide the ability for developers to define XPath extension functions to Java which can be called from within BPEL. This is a reasonably indepdendent extension mechanism. Also, any Specification can be called a closed standard from this point of view. So should we abandon standards?
BPEL requires deployment for testing. This is true of some products (it is true of Cape Clear). Not sure I agree with the "impacts developer productivity". I think productivity can be enhanced through good tools: viewers, debuggers and test frameworks. For example Cape Clear allows developers to use Buckminster to automatically build, deploy and test BPEL or Java Web Services from within a continuous-build system.
BPEL is confusing - I agree with this point. There are lots of new things to learn. I'll get back to this point at the end.
BPML as a solution to BPEL/Process modelling - only makes things more brittle. I agree, but my advice would be: don't use BPML as a means of specifying BPEL. BPEL is a programming language, to gain its power, you need to use it directly.

So as I said a mixed bag, some right, some wrong. Jeff mentions that JBoss JBPM may be a better fit than BPEL for Java shops (which is interesting given his point 3 above). I obviously wouldn't agree :-) However, I think a more interesting issue is whether BPEL is a universal tool, can it/ should it be applied to all integrations involving Web Services. No it shouldn't. There is no such thing as a universal tool - there are no silver bullets. BPEL is incredibly powerful and has very well defined semantics, but it has a sweet-spot: orchestrating stateful web services together. If that is not what you are doing, for example, you are using BPEL as a stateless route-n-transform mediation, you can do this in BPEL, but if you are a Java shop, you can quite easily do this in Java. Many of the ESB's on the market (including Cape Clear) will help you do this with no BPEL required. So pick the appropriate tool to fit your circumstances.

HTTP Ping-test with assemblies.

Fergal — Tue, 24 Jul 2007 16:58:00 +0000

Justin Mason blogged about an interesting use of Jaiku for http-ping testing. It has an open-API, SMS testing etc. We are currently just rolling out our new assembly framework, so I thought can I do the ping-test easily in assemblies. As it is I can. So here is all the working code for the assembly.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:cc="http://www.capeclear.com/assembly/10">

<cc:assembly id="CapeClearAssembly">
<cc:staticfile-in input-file="myfile.txt" id="staticFile"
routes-to="httpCheck">
<cc:schedule cron="0/10 * * ? * *"/>
</cc:staticfile-in>

<cc:http-out id="httpCheck" endpoint="http://dink.capeclear.com/"/>

<cc:xmpp-out id="xo" endpoint="xmpp:someOperator@gmail.com"
username="someUser" password="somePassword"
server="talk.google.com" domain="gmail.com"/>

<cc:send-error id="sendError" routes-to="xo"/>
</cc:assembly>
</beans>

It sets up a static-file event (running every 10 seconds according to a cron schedule). This event creates a static message which is routed to a HTTP-out transport (see routes-to attribute of static-file-in). The http-out transport is used to ping some URL (in this case dink.capeclear.com). If this ping fails, then an error handler (sendError) is automatically invoked. This sendError command routes a message to GoogleTalk IM (xmpp-out).

The result is that if dink.capeclear.com is not available, someone gets an IM message on googleTalk.

BT ends eight-year SOA effort- starts Phase 2.

Fergal — Mon, 02 Jul 2007 10:58:00 +0000

Techworld.com - BT nearing end of SOA project reports on how BT has completed an eight year SOA project - to SOA-ify it's core systems. Headline items:

Core systems weren't what the business process said they were when they actually looked.
20% reduction in IT Staff.
2,000 IT Staff redeployed from internal to customer-facing projects - now that the internal API's are defined.
160 core SOA capabiltiies (each with 5-15 operations).
IT Staff Bonuses now in terms of SOA-re-use.

They reckon that now that they are all SOA, it should be much quicker to roll out new services that work in terms of these core capabilities (customer account management, provisioning).

BarCamp Ireland 3

Fergal — Thu, 12 Apr 2007 16:29:00 +0000

Just realised I'm going to miss Barcamp Ireland 3 - which is on April 21st, due to unavoidable weddding. Well, hopefully I can make it to Barcamp 4.

Jolt Award / Cape Clear 7

Fergal — Fri, 23 Mar 2007 12:46:00 +0000

Cape Clear has received a Jolt Award. Score!

We also just released Version 7 this week, with spiffy new Eclipse-based tools that make writing, testing and maintaining web services much, much easier coupled with an improved server.

So now, it is time to pause and take stock of where we are and where we want to go over the next year. What seems clear at this point, is that the simplicity of the SOA vision (services, loose-coupling, easy integration) is being corrupted with ever-increasing complexity. It is time to focus on the basics, on problems and their solutions, not technologies and the ever-growing checklist of things a developer supposedly needs to know (see this scary wallchart: WS-*). To quote NTK:

THEY STOLE OUR REVOLUTION. NOW WE'RE STEALING IT BACK.

Eclipse Equinox OSGi R4 on the Server

Fergal — Thu, 08 Mar 2007 10:29:00 +0000

Finally got a chance to look a the the Eclispe Equinox project. This is an implementation of OSGi R4. OSGi as many people have mentioned over the last couple of years is becoming the dominant model for component life-cycle management (okay lets not mention the debacle of JSR 277). Having used earlier versions of OSGi during Eclipse plugin programming, I really do like the model. It's clean and relatively simple.

What is increasingly apparent is how OSGi is set to become the dominant force on the Server (see this slideset). Why is this? Essentially it is because the days of manually upgrading a server are coming to an end. The cycle where you take a server down, install the newest version and migrate applications, really is looking out of date. Software as a Service (SaaS) is the disruptive force transforming development. However, not all applications (currently categorized as client or server-side) will be delivered as SaaS, but at the very least these applications will need two things: an upgrade capability and the ability to run multiple versions of components together. OSGi provides both.

Joost

Fergal — Wed, 28 Feb 2007 09:49:00 +0000

Tried out the 0.8 beta of Joost formerly the "The Venice Project" on windows. This is an IPTV platform based on P2P technology headed-up by the Skype guys. The shocking part for me, being used to the low-res download jitter of YouTube is that it actually does what it says on the tin. When I first started it up, there were lots of pauses and delays. Resizing down the window from fullscreen and letting the beast run for a bit seemed to help and eventually I was watching TV on-demand. The quality of the video is decent - much better than say YouTube. That said I wouldnt' watch it in fullscreen mode, for the same reasons I don't watch terrestrial television in full-HD mode - pixelation/digital artifacts annoy me. It's better viewed in small screen mode. Still decent enough to watch, not as good as good as an Xvid torrent of your favourite show (btw: check out Zudeo this is site from azureus team).

Admittedly the standard gripe "there's nothing on" applies here - some car programs, national geographic, cartoons etc, but presumably that will get better. But it works. The gotcha is Joost should only be used for people with no download limits.

The interface is nice and simple, channels on the left, widgets on the right. The widgets allow you to do various things while watching TV, e.g. chat (like an IRC channel per program), search, browse news feeds.

Yahoo Pipes

Fergal — Fri, 09 Feb 2007 12:28:00 +0000

This completely rocks - yahoo pipes allows you to remix RSS feeds visually - in a DHTML/Flash IDE in the browser. The metaphor is Unix pipes. Setup an RSS input (URL) and then create a sequence of pipes (filters, transformers). You can then publish the result. I was able to create a pipe that filtered RSS feeds from developer.capeclear.com, to filter only XSLT related forums in about 1 minute.

Plus, it has an interactive-ish debugger. Sweeet. Check it out.

Just enough XML to survive

Fergal — Fri, 02 Feb 2007 09:35:00 +0000

James Pasley has posted a video which explains the basics of XML, SOAP and WSDL in 15 minutes for people who've never encountered them before. This is pretty useful stuff - kinda, an XML and Web Services for newbies. You can place requirements on a talk, such as "should be familiar with XML", but no one ever pays attention to that and even if they wanted to familiarize themselves, where would they start? Now you know. Link to video here.

Dublin Wifi

Fergal — Wed, 31 Jan 2007 22:46:00 +0000

Dublin City Council (the 21st Century version of the Corpo) is considering setting up a Wifi to cover Dublin. Really? Apparently it'll only cost between €10-€20 million. A snip, but presumably it'll cost something to run annually on top of this. Anyway, The Telecoms and Internet Forum (TIF) are already whining that this government interference and stifling competition, that it could quote "damage broadband take-up in Ireland". Riiiiiggght, because broadband takeup has been going so well recently. Let's remember that in Dublin 15% of people still aren't able to get Broadband. That's in Dublin the capital city of one of the richest countries in the world. Meanwhile you may as well abandon hope if you are part of the 42% unable to get DSL in Connaght). I happen to be one of these unlucky Dublin 15%. I live in Glasnevin in the "Dublin Central" administrative area (so obviously getting DSL is out of the question).

Anyway, what is so wrong with covering Dublin in Wifi? What is wrong with having free basic access? It is not like the incumbents are doing such a stand-up job. You can't get Broadband all over Dublin and the customer service of the incumbents really do leave a lot to be desired. Well here's something to think about. If we think of broadband access as a basic utility like gas, electricity or water, there are two basic things we should recognise:

The move over the last 20 years in UK and Ireland has been to privatise these utilities. This competition has undoubtedly led to cost-savings in some areas (gas, electricity ) but real structural problems in others (water). To take them out of government hands and provide competition.
If Dublin City Council are providing a new utility, that costs X million to run each year, who will be paying for it? Eventually, if this is utility model, wouldn't we get a bill. What's the business model? Advertising based?

The competition aspect that TIF raises I think is a currently a red-herring. Remember Northern Ireland (predominantly rural area) has 100% Broadband penetration. Until we have this in Ireland and especially Dublin, anything which can stimulate competition is a good thing.

iPhone - Linux got there first

Fergal — Wed, 17 Jan 2007 16:04:00 +0000

Gizmodo has nice picture of a linux phone which looks freakishly like the iPhone. Crazy.
The iPhone will sell by the bucketload. Why? Because it's a fashion phone. This is the really weird thing that most blogs have missed.

How many people use the features of their phones - I mean phones here and not just smartphones. Camera - lots of people have low usage of it. Calendar, task manager - I've heard of them. People will want it cos it's slick.

Will it change the way people think of phones. Nope, but there are some really nice touches (mouse gestures for zooming, orientation detection, turning off the light when it's close to your head). But the spec (for Europe anyway) is a wee bit light. Now a phone that I could use as a wii controller that would be cool.

24 developers on the Vista shutdown button

Fergal — Mon, 27 Nov 2006 21:28:00 +0000

Yikes. it's worse than we feared, but at least the delays make sense.

Come over all warm and fuzzy when you consider the sysephean project management hell happening in The Windows Shutdown crapfest. Now your own management hell will seem positively amateur.

S stands for Simple

Fergal — Fri, 24 Nov 2006 13:32:00 +0000

Amusing fictional conversation between SOA guy and new developer: Pete Lacey’s Weblog :: The S stands for Simple. Very funny. Favourite quote:

Dev: (Reads WSDL spec). I trust that the guys who wrote this have been shot. It’s not even internally consistent.

Intalio Benchmarks

Fergal — Thu, 23 Nov 2006 16:53:00 +0000

Intalio have published benchmarks for their BPEL engine. Benchmarks are a double-edged thing: you desperately want them to be able to compare different systems together, but experience teaches you that published benchmarks should never be given much credence. Their primary purpose is to benefit vendors' marketing agendas, rather than providing objective data upon which customers can inform purchasing decisions.

So where do the Intalio's one lie. It's difficult to say. 3.5 million BPEL transactions on a basic two-way server with a separate mysql database. That's about the sum of infomation. What is this BPEL doing? If it's simply echoing 'Hello World' or adding two numbers together it's a pretty meaningless benchmark.

The performance of a BPEL process is a sum of three things:

Transports - SOA means you don't get to dictate which ones your
customers use, you work with them.
SOAP Stack - Use the fastest (but SOAP parsing is a small portion
of a real-world BPEL transaction).
BPEL processing - Obviously performance / speed is interesting but
it is not really the most important issue here. For most enterprises these are the critical issues:

Reliability: This is the key issue. Can the process survive
server failure. How transactionally integrated are the transports and the BPEL engine? Messages sent or received
should never be lost or duplicated.
Availability: Can your system survive server failure.
Scalability: Can your system scale as load increases.

These last properties (the RAS of RASP) mean you need effective BPEL clustering.

There are two basic scenarios we should keep in mind when
people discuss benchmarking BPEL:

Unreliable Applications

Use an unreliable transport (e.g. raw HTTP) with a BPEL engine that
doesn't save state to a persistent store. You can produce benchmarks for
this, but this is really not the sweet-spot for BPEL - if a BPEL is
being used to model a Business Process then normally reliability is key.

Reliable Applications

Use a reliable transport (WS-RM / JMS) with a BPEL engine that provides
the highest degree of reliability. But what does "the highest degree of
reliability" mean? Different products open and commercial have differing degrees of reliability. Establishing a benchmark for this as some sort of
conformance test suite would be very useful to the industry.

So assuming you can determine the level of reliability you are happy with from a set of products (this is a big if), what is a useful measure for reliable applications? Well here are three suggestions:

Measure how well a BPEL engine can support large volumes of processes. BPEL Processes can live anything from seconds, to weeks and even years. Can your system support millions of live process instances?
Does your BPEL cluster scale? Can you add more servers to handle
additional load and maintain response times? Or does your cluster degrade as it handles replication of state.
Can your BPEL server support multiple workloads with different load / transport characteristics? Does it do so in a fair manner, or can one process starve resources from other BPEL processes?