Now they have a Flash Plugin that can be embedded into your posts (either using HTML or Javascript), that uses the Flickr (or Picassa) “Feed API” to show content from your public Flickr Feed. You can restrict it by User, Album (set), Group, or Tag. You can also customize the wall to show a certain number of columns, color style, etc.

What I like most about this plugin is:

• It’s a cool way to embed your photos from one place (e.g. Flickr)
• You can still allow people to “click through” to Flickr and see the actual image
• User can switch to full-screen for a really nice experience
• It’s difficult (without clicking through and viewing the Flickr photo) to casually download the image. You certainly can’t ‘screen-scrape’ them.

The instructions for creating such a wall can be found here:
http://www.cooliris.com/developer/reference/javascript/

As an illustration, here is a “Cool Wall” for my “Misc Art” set on Flickr.

For more information on what things you can show in the wall, see here:
http://www.cooliris.com/developer/reference/media-site-apis/

The crux of the requirement is this:

For an OSGi platform, with a given bundle, I might want three different set of configuration available to me:

• Global Configuration – available to ALL bundles
• Bundle Configuration – configuration specific to a named bundle (e.g. “MyApplicationBundle”)
• Version-specific Configuration – configuration that is specific to a particular version of a bundle

Global and Bundle should be self-explanatory, the Version-specific might not be so clear. Version-specific config comes mainly into play when we’re deploying multiple versions of the same bundle side-by-side. Useful for upgrades, backwards-compatibility, etc. If I write a new version of a bundle (say “MyApplicationBundle”, version 2.0), it’s not necessarily true that the configuration properties I used for version 1.0 are going to be applicable to version 2.0.

But ultimately what I want is to be able to have ONE set of Configuration which is:

GLOBAL + BUNDLE + VERSION = [My Bundle Configuration]

Where if the same property is specified at the BUNDLE or VERSION level, it overrides the more general property. This allows an administrator to set a particular property once and only override it if necessary, rather than copying it into each configuration for a bundle that requires it.

Config Admin today allows me to load a particular named Configuration (e.g. “MyApplication”). I guess you could argue that I could achieve a version of what I want by simply having three property files (“GLOBAL”,”MyApplication”, and “MyApplication_2.0″) stored in ConfigAdmin, and write some re-usable code that merges these together. True, but what that would give me (today, using Felix/Servicemix), is a Config Admin directory full of files all at different levels and versions. If I have 100 bundles, that could sure be a lot of files :) A more manageable structure is required.

So I naturally looked to Maven as a source of inspiration. It already has a good syntax for a hierarchical structure of artefacts, namely:


[COMPONENT]
---> [VERSION]
---------> [FILES]


So this allows me to store the following:


[ROOT]
---- GLOBAL_PROPERTIES.CFG
---- [MYAPPLICATION]
----------- PROPERTIES.CFG
------------[2.0]
---------------PROPERTIES.CFG


This allows me to keep my three different sets of configuration stored in a logical way.

But sadly, this is only half the problem. When we move from a single server to a multi-node cluster, we likely don’t want to store our configuration under each node – we want to store and manage it in a single place (possibly even protected by Version-Management). One such solution might be to store all our configuration in the structure above on a shared drive, and then “mount” this drive as the “configuration directory” for each node instance. That gets us some way to a clustered configuration, but we still have issues.

In an ideal world (yeah, right) every node in a cluster is equal, and all configured the same. Back in the real world, that isn’t the case. Certainly for the cases I’ve seen so far, a number of things might be configured differently, even for a cluster of nodes:

• Host and port information for callbacks, server URL publishing, etc
• Tuning parameters for each node in the cluster, based on the different loads they are expecting (if the cluster is partitioned that way)
• Configuration for the applications, if they are partitioned to service different subsets of data (geography, users, volume, etc)

Worse still, we almost certainly want the same useful “merging” approach here as we do for our single-node problem; that is, I might have a component for which I typically want to have the same configuration across all nodes in the cluster (CLUSTER_COMPONENT), but with overrides for just a few properties on a single node (NODE_COMPONENT). Same goes for GLOBAL and VERSION-level configuration too:

CLUSTER_GLOBAL + NODE_GLOBAL + CLUSTER_COMPONENT + NODE_COMPONENT + CLUSTER_VERSION + NODE_VERSION = [My Bundle Configuration in a Cluster]

Now of course, this is the WORST CASE SCENARIO for combining configuration, but it’s still very likely. So now, our structure looks like:


