Monday, April 25, 2005

Not doing a technology a favour

The Spring Framework is a worthy attempt to simplify Java/J2EE. These days pretty much everyone accepts that J2EE is largely a pig:


  • Its large, complicated and unwieldy.
  • EJB to date (i.e. pre v3) is a big fat failure.
  • EJB to date is completely inappropriate for many projects.
  • JCA is dying on it's feet.
  • The promise of portability has failed
  • The whole concept is not agile, why standardize a container, instead of it's component technologies?
  • I mentioned it's a pig right?


Spring aims to:

  • ease this burden this by simplifying configuration (via IOC),
  • provide developers with simple ways to use and combine the useful component technologies of J2EE and non-J2EE components - in a flexible way, you only need deploy what you use;
  • use AOP for declarative transaction management;
  • make testing easy, no setup problems.


But then this: Add a simple rule engine to your Spring-based applications. This genius suggests implementing what he calls a rule-based engine in Spring. The advantage seems to boil down to: you can use the Spring's configuration xml to create your ruleset. Oh dear. And it doesn't stop there. His idea of a rule-base is to use spring's XML to define a lot of if-then-else statements connected into a graph. Oh dear, that's not a rulebase, that's a monstrously inefficient way to encode a lot of if-then-else's in xml. Rule bases are intended to be configurable, efficient via RETE-II algorithms, support multiple priority-levels and modal contexts. Oh and I think there are standard XML vocabularies for specifying rulebases (maybe Rule ML?). This article just makes Spring developers look silly.

This whole episode is a good example of "patternoxia" - the misguided attempt to describe obvious things and everyday workarounds as patterns. E.g. "I have discovered a useful pattern that developers should follow when faced with the need to make decisions: the if-then-else pattern. I have createed a set of interfaces and abstract classes that developers can use. This adds to my while and empty statement patterns covered in earlier articles". You have been warned.

Thursday, April 21, 2005

The Sect of Homokaasu - The Gematriculator

Apparently this blog is only
52% evil. Will I guess that it's early days, but it is comforting to know that at least I'm starting from a sound foundation.

Thanks to dk for the link.

Thursday, April 14, 2005

BPEL and Java

