More and more companies are using geocoding at some point in their business processes. Geocoding can help companies take smarter decisions by offering customers location-specific services and more. The fact is, geocoding is becoming a go-to resource for those with high hopes of increasing revenue, reducing expenses, and driving up customer loyalty and satisfaction. This is where an API like GeoNames comes into play.
Geocoding & Geotagging
Geocoding is the process of finding associated geographic coordinates (often expressed as latitude and longitude) from other geographic data, such as street addresses, or zip codes (postal codes). With geographic coordinates the features can be mapped and entered into Geographic Information Systems, or the coordinates can be embedded into media such as digital photographs via geotagging. Reverse geocoding is the opposite: finding an associated textual location such as a street address, from geographic coordinates.
In over 10 years of developer experience, I worked for different companies, in different roles, but I always found the same problem over and over again: bug reporting sucks. I spent some time thinking about how to avoid some usual problems in this area and I realize that we could apply the same technique we apply to improve the code: reviews.
Its about time the Web became more event-driven. We have had AJAX for many years enabling events between server and browser, but on the backend we are still polling data. With the explosion of public APIs from SaaS, Social Media and Infrastructure Apps, more and more applications are written by composing web APIs. Developers often need to call a API to get data updates, only to find that nothing has changed. Streaming APIs provide a more elegant solution to polling allowing developers to subscribe to changes they are interested in.
Testing exception handling code is not always an easy task. You either need to setup the external conditions that cause the exception to be raised or generate mocks to get the same results.
A third option is using a bytecode injection tool like Byteman. Using Byteman scripting language you can insert custom behavior into the application code under test. The main use cases for Byteman are:
This is my final post in a series of to ESB or not to ESB articles where I have attempted to shed some light on what an ESB really is and show some alternative architectures for performing integration. I’ve given an overview of four main architectures that I saw most often and provided some context about the benefits and the considerations of each.
An ESB is an architecture, not a product. ESB architecture is best suited for integration projects that include a more than a few applications and plans to role out for even more applications. An ESB architecture is typically selected for strategic projects where the upfront cost of developing the architecture is part of the planning. Pros: Well defined architecture, decouples systems, easy to extend and scale. Cons: upfront cost to create the canonical message and define the message adapter architecture.
In a Hub and Spoke architecture, all systems integrate from a single location; the Hub. Usually, work the hub works with application data formats directly; no canonical message. The state is maintained in a shared database. To scale the architecture, the hub is clustered. Hub and Spoke architecture is a great way to get started with integration, such as a proof of concepts and smaller integration projects or to serve as an integration layer for an application. Pros: easy to get started with. Cons: hard to manage over a few integration points.
API Layer architecture is used to decouple clients from backend systems, which is good for modernizing legacy applications, refreshing existing SOAP APIs, migration of backend systems and unifying data sources. API layer is also used to publish data such as reference data, and lookup data form flat files, databases, even Excel spreadsheets. Pros: decouple systems and creates a common interface. Cons: REST APIs are not easy to get right and hard to change.
Grid architecture is good for high-transactional or data processing tasks that can be parallelized. Having ESB-like capabilities can help feed data into the grid from different sources. Typically this type of architecture is used for processing structured data where as Apache Hadoop would be used for unstructured data. Pros: easy to scale using commodity hardware. Cons: Generally stateless, applicable to a small set of problems.
Architecture then technology
The very first post about when to use an ESB was sparked by people choosing an integration technology before understanding the architecture they needed for their project. Once you have a high-level understanding of your needs, it makes it much easier to reduce the number of vendors to choose from.
Why Mule?
The architectures listed in this blog post series have one thing in common, I have seen them all implemented successfully by our users and customers multiple times. One of the key benefits of Mule is that it was architected to be a loosely couple integration platform that can be wired together into different integration scenarios using configuration, not custom coding. This means your architecture can evolve over time and morph to the needs of your applications and grow as the scope of the project changes.
Light-weight
Mule is one of the smallest integration platforms out there with the fully loaded distribution weighing in a paltry 40mb. It is modular by design so you can use Maven to strip out unwanted modules if you need to reduce the footprint. For me light-weight isn’t just about size it is also the cost of making changes to existing integrations; how much heavy lifting do you need to do to make changes. The Mule run-time offers modularization and super-fast hot deployment as well as a configuration model that makes it easy to re-order and add/change functionality. Furthermore, you get Mule Studio so that you can do it all in a graphical Eclipse environment.
Scaling down
Integration architectures are all well and good but what if you just want to do some quick point-to-point integrations? Mule is lightweight and easily embeddable, it allows you to embed the Mule runtime in your App Server such as Tomcat, JBoss or WAS or just embed it directly in your application or JUnit test case. This is powerful; it means you can create unit tests for your integrations, run on your laptop and incorporate into your continuous build.
Message agnostic
An unsung feature of Mule is the container is message agnostic; this means it does not force XML messages on its users. While XML is common, there are many scenarios where you will want to use JSON, flat files, Cobol Copybooks, binary and file attachments, streams and Java objects. What’s more is that Mule streaming allows developers to process large messages efficiently.
To the Cloud
If you’d rather leave the application architecture, hosting and monitoring of your integration to a company that lives and breaths integration 24×7 then CloudHub is for you. CloudHub is an integration Platform as a Service that gets you up and running in minutes. It offers a multi-tenanted, elastic platform with connectivity to 40+ SaaS, Social Media and infrastructure services and the ability to connect to your on-premise applications. A nice benefit of CloudHub applications is that they will also run on Mule Enterprise and Mule Community, so you are not locked into a commercial platform.