[ALL-NODES]
--->[COMPONENT]
-------> [VERSION]
----------> [FILES]
[NODE-01]
--->[COMPONENT]
[NODE-02]
--->[COMPONENT]
[...]


Where “all-nodes” is the configuration that applies across the cluster, and “Node-01″, “Node-02″, etc. is the configuration overrides for a particular node in the cluster. Provided this was stored on a shareable filesystem, this could be the centralised configuration for a cluster. Maybe something like GIT could be then used to easily apply Version-Management to it and deploy configuration on-site?

Finally, a large portion of my design was to support multiple sources of the configuration data. Filesystems, LDAP, ConfigAdmin. Certainly for sensitive or easier-to-manage data, LDAP (or a database) is a natural choice, yet I don’t see a way (that is documented, anyway) in Felix to configure an LDAP source (for example). Certainly nothing that meets my somewhat broad requirements to load multiple sources at once.

So my recent coding-stint addresses all of this into a custom component that we use today. I had a design choice as to whether to position this code underneath Configuration Admin (e.g. our components use CA, CA invokes our code to gather configuration, and returns), or on top (we use a custom bean to request configuration, and that bean uses CA if-and-only-if the requested Configuration is managed by CA). Right now, I’ve settled on the latter, mainly for portability point-of-view. The component today can be used both inside AND outside of the container – it has no hard dependencies on OSGi or CA, and so we can use it for Configuring non-OSGi applications too.

But I’m wondering, has this been discussed/tackled before? Certainly my initial browsing and investigations suggested to me that it hadn’t. I’ve taken a look at ConfMan from OPS4J PAX which seems to at least be looking at a similar problem, but not as broad a scope with the solution.

Probably the most promising option is Fuse Fabric, a product based on Apache Zookeeper, which is starting to work its way into the Servicemix and Karaf products. But I think that, right now, it’s focus is in a slightly different place to mine – albeit an area that I’m likely to be spending more and more time looking at in the future. Fabric is more about the co-ordination of the cluster, which certainly includes configuration, but covers much, much more (upgrading, provisioning, etc). Compared to my approach above (for configuration), it’s much more of a “push” model that an “pull”. In my approach above, each node “pulls” configuration from the central configuration source, whereas Fabric would “push” it. Also, today, I don’t see anything to suggest the level of complexity in the configuration to support some of the use cases I describe above. The interaction seems to be directly with OSGi Configuration Admin, and so it’s deploying single configuration files into CA on each node. That said, I’d love to reach a point where maybe I can have Fabric interacting with my own Configuration component to do the “tiered config” approach, and let Fabric manage the rest – that would be the absolute “sweet spot”.

Lastly, I’ve been toying with the idea of turning this recent work into a separately-named component and opening it up for general use, with the hope that a platform provider like Servcemix might adopt it. Would anyone use it? Would be interested to know what people think.

Dan

It’s fair to say that the bulk of the effort so far has been into running Apollo using STOMP, a text-based protocol which is rapidly becoming a preferred protocol over binary transports like OpenWire, thanks to the modern increases in the ability to quickly parse text (compared to binary) headers.

I use a number of Apache products today (via Fusesource) and was interested to see how Apollo was shaping up, so I read the press release for 1.0 with interest. Then I came across this discussion, via a tweet from Rob Davies, which I’ve only just finished reading. Suffice to say, that like most other areas in technology, there’s no shortage of “competitive feedback” from developers/architects/founders of other messaging brokers/protocols. It’s to be expected, I guess, since anything like messaging is so driven by performance and reliability, and anything which claims to be better than another is going to be met with the usual scepticism. However this forum thread reached a whole new level.

The ‘problem’, as I understand it, is centered around interpretation of the JMS Specification, namely in the realm of “Guaranteed Delivery of Persistent Messages”. JMS API 1.1, section 4.7 states that:

“A JMS provider must deliver a PERSISTENT message once-and-only-once.”

The crux of the issue is that Apollo introduces an optimisation which skips disc writes for persistent messages if the message can be delivered directly to a consumer. That is, if it can successfully deliver the message and receive an ACK, then there is no need to persist the message. All OK so far. Except that it introduces a scenario where the Consumer’s JMS Client can receive a message, but before it has time to respond with an ACK, the broker dies. So technically, we’re in a position where the message has not been “received” (if we’re assuming that receipt implies an ACK). But, because the message was never persisted in the broker, the broker cannot re-send it. So what’s the solution? For Apollo, in this case, they rely on the Producer to re-send the message. Why would it do that? Because, in the case of persistent messages, the Producer waits for an ACK (from the broker) before returning from the call to send() (and hence considering the message successfully sent). If it doesn’t get a successful return to send(), then it should consider it not successfully sent.