Good article BPEL and Java. Introduces basic points of BPEL and positions it. W.R.T BPEL and Java boils down to:

  • Use BPELJ if you like mixing BPEL and Java in one file.

  • Or try WSIF for accessing things as web-services.

  • The BPELJ solution seems really ugly to me, mixed scripting languages are rarely a good idea. Plus it really mucks up portability.

    The WSIF is general java API solution for using WSDL as a universal API description, with pluggable bindings for SOAP, EJB's, Java etc. etc. It's seeming less useful with JSR 181 web service meta data annotations that simply let me expose POJO / EJB's / whatever as web-services.

    So not really much help there. So it could really be, BPEL use it for intelligent routing, conversation handling and stateful processing. Use something else, e.g. Java for complex processing. Address that something else as a web-service via WSDL and incorporate it into your BPEL script.

    One of the comments on this that comes up is what is the relationship between BPEL (orchestration), BPM and Workflow. The JBoss JBPM people would argue that workflow involves humans and task management, BPM involves EAI (i.e. adapters). These distinctions are largely illusionary. The adapter argument is disappearing, most pure play adapter vendors have shut-up shop. Most companies shipping adapters for their products are also addressing them as web-services (meaning they can be directly incorporated in BPEL). As for workflow. Integrating with a task management portal, like a bug-tracking system like Bugzilla, JIRA et al is entirely possible from a BPEL script. This just leaves BPEL.

    Who's watching the watchers?

    Well at least there was only "45 or 50" breaches of security at the privacy invading companies: It's official: ChoicePoint, LexisNexis rooted many times | The Register

    So not only do they steal your data, they allow others to steal your data too (well I guess it's only fair). The real doozer here though is that they never publicised the breaches, meaning the individuals whose personal data was threatened were never notified that they could now be victims of ID theft.

    Just in case 45 or 50 doesn't seem outrageously high to you, the most recent of these incidents involved leaking 310,000 victims records.

    XML.com: XML Namespaces Don't Need URIs

    Frightening. XML.com is the premier XML newssite on the web. Plus it's an O'Reilly site so you expect a certain pedigree to it's content. Instead you get this: XML.com: XML Namespaces Don't Need URIs. This article starts off from the fairly reasonable standpoint that namespace URI's (the mechanism in XML that is used to disambiguate elements and more importantly their corresponding values from different XML Schemas (grammars)) are ugly and unwieldy. Fair enough, I don't think you'll find too many people disagreeing.

    Namespace URI's work by allowing you to prefix any XML element or value with a token, e.g. for XSL you would use the "xsl" prefix e.g. . You declare the prefix (typically on the root element of a document) by including an attribute of the form xmlns:="". What the prefix is then is a shorthand to use in the XML text for the namespace URI. Similarly values referenced from imported documents, are prefixed so that they can be resolved from the importing document.

    The article then argues that URI's are the wrong sort of namespace declaration. Again a reasonable point when compared with say a programming package declaration, e.g. org.w3c.xml. More readable certainly, but not semantically different.

    Then it loses the plot and says hey we don't really need namepace declarations, prefixes are enough, providing we all choose reasonable prefixes. I'm sorry they aren't. While I'm no fan of namespace handling. In it's current form it makes processing XML documents a real pain in the ass. However, something like namespaces is still required. Otherwise we need a registry of known prefix types. For prefix clashes, it seems to suggest using aliases, but this is equivalent to namespace URI's anyway.



    xmlns:xxx="http://www.xxx.sss/"

    Friday, April 01, 2005

    Pope Aid

    So the Pope is dying. Many, many well informed and smart people are saying a lot of worthy things about this great communicator, collectively ignoring that the spiritual leader of a couple of billion people has been wearing nappies and simply going through the motions for the last decade.

    What I find most interesting, is that at what is probably seen at the defining apex of twentieth century Catholicism in Ireland, the lark in Phoenix Park that was "The Pope's visit to Ireland", there was a million people turning out to celebrate the awe and majesty of mother church. Ironic really that in their midst, the generation of kids that they dragged along for the day out, have grown up and turned their backs in a mixture of indifference and disgust.

    Wireless Broadband == happy, happy

    It amazes me how wireless + broadband has re-introduced computers back into my spare time. While I've owned a computer at home for at least the last 10+ years, since I use them all day at work I've only really used them at home on an severe as-needs basis. There are a couple of familiar reasons (heralded in many broadband adverts):
    • it was in a different room, the spare room, which is always a somewhat depressing room.
    • needed to dial up the internet over a slow modem connection
    • there was really quite a lot of good telly on.
    • it's anti-social (new-age-net-friends take note).
    So finally threw out the tower, ordered a laptop, wireless router and a zippy broadband package. It's not just better, it's a different fish entirely. Now I can sit on the sofa watching telly and surfing or twiddling software I never had the time to play with before. The photos that have been languishing on my hard-drive (bought spiffy digital camera two years ago) have been uploaded to photobox. Skype let's me call friends for free and I can work from home when I need to.

    No wonder laptop sales are set to out-sell desktops in the next month.

    Now there was only one fly in this ointment: my choice of router. I chose the Asus wl-500g wireless router. This router came recommeded by a friend. It's 54g provides lots of spiffy additional features like USB ports (stream music / attach hard-drive for ftp server) and printer ports (meaning no more connecting printer cables, just print over wireless). Even basic setup was easy. The problem came when I wanted to start setting up the internet firewall. Its setup was really really old. You basically had to individually open up source and destination ports on the incoming WAN-to-LAN side. This is a real pain in the arse to do, a task beyond the capability of most users and the end result is not very secure. For every outgoing connection, for example HTTP (port 80) you have to open up inbound packets thar originate from a server on port 80. But you can't really filter them any further than on your IP range (e.g. 192.168.1.* - so try not to choose this as your DHCP range since it' usually the default). This isn't terribly secure.

    Most firewalls from this millenium use Firewall SPI (Stateful Packet Inspection). The problem with the previous description of firewall setup is that it is a very simple mechanism that filters incoming and outgoing packets independently - i.e. at the raw IP level. But this isn't how a lot of information flows over the internet. Most information that you are interested in allowing through your firewall flows in terms of connections. I send a request to a HTTP server, it sends me responses. There are outgoing (request) packets and incoming (response) packets, but they are correlated. This in a nutshell is what SPI does. It tracks outgoing packets and when a packet arrives inbound it checks to see does it correlate with one that was sent out, if so it lets it pass. This turns out to cover most uses for home networking. Obviously if you are running dedicated servers you will need to open their inbound ports directly.

    So where does this leave my router. Well the short story is that I spent several hours over a couple of days opening ports, testing software attempting to get my work VPN to work with my firewall. This also involved helping work IT debug their service, but that's another story. Anyway, I failed to get it completely working. It would work to a degree - this was very annoying. All the time I believed the product blurb "supports VPN pass-thru".

    Turns out it didn't. There's a firmware upgrade available which fixes it. Download it, install it (then reset the router - unfortunately they don't tell you this) and wallah - everything now works pretty much out of the box. The router really is doing what it says on the tin.

    So the moral: check for firmware upgrades (I know, I know).
    The real moral: ASUS guys, you should add an auto-upgrade feature to your router (at least let people know one is available). You also need to provide better information on your web-site, such as "VPN pass-thru doens't work on firmware earlier than 1.9.X.X despite what we might have claimed on the box".