StackMob recently teamed up with Rackspace, an open cloud company, to help capitalize on the trend.

“Enterprise for the first time is completely rethinking how they are developing applications, which is very exciting because as far as I’m concerned, this hasn’t happened before,” said StackMob CEO Ty Amell in an interview with SearchSOA.

Amell likened the innovation and growth in the mobile ecosystem to the Industrial Revolution.

“If you look at what happened back in the Industrial Revolution, there were standardizations and factories that allowed people to build things like never before,” said Amell. “Fast forward to today and we have a Tech Revolution… we have all of these BaaS providers with niche services, all providing great services and then we have APIs allowing systems to talk to each other. For the first time we have a standard service.”

Furthermore, Amell said the movement is something that won’t take several years to catch on and more to implement, rather he foresees it as a fast-moving market.

The growth should come as no surprise given that data from Strategy Analytics indicates that over the next five years, revenue associated with mobile workers using enterprise business apps will nearly double.

“Mobile workers have moved beyond just mobile email and messaging to include other collaboration apps such as conferencing, productivity apps such as content authoring, and business process apps such as CRM and even ERP,” said Strategy Analytics director of business cloud strategies Mark Levitt in a statement.

Do It Yourself (DIY) television shows have proven popular with audiences, but the same “I can save myself money by doing it on my own,” mentality that makes for good entertainment, may not be so amusing when it comes to OSGi server runtimes.

During his lecture, Ward talked about how those who enjoy DIY projects will like OSGi because it’s all about modularity. “It’s very easy to build a server runtime from a freely available piece,” he said. “OSGi makes it simple to reuse components, but do you want to do this?”

If an application architect decides to go the DIY route, there are several options to choose from. Among the platforms are: Eclipse, Apache, Aries, JBoss, GlassFish and IBM Websphere, explained Ward.

There isn’t a cut-and-dry answer to what features should be used. Just like the many aforementioned platforms, each scenario needs to be looked at independently.

Ward advised session attendees to ask themselves, “What do you want from your runtime?,” he asked. “You need to answer this question first. Is it a development stack for playing around with?”

Ward also advised people to consider the following:

- Do you want to learn? You’ll gain the most knowledge if you build it yourself;

- What kind of time do you have? You’ll make the fastest progress using a pre-built offering;

- Is it a small/medium reduction system with a small feature set?

Even though each situation has its own circumstances, there are some general rules to follow. Ward suggested that for those creating an application that needs a lot of features, building their own runtime isn’t a wise decision. He asserted that in such a scenario, developers should save themselves time and pick a pre-built runtime that offers the necessary services.

Another situation where building a runtime can also be a poor use of resources is when an application needs to run on three or more nodes. Again, Ward said this is a scenario where it’s better to fork over some cash. The combination of deployment, management, and monitoring will be big issues.

Ward’s closing piece of advice was this, “Mostly, pick an option that’s designed for your requirements. The number of people who don’t do this is crazy!”

During a EclipseCon 2013 session March 26 in Boston, Sinha cited some pretty staggering statistics. Among them was one he attributes to IBM, which says up to 90% of a developer’s productive time is spent trying to understand code.

Devoting even half your time unraveling a mess of code can be daunting, admitted Sinha, but that doesn’t mean developers should try to reinvent the wheel. Rewriting code can be costly and time consuming. Instead, he offered some pragmatic advice that starts with building architectural maps. It’s not uncommon for team members to have different pictures of a project’s main components.

“Even if you have 100 developers, get the team leads into the same room,” Sinha suggested. Armed with old-fashioned paper, the participants should document the top components and connections between the components. “I’m essentially saying; try to get them to merge their ideas.”

This exercise helps make sure everyone is on the same page. “The first time we did it we split the things we agreed upon,” said Sinha. “We had a whole list of things we needed to think about the next time. One hour and we had that.”

Writing on a whiteboard may also prove beneficial in helping people understand a system. Sinha noted how people in his organization began to plan around what they saw on the board.

With everything clearly documented, the team will have a more central view and will have an easier time obtaining necessary information down the road. “If you are writing any new code, you are not putting it in the wrong place,” said Sinha.

While untangling the web of code implemented by someone else may seem like a thankless task, it’s important to remember what you are doing can be extremely difficult. Setting aside time on a regular basis, whether it be at the personal or team level, for fixing is also important.

Sinha offered another commonsense tip: celebrate your successes. Even the smallest victories are meaningful as they can be used as stepping stones towards long-term goals.

Want a challenge? Add the avalanche of enterprise mobile applications to DevOps teams’ already-daunting integration workload, Paul Kopacki says. He’s Sencha’s vice president of marketing, which just released a mobile app integration tool for developers.

Last week, Sencha Inc. of Redwood, Calif., released upgrades to its product line designed to make HTML5 development more simplistic. The company’s core offerings–Sencha Architect, Sencha Ext JS and Sencha Touch–have been enhanced to make it easier to quickly build HTML5 applications for any platform. A new touch bundle for mobile developers was also launched.