The somewhat long debate centered around the fact that the Consumer might “see” a persistent message, suffer a broker failure, and then never receive it again if the Producer dies and never recovers, because the message wasn’t stored on the broker.

So my take on all this? From a Spec point-of-view, we need to agree on what it means to “send” a message, and “deliver” a message, and herein lies the slightly wobbly ground. Personally I think that, in general, it’s perfectly fine for Consumers to only care about messages that were successfully sent. And I think that it’s OK to consider a persistent message successfully sent if and only if the Producer returns from the call to send(). So from a professional sense, I totally agree that Apollo is adhering to the rules and providing users with a solid improvement in performance. Yay! I look forward to reaping the benefits when it makes its way into ActiveMQ at some point.

However, it uncovers an example of where specifications and interpretations can get us in hot water if they are suitably vague. For this optimisation (and probably other situations too), you can certainly make the case that the “Sent” vs “Received” argument above could be considered circular. “When receiving a message, I only consider it valid if it was successfully sent, which will only happen if I successfully acknowledged it, which surely means that I received it?”.

Nevertheless, nit-picking over the JMS Specification (or any other for that matter), is kinda pointless. Ultimately, it will come down to whether a Client Application and Server Application can send and receive data according to their understanding of the rules, and not lose any messages. If a Client does not actually process any messages that it does not ACK, and a Producer always retries messages that it never successfully sent, then I can’t see the problem. If you want to hold a pedantic debate, that’s fine, but it really doesn’t help (or hinder) my ability to write fault-tolerant message-based systems.

So let’s not debate “does it meet (y)our interpretation of the JMS 1.1 Spec”, let’s debate “will it keep my system running as I expect?”. I believe the answer is a resounding “YES”.

http://activemq.apache.org/apollo/

I’d never visited Florida as a child. My parents aren’t the “Disney” type, and whilst at the time it’s always something you think of negatively, I can now fully endorse their position, and even though I’ve grown into an adult that’s visited there a number of times, I’ve always done so without children. I’ve seen my share of exhausted, cranky kids who really are too young to appreciate the experience they’re having. By the time we were teenagers, my Mum had stopped flying and so it fell to a young travelling 20-something Dan to experience Florida for the first time. Since then, most of my trips to Florida have been on the back of work.

One of the more positive side-effects of working remotely is that a large majority of my team are based in Melbourne, Florida. Apart from the good year-round weather, seafood and proximity to Orlando (and Disney), it’s also a short 40 minute drive from one of my all-time favorite places in the world. I am referring to the NASA Kennedy Space Center.

Over the course of my years working for a Florida-based team, I’ve visited the Space Center a number of times, including once with my wife, Charlene. Until a couple of weeks ago, the most amazing visit was to witness STS-129: the launch of Atlantis on November 16th 2009. I was able to stand in the Rocket Garden at the Visitor Complex to watch Atlantis blast off to deliver parts to the International Space Station. I was simply blown away by a number of things: the sight of Atlantis rocketing into the sky, the sound, even from 10 miles away from the pad, and the overriding sense of love and family that each person standing there felt towards both the crew and the craft that was hurtling them into space.

Skip forward to just a few weeks ago – early January 2012. I find out that I’m going to be taking a trip to Florida, so I check (as I regularly do) the Kennedy Space Center website to see if there was anything special going on, and I see…. “Come and look inside the Vehicle Assembly Building!!”. So not only was I super excited to see inside the VAB, where Atlantis, like every other orbiter, was assembled prior to launch, but another exciting prospect loomed. Although not guaranteed, the Kennedy website suggested that, at certain times, a Shuttle Orbiter may be inside, being prepared and decommissioned before getting sent to various space museums across the USA. I book a ticket. Very quicky. Very, very quickly!

Skip forward to Saturday February 4th, 2012. I’m on the “Up Close Tour”, and the guide drops a BIG hint that there was indeed an orbiter in the VAB. I’m a big softy at the best of times, but when I heard that, my heart jumped into my throat and stayed there until I arrived at the VAB. It would be a disservice to the VAB to not spend time talking about it. It’s big. The quote from Douglas Adams regarding “space” in the Hitch-hikers Guide to the Galaxy sums it up pretty well:

