I’ve decided to do a bit of a “deep dive” in to the Fuse ESB, which is now owned by Red Hat, to upgrade my technical skills in this area. I’ve actually ended up using a product called Fuse Service Workbench instead of this and will eventually do a post similar to this on how to install it. The directions given here will work though if you want to set up “Basic Fuse” along with the Developer Studio.
One thing I have discovered (by getting FSW up and running) is that due to various bugs in Oracle’s JDK 1.7 on Apple – you should use it, at least for this. Instead, you need to use Apple’s JDK 1.6, making sure that you set JAVA_HOME to the real path, not a symbolically linked one (of which there are many). I’m assuming 1.7 is OK on Windows (as the doc says it should be) – feel free to let me know your experiences in the comments section.
For simplicity, I’m using the RedHad FUSE ESB which includes: Installers, Testing, Performance, Third party verification, Centralized management of uniquely configured brokers with Fuse Fabric and Incremental patching. It’s a 30 day trial, but I’m just using it for the quick and easy installation.
1. Install JBoss FUSE Beta (6.1)
Get it from http://www.jboss.org/products/fuse, unzip the file, uncomment the (last) admin user line from etc/users.properties:
and start the ESB, so you should get something like this:
JBoss-FUSE rwest$ bin/fuse Please wait while Fabric8 is loading... 100% [=============================================================] _ ____ ______ | | _ \ | ____| | | |_) | ___ ___ ___ | |__ _ _ ___ ___ _ | | _ < / _ \/ __/ __| | __| | | / __|/ _ \ | |__| | |_) | (_) \__ \__ \ | | | |_| \__ \ __/ \____/|____/ \___/|___/___/ |_| \__,_|___/\___| JBoss Fuse (6.1.0.redhat-328) http://www.redhat.com/products/jbossenterprisemiddleware/fuse/ Hit '<tab>' for a list of available commands and '[cmd] --help' for help on a specific command. Open a browser to http://localhost:8181 to access the management console Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown JBoss Fuse.
As mentioned above, you can then go to http://localhost:8181 and login
which should give you the welcome screen!
Congratulations – you’ve almost got FUSE running as what you have at the moment is a Fabric, which is kind of like a ‘mini cloud’
Now you should shut FUSE down using
JBossFuse:karaf@root> osgi:shutdown Confirm: shutdown instance root (yes/no): yes JBossFuse:karaf@root> JBoss-FUSE rwest$
so you can …
2. Install JBoss Developer Studio 7.1
Get it from https://www.jboss.org/products/devstudio.html and just open it – as it’s a jar file, on a Mac (which I use) it will just run the installer:
If you’re on a Mac, then the JVM/JDK will probably be set to your browser’s JVM, which is not correct – it should be set to your JDK. In the case of Apple, it should be 1.6:
>> TODO: Update Diagram Below
Contrary to the screen above, you can use the “Visual Page Editor” on a Mac if you do a 32-bit installation. At the end you can then start the IDE and at a minimum you should install all of the “Integration Stack” items as some of these work with FUSE:
and there’s some pretty cool stuff such as support for Rules systems like Drools and Guvnor. You’ll probably get a warning about “unsigned content”, but that’s just someone (in Red Hat) being lazy.
After the installation, JBoss DevStudio will want to reboot and then you’ll be right for development with FUSE which we’ll cover in the next installment…
NOTE: Still a bit more updating to do, but most of the above should be correct.
I started programming in Java a few years after it was released. I had been doing C++ for a number of years and just come off a C++ project which failed because they (who were a pretty good team of programmers) couldn’t scale it because of the two common killers: Threads and Memory Management. Near the end I was reading James Gosling’s original paper on Java which addresses the major problems of C++ and explaining how Java addressed them. I was obviously quickly sold! As a result I spent over a decade programming in Java and J(2)EE, in the beginning implementing (mostly web) projects way faster than the “C++ laggards” could.
Now, I’ve been doing Solution and SOA Architecture, occasionally whipping up a prototype in Java, or doing some Perl but quite often working with WSDL, XSD’s and just plain models. Recently though, I’ve been playing around with Clojure in my own time and am amazed at how much fun it is. It really reminds me about my early experiences with Java, but that would be the subject of another blog post…
Recently it has struck me just how many languages have versions or been constructed to run on the Java JVM. A list from Wikipedia shows:
- Clojure, a functional Lisp dialect
- Processing, a visualization and animation language and framework based on Java with a Java-like syntax.
- Groovy, a scripting language
- Scala, an object-oriented and functional programming language
- Xtend, a statically-typed language sitting on top of Java
- Fantom, formerly known as Fan
- JavaFX Script, a scripting language targeting the Rich Internet Application domain (discontinued 2010)
- JRuby, an implementation of Ruby
- Jython, an implementation of Python
- Armed Bear Common Lisp, a full implementation of Common Lisp
That’s quite a few languages! What’s more, a number of them have plugins to an IDEs such as IntelliJ or more commonly eclipse. It struck me that these languages were effectively using Java and often IDE’s as a runtime / development platform, much like many high level languages used C.
Which begs the question – where is Java headed in the long-term? Yes, they’re adding Lamda’s in Java 8, but why would I want that when I can work with Clojure which has had this from the beginning and has a whole bunch of good extra stuff… Is it destined to become a “low level language and environment” upon which more sophisticated languages will be built?
This post is the result of a tweet to @flowchainsensei about a month ago about Scrum projects, where I said I really should blog about my experiences in “Agile Land”, so here it is:
My “Agile background” began back in 1997 (yes, I know that was technically before Agile began) when I started reading about iterative development and was on a project where the management was getting a bit “edgy” about the project and its delivery. It was a large organisation, with too much money and a lot of politics. At the time I was the lead for a sub-project which was responsible for the back-end interface and I recommended to the overall lead that we set up a server and do weekly or bi-weekly deployments on to it, so at least people could see the good work that was being done. Unfortunately, he was a “waterfall guy” and completely ignored the suggestion…
In the mean time, I came in to contact with the “useability people”. They had the whole setup (which was unusual at the time) with multiple cameras, mirrored windows etc… I didn’t use that though, instead using one of the early Java GUI builders to rapidly prototype interfaces which I then printed out (their (great) suggestion) and talked through it with them. Yep – that was paper prototyping and it worked well. Eventually after a number of major re-designs and total restructurings we ended up with something that seemed quite reasonable so we started using that for our weekly sessions. It was working against a set of “Mock Object” interfaces (we used to call them stubs ;) that people could play around with, so we’d go through various scenarios.
In the background, I had the team of 4 working on the connectivity to the main system as we knew the information that we needed to maintain, just not the visual interface and we adjusted things as we went along and sync’d with any minor updates to the data model, which was against an Object-Oriented (oops, NoSQL nowadays) database. Finally, we ended up with an interface that everyone was happy with. In fact the Users said it was the best internal maintenance system that they’d ever used! For me, as a contractor, it was off and on to the next big thing as I’d built and successfully deployed my part. Unfortunately, for the project, it was cancelled a few months later as they’d never demonstrated much of their (front end web) functionality to their users and the whole project was canned only a few months before they would of finished!!! That’s in a 2 year project, because they thought the waterfall model was fine – what’s wrong with demonstrating a 2 year development project after 2 years? ;-)
For me it was a huge lesson – there seemed to be something to this “iterative development” and I was curious . . . I can’t remember exactly what I was reading around then, but I think it was mostly around the RUP and I remember Royce’s book on “Software Project Management – A Unified Framework”. About a year later I was bought on to a project that had a fixed deadline, which was going to make or break their funding. People were just generally freaking out because it seemed out of control and no-one really knew what to do. Using what I’d learnt so far, I suggested we write down all the product features that had to be built and prioritize them, paying attention to put the “risky” ones first (as that’s a key rule for RUP). We had about 2 months and I think we had about 30 product features. Funny thing, is I remember keeping the list on a whiteboard where we’d cross them out when done and make any key notes regarding them. This was about 10 years before I learnt about Scrum – the only thing we were missing was the moving of stickies, but still it was an “information radiator”. Apart from the first week planning, architecting and prototyping technologies, for the most of this project I was really a coding architect. The other thing we did was weekly demos (it just seemed natural as we only had two months to complete this, so even a monthly iteration wouldn’t of made sense) and discussed the progression of the project and adjusted any estimates for the features as we progressed. In the end, we built about 25, but obviously the remaining 5 were really “nice to haves”. Another job successfully done and on to more projects, but you’ll have to wait for the next Iteration of this to hear about that . . .