Among the key upgrades to the Sencha ExtJS product is a big-data grid. “There are many more data points people want to build into their applications,” Kopacki said in an interview. “Big-data grids are one of the things customers are asking for and we are delivering in this release.”

Financial data companies are among those who rely on the technology on a daily basis. One Sencha client used the technology to build an app for bond traders. The client company, which tracks a great deal of information, needed greater capacity to take the data and share it with its bond traders in a faster pace.

Online accounting software company Xero has also embraced the technology. The company’s CTO, Craig Walker, said a few years ago that he realized Xero wasn’t delivering a positive mobile experience. “Our experience had been with native development and we wanted to move to Android, etc. The mobile touch framework delivers a lot of functionality up front,” he said during an interview. “What would have normally taken us six to nine months took us three.”

While there has been some debate over HTML5, Sencha has a clear stance on the technology: It’s a big proponent. In fact, the company recently developed a copy of the Facebook app to show that developers, not HTML5, were the issue when Mark Zuckerberg abandoned the markup language last fall.

“Some people come to HTML5 from a web perspective and fail to see the power of HTML5,” said Kopacki. “If you come at it from an application development perspective, you use the right tools so that HTML5 is powerful, especially for business applications.”

While the debate over HTML5 is sure to rage on, at least for now, some companies are banking on its ability to quickly aid programmers as they integrate old systems with new technology.

Running through the history of computing is a quest for modularity. We curse it when it doesn’t work; we take it for granted when it does. Long ago, software engineers began to seek the equivalent of Lego bits, software modules that could be swapped much like bus boards on a hardware backplane. It’s been a long strange trip.

Modularity has gone through various stages in the modern era, with objects, components and, then, services, coming to take the place of Lego pieces in the software world. But, even in one of their (somewhat) recent iterations – that is, the services-oriented OSGi Service Platform – the mechanics software module interaction is not easy for developers or architects to master.

“Java Application Architecture” (Prentice Hall, 2012) by Kirk Knoernschild is one of the more probing books you are likely to find on this subject. Before the year past is very far past, I would like to take some time to discuss the book , as it is one of the better ones I have read lately.

The book has a straightforward principle, which is to provide guidance for those who might set out to design modular software. In Knoernschild’s terms, it looks at ways you can “minimize dependencies between modules while maximizing a module’s potential reuse.” This is, one, a major goal of middleware; and two, a long-time holy grail of software development.

While much of the book portrays garden-variety java problems, a fair amount of “Java Application Architecture” which is subtitled ‘Modularity Patterns with Examples Using OSGi’ also has a helping of OSGi know-how.

A conversation with Knoernschild disclosed that the book arose from an initial interest in uncovering how to leverage different layers of abstraction – to reach a deeper understanding of software architecture, and gain ease of maintenance. Composition of “Java Application Architecture” happened over many years, and there were discoveries.

“Along the way, the book morphed based on me learning more about how to design large software systems based on the Java system, with JAR files as the principle unit of modularity. Then, in the 2006 time frame, I discovered OSGi,” said Knoernschild, “I started digging into OSGi.”

He said he found the ideas of OSGi meshed with his own ideas about Java modularity in general. OSGi, for example looks at JAR files as the main means of re-use, treating a JAR file as a first class citizen. In the book, he explains how to take a monolithic application, modularize it and eventually bring it under the control of OSGi.

At heart, the issues Knoernschild addresses in “Java Application Architecture” are about dealing with complexity. Like Fredrick Brooks’ work, you could say Knoernschild’s effort is to separate the accidental complexity from the essential complexity. His thoughtful look at Java modularity is more than just tools and tricks – it is a foundational framework for thinking about problems of software architecture.

“Designing software is hard. It’s hard because breaking up the systems is so difficult,” said Knoernschild. OSGi’s detractors still argue that it, in itself, in fact, is too difficult. But experience tells us things are hard for a reason, and while the general drive of software is to make things easier, it is a daily battle to effectively simplify the complex. Knoernschild’s book, fights the good fight, and could become a valued companion at many developers’ bench tops. All and all, it is a brilliant breakdown on modularity.

“It is a fact that the number of APIs grows by the day and, with the explosion of mobile applications, APIs will be used more and more in the future,” Malinverno told a crowd at Gartner’s Application Architecture, Development & Integration Summit this week in Las Vegas.

He noted that daily API calls have skyrocketed into the billions for many well-known companies. Facebook, for example, saw 5 billion API calls per day in October 2009, while Twitter had 13 billion per day in May 2011.

“These companies better know who is calling,” cautioned Malinverno. “They better know how many calls per second they have to field, and they better know what sort of elasticity they need to demand from their cloud platforms to ensure that whoever uses their API is able to use it properly.”

API management is the way to do that, he said. Without it, businesses may lose out on value in their services and their APIs.

“API management is about making an API available on the Web for everybody that you want to use the API—enabling them to call it and get the result they want,” he explained. “Not everybody feels they need API management, but they do. The assessment of the value of the API is a part of API management.”

Malinverno also noted that SOA governance and API management are very closely tied—perhaps even the same. He said SOA governance is “the ability to link a specific intent of your business strategy to the way you develop and operate services.” He advised his audience to build a strong SOA governance strategy together with API management, to create what he called “application services governance.” -Stephanie Mann

