Sometimes I look at the state of integration and I think that things could be so much better. We’ve effectively been doing it since the Berlin airlift. By now you’d hope that things would have settled down and the ability to do integration would simply be a commodity and I would be out of a job. I’m not and that says more about each new generation of programmers than it does about me.

The adapter has supported remote JMX via JMXMP for a while; which means you can connect to an adapter via jconsole, or other tools. The only problem with the reference implementation (e.g. service:jmx:jmxmp://localhost:5555) that people tend to use is that it isn’t terribly useful if you’re managing a community, where the various IT policies aren’t going to let unfettered access through their firewall to the adapter; some of our smaller customers they don’t even have an IT dept., and talking the business admin through how they need to modify inbound NAT on whatever router it is they’re using is not for the faint-hearted (and basically you end up being their IT dept. which is another sorry state of affairs).

Email is probably the single thing that you pretty much guarantee every company is capable of. That doesn’t mean that it’s a good thing to do integration with; the way that various mail clients can / will munge the data is quite extraordinary. It’s a given that at some point you will have received an email that has an attachment called winmail.dat or emails that inexplicably have an empty body, and an attachment called ATT00001.htm that actually contains the email. That last situation seems to occur quite a lot when an message generated by Outlook (with graphics in the signature) is forwarded by someone using a Mac.

I haven’t posted for a while, I can see that my last post was in June; the summer holidays must have been quite exciting (or frenetic); can’t remember now. Anyway, this post is about something that isn’t really used in the adapter; which is TriggeredChannel. It is a channel where the workflows are only started when an external event occurs; hence the name. Once the trigger is received; workflows are started, the channel waits for the workflows to do their thing, and then stops them afterwards and is then ready for the next trigger.

I have a daughter; in the near future she’s going to start browsing and terrorizing the web at large. One of the things that’s been at the back of my mind is how I’m going to handle that. I don’t subscribe to the notion of ISP level filtering; not because I think it’s a bad idea (it might not be a bad idea, but it’s sure to be implemented terribly), but because I don’t think that I should abrogate my parental responsibilities in that fashion. The other thing of course, is that my daughter will (eventually) be able to bypass any security; that’s not an if, it’s a when; when she can do that, then good on her; I think I’d have to trust her by then. In the meantime though, it’s time to start locking down the network…