A recent report by OpenSignal revealed that there are 18,796 distinct Android devices in use. This data was gathered directly from users who installed the company’s app. Even though device fragmentation is not a new phenomenon in the Android world, the sheer number of devices is impressive (up from 11,868 devices counted last year).
In a previous blog post (http://ig.obsglobal.com/2013/09/mind-shift-necessary-when-adopting-oracle-fusion-middleware-part-1/), I talked about the how, with a slight adjustment, we can apply most SOLID principles to Oracle Fusion Middleware design and development. I also alluded to a third hurdle, which is working with limitations.
Have you ever wondered what happens to all those useful little tools that were created as by-products within a project? Tools that facilitate the lives of their developers or source code that solves a particular problem? What usually happens is that those creations eventually sink into oblivion once they’ve served their purpose.
A couple of years ago, Online began an Enterprise level project with multiple vendors and a total team size of over 500 people. Oracle Fusion Middleware had been selected as the implementation technology. With 14+ years of development experience in traditional development languages such as C\C++, Delphi, C#, and Java, I approached this new technology as I would any of the other languages I’d learned. I attempted to apply SOLID principles and in doing so, realized that there was a mind shift necessary to successfully achieve this goal.
If you are like me and have embraced Eclipse as your preferred IDE for dabbling in various java related frameworks, you have undoubtedly run into a situation where Eclipse is no longer happy. Either from slowing to a crawl, or the Scala plugin is complaining while you are trying to do Android development or one of many other possibilities. Besides, why do you want the overhead of the Android plugin when you are working in Scala, or the svn headaches when you are using git?
Previously on “Open Source ESB Search”
- Who we are, what we do, what has changed, what are we required to do for our customers, and how do we want to do it… (see our first post at http://ig.obsglobal.com/2013/06/open-source-esb-search-introduction/)
Today, on “Open Source ESB Search”
- Ramping up our Open Source ESB Implementation
What are the current, mature, best of breed Open Source ESB offerings?
- JBoss – the most mature, but lacks a development paradigm that allows for TDD using any IDE. Arquallian provides some support, but not ready for production. Operational support offered by Red Hat.
- Mule – lower level DSL’s that feel dated. Less testing support. Operational support offered by MuleSoft.
- JBoss Fuse ESB – nice aggregation of common tools available to Java or XML DSL. Seems to be the “simplest thing that works” while covering 40+ EIP’s. Operational support offered by Red Hat.
- Spring Integration – provides EIP and generally very good, but would still require container support. Operational support offered by VM Ware.
- WSO2 – has matured recently, but seems to require more current development than other projects that reuse other OSS components. Operational support offered by WSO2.
Which ESB scored highest? Which feels like the right fit?
- Fuse’s features combined with the ability to “upgrade” to the full JBoss stack without losing support swayed the decision in favor of Fuse. JBoss is in the process of applying other JBoss tooling to the Fuse environment. Operational support available via Red Hat may be offered to our clients on a deployment-by-deployment basis.
- Previous investigation resulted in positive feedback with Fuse ESB’s leveraging Camel’s DSL.
- Fuse ESB’s use of CXF to publish web acceptors is familiar to each project developer.
- Red Hat’s Linux offerings position us to deploy to either a free or an enterprise OS while staying within the same support proposition.
What due diligence did we perform?
- Evaluated each Open Source ESB for platform openness, community involvement, upgrade paths, development support, and many other concerns.
- Investigated possible Red Hat partnership.
- Became a Red Hat partner.
- Attended Camel One.
- Attended Red Hat Summit.
- Investigated sample and example code for quality.
- Performed gap analysis between the ESB features and our first project’s requirements and non-functional requirements with an eye towards system expandability and flexibility.
Where are we now in the process?
- We have a system architecture and design.
- We are validating our system architecture and design against the Fuse ESB.
- Help desk has built out three virtual machines – as defined by our system architecture; we require three virtual machines to validate our failover, tracing, and lost-less message non-functional requirements.
- We started a bit of an “Iteration Zero” and spike iteration. As an Agile shop, we demand customer-usable software features delivered in each and every iteration starting with the first iteration. For this project, we have a bit of time before the client is ready to consume any deliverable, so our Delivery Manager is the customer stand-in.
What are some of the next steps/posts?
- Further Discuss the Problem Domain
- Map the Solution Domain onto the Problem Domain
- Discuss Testing Tools and Techniques
- Discuss our ESB Ecosystem and Topology
- Enumerate ESB Acceptors and Message Canonicalization
- Conclusion and Postmortem
Cloud Foundry is an open Platform as a Service (PaaS), which is developed and operated by VMware. (VMware is also the company that operates the Spring Framework.) Cloud Foundry is an Open Source project available through a variety of private and public Cloud distributions. It's written in Ruby, but intended to host any language or any other component.
This post begins a series that will share Online’s Portland office's experiences as we re-platform from a Sonic ESB Architecture to a more open ESB architecture for our Justice and Public Safety solutions.
In the beginning, if the business needed an application built, they went to the IT department, participated in a pleasant Waterfall SDLC and eventually had a shiny new application sitting on the Mainframe.