“Space is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemists, but that’s just peanuts to space.”

It’s huge. Not only is it huge, it’s simply impossible to shoot. I must have taken 20-30 shots, in an attempt to later stitch them up into some kind of “mega image”. No matter how much I try, I simply can’t. The pipework, scaffolding and large expanses of glass must be the worst kind of surface to try and image-stitch. The best I could manage was this 2-sheet stich using an app I’m trialling called “DoubleTake” for the Mac:..

Okay – so it’s big. The white box at the bottom of the screen is a HUGE door, and the small dark spec in the door is a PERSON!! It stands at a whopping 525ft (160m) tall, and at one point in time was the largest building by volume in the world. It’s easy to see why, and hard to see how anything could beat it!

And there, nestled in one corner, behind a gate, was….. Atlantis. I don’t think I’ve ever been quite so emotional about seeing an inanimate object before. I kept getting something in my eye. That’s my story, and I’m sticking to it…

Some pieces (including the front section), were still removed, being processed and cleaned before being re-fitted. It’s odd, because – as a regular to the space center – I’m used to seeing the replica of the orbiter in the Visitor Complex, next to the Shuttle Launch Simulator. I wonder how many people have walked inside it, thinking that it was a real shuttle. But when you see a real shuttle, an actual craft that’s been all the way out of our atmosphere, and back again, many times, you really appreciate just how much toll it takes. It’s not all white and shiny and glossy. It’s worn and battered. But it stood proud, as if it would have taken another hundred crews into space if it only had been allowed to. And so it initially saddened me, that such a proud machine was now sat there, retired and redundant. Until you remember, of course, that these orbiters are about to become immortal. Preserved for all to see in space museums across the US. And the biggest honor of all? The orbiter that gets to remain in its spiritual home at the Kennedy Space Center? Atlantis :)

I was (thanks to some rather dubious manoeuvring), the first person to get to see Atlantis. I was the last person standing there at the end, still transfixed on the sight before me. On the second request to head back to the bus I grudgingly obeyed…

They say “you should never meet your heroes”. On this case, they were totally wrong. I met Atlantis, and she was awesome.

Dan

I followed some very good tutorials on the Blender Wiki, which contains some great material, so kudos to the guys that write/maintain that site. It walked me through creating a glass texture, setting the right levels of reflection and transparency, and also turning on “ray-tracing” to draw the scene properly. It then walked me through setting appropriate lighting (both ambient lamps and spotlights) to effectively light the scene.

The result is below, and for my first ever attempt – I’m pretty pleased. I’m also becoming much more comfortable with all the Blender controls for panning and moving views and objects. Haven’t decided on my next project just yet – will update this post when I’ve decided…

Thanks to GE’s Long Service Award, I treated myself to a Wacom Bamboo Fun Graphics Tablet. Why did I buy one? Well, I’ve had one before, and used it mainly for sketching out diagrams (rather than spend my day in Visio-Land), and at that time my photography skills didn’t exactly warrant the use of a tablet.

But NOW that my photography skills are improving, coupled with the hundreds of DSLR magazines I’ve accumulated showing me how to improve my photos – I think it’s time I became reaquainted with the tablet. My old one has since lost its stylus (typically), and so I had no choice but to buy another one ;-) I have a ton of photos waiting to be uploaded to Flickr from my recent narrowboat holiday. I’m holding back so that I can test out the tablet, and see if it really makes much difference.

Finally – one of the FIRST things I’m going to do is create a series of graphical banners for this site! I have a picture in mind for each different subject area (Home Page, Photography, Technology, Integration and Cool Stuff). All bar the Home Page will be photography – but I really need the tablet to draw what I want for the Home Page. The signature picture for Pangalactica: A slice of lemon wrapped around a gold brick – as described by the marvelous Mr Adams.

I’ll post again once I’ve received it, and had a chance to road-test it. I’ll try and post in the style of Clarkson. Maybe. Possibly…

Right now, today – there is a certain degree of expection that Business Processes – which are typically quite “step-by-step” – have a visual tool that allows (non-)technical creators/editors/debuggers to Create/Edit/View them. This is fine for Business Processes – their “flow” is typically represented as a “step-by-step” process, with some basic conditional routing. Importantly, typically in a Business Process, all the possible routes are pre-determined. At this level, we can focus our attentions at the service-level – we dont necessarily care where (or how) each service is invoked. So the BPEL “routes” are relatively straightforward in design. Which lends itself well to a “Drag and Drop”-style GUI tool.