Among other things, the anticipated Axway/Vordel suite aims to enable mobile access to legacy data, and provide end-to-end visibility from cloud to on-premises. Axway also noted that Vordel’s products will become central to Axway’s existing suite, and Axway customers can expect immediate access to Vordel services.

For Axway, added security capabilities are key, according to one viewer. Blogging on the acquisition, Forrester Principal Analyst Stefan Ried wrote,”the more the boundaries of an enterprise are extended by integration offerings, the more a federation of security becomes important.”

Elsewhere, Mark O’Neill, co-founder and CTO at Vordel, took to his blog to comment on the news. “Vordel’s products, from Day 1, have been to enable B2B traffic on the Internet,” he wrote. “This is a perfect fit with Axway, with its heritage in Managed File Transfer (widely used for B2B) and B2B platforms.”

The acquisition follows on the heels of Vordel’s news in July that it added an API server and a cloud service broker to its application gateway offering. That decision was driven by the need to come up with an API lifecycle package meant to improve the REST and JSON experience. 

–Stephanie Mann

By way of example is FatFractal, a San Francisco-based BaaS provider that launched just this week. The company describes its product as offering native code support for any connected device, along with an events model and declarative security. FatFractal also says it integrates all of those components as lightweight services.

While it may be the newest BaaS player, FatFractal joins a slew of companies already in the field. Its competitors include StackMob, Kinvey, Applicasa and Parse.

Central to FatFractal’s approach is a NoServer module, which takes JSON requests and handles them via a script execution engine and a Create, Read, Update and Delete (CRUD) engine.

FatFractal CMO David Lasner thinks the new approach is needed. “It’s just hard to do a backend in the cloud and make it work,” he said. “The nature of applications is changing and you’re getting thousands of applications that use a lot of data.” – Stephanie Mann

The JBoss EAP 6 is said to provide developers with “a high-performance, low-footprint, easy-to-manage solution designed to help enterprises build applications and ease into the cloud.” Representatives from JBoss and Red Hat touted the new platform’s cloud centric nature, lightweight pluggable architecture, malleability, multicore and virtual systems optimization, upgraded middleware components and the fact that it supports Java EE 6 as well as JVM languages such as Spring, Struts, and Google Web Toolkit.

On the data side, JBoss Data Grid 6 is Red Hat’s offering for dealing with big data issues. “The massive proliferation of data places new demands upon enterprise applications… Red Hat JBoss Data Grid 6 brings a new approach to solving this issue, enabling enterprises to move with agility and with more flexibility than other proprietary approaches.” Explains Craig Muzilla, vice president of middleware at Red Hat.

He and other spokespeople put a number of features of the new system on parade, including its NoSQL approach, real-time application support for big data, flexibility of application integration, high scalability, high availability and fault tolerance. This is said to allow enterprise customers to build an open cloud that can integrate resources from various vendors and maintain a shield against lock-in to any one vendor.

Looking at the third new product in their trifecta, Red Hat claims that CloudForms provides enterprise IT organizations with the tools to build a hybrid cloud infrastructure that will deliver self-service computing resources to end-users, but without giving up control.

Rob Terpilowski, lead Java developer, Lynden, Inc., explained how he and his team used Apache MQ messaging middleware and other open source messaging software to replace homegrown tracking software. He said the original tracking software was built to overcome immediate needs without consideration for later modernization or integration requirements. Terpilowski described the project in a session titled “Building a reliable messaging system for an unreliable (and diverse) world” that took place as part of the CamelOne conference last month in Boston.

The challenge was to combine disparate systems including a decades-old pre-relational database platform, Solaris 10, Glassfish application servers, both graphical and green-screen user interfaces and barcode scanners that are embedded devices running on Windows CE.

One of the major reasons the old homegrown system needed to be replaced, according to Terpilowski, was that it couldn’t scale up to meet the shipping company’s growing needs. The polling system that was in place ran into issues with growing database load and with endpoints getting overwhelmed with irrelevant data. Terpilowski and his team were able to add messaging via Active MQ and an additional MQ table that the existing system would write to, keeping the inflow of data fairly consistent. But the flow of data back out to the endpoints went from a constant pull of large amounts of data to a much more targeted push of relevant data via Active MQ and location-based topics.

There were also challenges associated with intermittent Wi-Fi connections at storage and freight routing facilities where workers with barcode scanners would constantly move in and out of thick-walled storage containers, breaking the connection. Early efforts at overcoming the connectivity issues centered on a .NET failover system on the devices themselves, but that failover system was deemed non-optimal.

Eventually the team decided on rolling its own proxy server. The main purpose of the proxy server was to maintain connections on behalf of the endpoints as they appeared and disappeared, and then close out the connection properly when it was appropriate. With the messaging proxy in place to handle connectivity issues, Terpilowski’s new system was able to monitor proxy related statistics, summarize client information and reset a client’s connection to the system when necessary.

Stay tuned for more on embedded middleware issues. Let us know about your experience with open source messaging software.