So I find myself recently asked a similar question about (Enterprise) Integration Patterns. Because the very nature of these messages are much lower level, they have a much greater ability to create more complex flows. They are concerned with much more “physical” attributes, compared to a Business Process. An Integration Pattern typically DOES care “which server”, “which protocol”, etc. The real problem comes with the complexity of the “flow”. When the flow is conditional, and the possible routes are NOT explicitly stored in the flow, then it becomes much harder to represent this visually. I refer to patterns like Routing Slip, or where custom Java-DSL routes are defined that internally decide how to continue to route a particular message. How can we draw a “chart” of the flow of data through an Integration Pattern, if we don’t know up-front what the flow is going to be?

I’m of course picking on the more difficult EIP’s rather than generalising, but you see my point, right? What good is a tool if it can only (visually) represent some of the patterns?

Despite this, there are already efforts to visually represent Enterprise Integration Patterns. I’ve seen examples of ESB design tools in what was Oracle SOA Suite (not sure what exists today after the BEA/Oracle technology merge). Although the scope of this was somewhat reduced – I certainly didn’t see many Integration Patterns represented in there. More recently the Fuse product team have created the Fuse Integration Designer – which aims to visualize Apache Camel routes, and include other components such as CXF and Spring-based beans. Finally, more recently, the Sun team have been busy working on tooling for Project Fuji – which also looks promising.

But my question is this – how far can this realistically go, and what will it really be used for? How important is visual tooling for Integration Patterns. I can see the benefits to the developer – the ability to quickly “mock up” 50-80% of an EIP project visually clearly saves considerable time. But once that route includes non-visual aspects that affect the route (components that cannot be visually represented) – how useful is it then? Can it still be edited? Debugged? If we are debugging, and the runtime suddenly dives into a pattern we can’t represent, and then crashes – how valuable is this?

My main concern is that it will encourage “sloppy patterns” – patterns that avoid using non-visual components, because it’s easier to stick to the components that can be created and edited in the visual editor.

Or is there really an answer that enables all components to be represented visually? The only solution I can think of is to split EIP’s into “stages” delimited by endpoints. So every single start/end route combination has a separate view. Then a design/edit/view/debugging tool can “jump” from one diagram to another, without losing the context. Clearly for internal java-based errors, we will still need to jump into the code – but it might enable better web-based “first line” debugging to take place to focus the problem onto a particular EIP “stage”, or better still, a particular component…

Thoughts?

This is the result of my first serious attempt to create anything in Blender. Using a combination of Edit and Sculpt mode – I was able to recreate a 3D Model of this “Big Maoi”. The “real” Maoi sits on my desk, is about 12inches high – and doubles as a Kleenex dispenser – although I decided (on this occasion) NOT to render the tissue sticking out of his nose :-) For those that really, really want a Big Maoi on their own desk – you can find it here.

The actual model is constructed from only 2 primitive objects – both spheres. I could probably have created it all using just one – but the neck and base of the sculpture was an “afterthought” – so decided to build it separately rather than mess up my crafted head :) This had an interesting side-effect, in that I could very easily take the 2 primitive objects and export the UV maps into other virtual environments (like Second Life, or OpenGrid) that use UV maps to represent free-form sculpted objects. Finally, the texture is just a free “stucco stone” texture taken from the internet. The real statue on my desk has a very “stucco” feel to it – so it actually suits it very well.

So what are my impressions of Blender? I have to say that even tho I managed to create this relatively easily (after a few failed attempts), there are still some aspects to it that are going to take some getting used to. The most simple of which is that, unlike other packages I’ve used in the past (3D Studio, Lightwave, etc) the controls are very “Keyboard and Menu” oriented. So it took me a while to figure out all the keys just to (a) move my own view about and (b) move objects about in the scene. Once mastered, tho, it’s quite powerful. The only thing I still can’t find out how to do, is control the view of the camera from within the camera view itself – something I was used to doing in other packages. Once I master enough – I’ll create a little “cheat sheet” to stick on my monitor.

However all that being said, I’m relatively optimistic that I’ll be able to continue to further my skills and create more 3D sculptures. My next project is to create something that has multiple textures “painted” onto a single primitive object. I’ll scan my office for the next likely victim :)