With standard Java and standard Java servers, fairly strict and familiar three-tier architecture came about. The question to ask now is “Will it last forever?” Like so many things, the fundamental tiers of computing do come up for reconsideration once and a while.

These breezes have been blowing subtly since people cast about for lighter versions of Enterprise Java Beans. More recently, Node.js has arisen as a JavaScript alternative to Java on the server side. Increasingly, the client is the object of interest.

Node.js and other browser-influenced technologies seem to encourage software architects to cast skyward their monolithic three-tier components. As these flying components drift down to earth, they may not settle back up in the same alignment. The sudden near-hegemony of mobile clients is pushing things ahead quickly.  A variety of new architectures are brewing.

In some ways, there seems a growing reaction to the rule of Java and the server. That view emerges from a look at a reporters’ notebook. It’s not going away, but as described in an interview with James Strachan, now senior software consultant with JBoss: “The server side is becoming thinner and thinner.” When SearchSOA.com and TheServerSide.com spoke with Strachan earlier this year at the CamelOne event, the topic of Node.JS was on the docket, but Strachan was expansive.

He said, looking forward:

The server side might just be Amazon Simple DB or Mongo DB or something; there might not be much of a three-tier architecture anymore.

Meanwhile, with flair, he continued:

….the client side is becoming bigger and more and more complex; it’s real-time now, everyone’s doing Ajax, real-time updates, and people are doing lots of single-page applications – which is when one Web page starts up and the entire app is in there. There are lots of models, containers, relationships and persistence and “yada-yada.”

Strachan notes this is highly driven by mobile applications:

In many ways the browsers won. Almost every mobile platform has Web capabilities inside it – Android, iPhone, iOS all have Web browsers and so forth. So the Web has kind of won … most browsers use JavaScript and HTML 5. Silverlight’s dead, Flash is kind of dying … the browser is really where it’s at …  with HTML and JavaScript.

Are the new approaches overblown? Is real change far off? Do you see a shift in emphasis to the client? If so, do you think services or SOA have had a hand in breaking down the status quo? -Jack Vaughan

@searchsoa

Recent weeks have seen clamor in the ranks of the OAuth API standardization effort, as well as a high-visibility launch of an alternative to Twitter APIs. In the first case, an OAuth originator took exception at changes proposed for Version 2.0. In the other case, a West Coast start-up took on Twitter, promising a non-ad-supported social media platform based on an open Web API. A sidebar to all this is the earlier craigslist mini-brouhaha surrounding its attempts to close up its data listing URLs that are being repurposed by Web API-wielding third parties.

Over the weekend, the potential Twitter alternative known as App.net garnered considerable attention by enlisting developers at as much as $100 a pop to sign up for its paid mobile app service. The company had well exceeded its $500,000 seed goal as of August 13. On one level it can be seen as an effort to enter the void caused by Twitter’s recent back-tracking on some of its API openness. On another level App.net can be seen as an affront to Twitter’s growing reliance on advertising for revenue.

It was in the wake of Twitter’s efforts to ensure that its APIs maintain a “consistent set of products and tools” that App.net co-creator Dalton Caldwell blogged about what Twitter could have been. (He’d early attacked Facebook.) He saw the Twitter API originally as a real-time protocol, one that became tainted by Twitter’s advertising model. Subsequently, App.net launched its online promotion,  which seemed somewhat akin to crowd-funding undertakings such as Kickstarter.

Dalton Caldwell, who began his career at SourceForge, has seen the upside and downside of technology. His present company, Mixed Media Labs has focused increasingly on its App.net developer store, now pitched as a social platform, as backing has run out for its Picpiz picture sharing site, now shut down. In effect, he has ridden the swells of the open API trend, and found a way to get mobile app developers to pay to be part of the App.net effort.

These doings – both Twitter’s and Mixed Media’s – don’t much clarify the trajectory of that recently born technology known as the open, Web or public API.

An era of an open,  programmable Web may come about if non-commercial standards can be agreed to. Oauth 2.0 will provide a testing ground for that. But, Caldwell’s App.net does not forgo commerce altogether – his business plan merely pledges to forgo advertising commerce.

It is early for open APIs. Companies that use Web APIs as part of their business will no doubt take a one-step-forward/one-step-backward approach. They will be eyeing the open API effort but continuing to use Twitter APIs where appropriate. What do you think?

Few application development managers are not affected by the mobile tsunami. They are now sorting through the costs and benefits of a new category known as mobile middleware, which has arisen to deal with mobile device diversity. As it turns out, mobile apps are a bigger problem for application development managers than was mobile email. They have to support every conceivable type of endpoint, and select between HTML5, native and hybrid programming schemes.  

The PC was a game changer. The same appears to be true of the smartphone, which recently crossed an inflection point, surpassing the desktop PC in unit sales. Equal as influences are social media, open APIs and app stores.

Social media applications that aggregate news and information have caused a big boost in use of integration middleware using “REST” and RSS-style services. SOA laid the foundation, but it is the simple REST version of SOA that is carrying integration development forward today, as seen in social media and mobile application development. Basically, REST underlies the big digital consumer success stories called Amazon, Google, Facebook and eBay, and their style of development is now penetrating the established enterprises, and software architects must understand how to build these modern style systems.

Now we are seeing a type of consumerization of IT integration that resembles the open APIs of the big e-commerce and social media sites. The idea is that you publish out APIs that let outsiders hook into your Web versions of your enterprise applications. Some SOA houses are building API management tool sets in response. They want their APIs for B2B to fly off the virtual shelves as the MP3s do at the iTunes store with which consumers are familiar.

Consumerization of SOA integration could be taken more broadly still. Seldom when you are calling, are operators actually standing by. The Web has enabled – some might say ‘condemned’ – the consumer to take over the role of key operator of yore. This requires teams to design and deliver much better applications and application interfaces than ever before. This is becoming more and more true as mobile devices flourish.

Again, aspects of the “new” consumerization of IT can sound like an old story. The notion that end users can, with the right tools, manage to meet the bulk of their programming own needs was heard in the days of the original Visual Basic, Lotus Notes and PowerBuilder. To a point it was true. We hear that now about open APIs. Is it more likely to be more true this time? What do you think? -Jack Vaughan

Why? Apigee’s recent report, aptly titled “Developers Hate Marketing: Attracting Developers to APIs,” puts it this way: “Developers live in the world of the tangible. They want to see their apps used by people. They have a keen eye for anything that sounds like vaporware or shelfware and are extremely cynical about marketing.”

That said, Apigee does outline an alternative API-promotion strategy for attracting developers. Three main points stand out:

1. Build a developer community. Instead of talking at developers, show them what they want to see. By building a developer community that speaks to the needs and ambitions of the type of developers you want to work with, you better your chances of attracting the right fit of developer for your project.

2. Know what developers want—and supply it. According to Apigee, developers want to build useful skills, raise their visibility among other developers, use effective tools and—unsurprisingly—to make money. Providing what developers want is an obvious necessity if your business wants to attract and retain ambitious developers to work on your API.

3. Make developers part of the team. Another big takeaway from the report deals with the way companies treat developers. Traditionally, outside developers have been viewed as consultants. Today, a landscape driven by open source trends is demanding developers be treated more like customers—or even partners. As the report puts it, “Developers become a channel for new types of business that you wouldn’t or couldn’t pursue yourself.” As such, they take on a vital role that brings them into the folds of an organization on many levels.

Clearly, the first part of building an API—figuring out how to expose a service or product—can actually be easier than the second part—that is, getting developers to actually use it. That has always been true to some extent. But, in the era of open APIs, the story has a new twist. – Stephanie Mann

On the current state of APIs—and how they compare to old-fashioned SOA— Farquharson said:

I like the fact that APIs are simpler and more accessible. I like the fact that APIs are more community-oriented. A developer is far more attuned to a Facebook-like experience of collaboration than a UDDI registry. I like those kinds of trends around API management. I like the fact that discovery is completely revolutionized. I think the security mechanisms are simpler, and it remains to be seen how complicated things are going to be over time.

He added that new shifts in API management are shining a spotlight on developers:

I don’t think SOA was ever focused on the developer. API management has driven some focus toward the developer. The business likes this because the developer…is probably building some cool apps that are going to make them some money. It’s nice and neat if you look at it from that perspective.

Read more about our discussion with Farquharson here: Farquharson on API management: “Focus on business-developer relationship”. –Stephanie Mann

Giuli, a technical expert at Ford Motor Company’s Research and Advanced Engineering organization, recently told EclipseCon 2012 attendees in Reston, Virg. about OpenXC platform.  It is, he said, a joint effort of automaker Ford and embedded tool maker Bug Labs. The OpenCX platform is intended to produce a standard way of connecting aftermarket software and hardware for cars and trucks.

OpenXC is an API to the car. It requires installation of hardware components, which then read and translate metrics from a car’s internal network. This data can be handled by Android applications using the OpenXC software component library.  It can be used with the OSGi framework and the Eclipse-based Dragonfly IDE. The software is now in a limited test release. It is an important indicator of how far open-source efforts may spread.

Enthusiasm for modifying cars goes back a long ways.  “Cars have always had a maker/tinkerer culture,” said Giuli. Now, efforts such as Ford’s,  Local Motor’s and the Silicon Valley Automotive Open Source Group’s undertakings are looking to bring the open source software ethos into modern cars, which now sport more and more programmable electronics.

Even SOA has made an appearance in some embedded services development efforts that are based on modular methods for updating and enhancing automotive “infotainment” systems. Still, reminds Giuli, software development is very different in the automotive world.

T.J. Giuli, Ford Motor Co.

Consumer electronics design cycles are measured in months, versus years for cars, which must adhere to the strictest safety guidelines, he said. Remember, cars have extended warranties. “A lot of engineering goes into making it last for ten years or 150,000 miles. It’s almost like mil-spec,” he said.

That leads to difficulties, Giuli conceded. “At the end of this [almost] three-year development cycle, the technology is obsolete upon release.” Think of the advances in small devices that have occurred in the last three years.

There is significant potential in open platforms for automotive software development, according to expert viewers. “I think it’s really exciting to see the evolution of cars as a platform for development,” said Melinda Ballou, analyst and program director for Application Life-Cycle Management research at  IDC.

“Data and information that was locked up becomes available in a very different way to typical developers,” she said. Ballou also suggested use of Eclipse open source IDE software for Google’s Android Development Tools gives added vitality to the Eclipse platform.

While safety will remain a major concern, software such as that described by T.J. Giuli at EclipseCon will help build “Web 3.0” or “The Internet of Things” according to conference attendee Christof Hammel, developer, architect and programming engineer at auto parts giant Robert Bosch GmBH.

That will help meet consumer needs. “For the car today,  the new generation wants to have the features they have at home and with their  phones,” Hammel said.

Safety will remain a big factor. It is said that designing interfaces for mobile apps is different than for land-based apps – that is even truer for automotive computer system interface design. “Things that require total focus don’t make sense at all,” said Ford’s Giuli. “So you have to think about designing differently.”

His comments came only a day after representatives of the Alliance of Automobile Manufacturers urged congress to help ensure that mobile devices limit the likelihood of distracting drivers when the devices are included as part of vehicle systems. – Jack Vaughan

“Virtual images are tripling every two years, outpacing the doubling in compute power and essentially flat IT budgets,” IBM Tivoli Software General Manager Sabbah said in a statement coinciding with IBM’s Pulse Conference.

“With current operating practices, every two years you’d need 1.5 times the physical infrastructure to support cloud and twice the labor. That’s an unsustainable cost and management problem which is the exact opposite of the promise of cloud,” he continued, as he outlined benefits of IBM’s new SmartCloud Foundation offerings. While public cloud providers can be expected to ramp up to manage ultra-large configurations, it is more difficult to see how labor issues will affect the much discussed user-side cloud type known as private cloud.

Will work for cycles

The labor issue is a stubborn one, and it must be factored into cloud computing ’what if?’ analyses that enterprise architects are now undertaking. Cost savings are crucial to the dream of cloud, but greater experience with this architecture leads many to downplay cost savings.

Various companies have been working to address the labor issues of cloud, which is a massively scaled architecture that calls for sophisticated and on-demand provisioning of increasingly complex configurations and many virtual images.

The effort suggests that this goes back a long ways. It certainly has been of concern as distributed computing and rack-based blade servers have multiplied. The movement toward grid and autonomic computing looked to address the challenge, and now cloud and even dev ops can be seen contending to solve the problem, but remedies have yet to take hold.

The poster children for the first rush of cloud – Google and Amazon – can be said to have “thrown people at the problem” as they both employed high head counts of developers to service vast farms of servers. And the developers are very advanced developers at that. The classic Google ranch hand is a math and algorithmic wizard who is also adept at systems programming. In Google’s early days, at least, this person combined development and operations skills to a startling degree.

Is cloud computing hugely labor intensive?

We wondered if other companies can repeat this model. So, when we caught up with Skytap’s Brian White at this week’s EclipseCon 2012 in Reston, Virg., we asked for his take. As vice president of products at cloud provider Skytap, White is responsible for product strategy and product management. Before this, he was director of developer resources for Amazon Web and launched the AWS Elastic Beanstalk platform-as-a-service offering. We asked if private cloud labor was not labor intensive.

“It’s hugely labor intensive,” White answered. This is for a reason. “There are things that make [public cloud] a challenge. One is keeping it up and running all the time.” Another, he said, is the fact that the number of servers you can deploy may be relatively modest. “You don’t have unlimited capacity for scaling,” he said.
Where cloud approaches have the most value, White and others have concluded, is where resource needs are unpredictable or irregular. That is why Skytap and many other cloud providers focus on the development and test markets.

Development and test tasks make for a dynamic workload, he said, adding “from a cost perspective you don’t need to have these projects running 24/7.”

For cloud, “there is a huge amount of hype around cost,” said White. “The real benefit people are getting out of it is agility – much more than just pure cost reduction.”

Continuous deployment

While it is largely a beneficial trend, the move to Agile development becomes a factor that further exacerbates the cloud planning dilemma of architects. This was borne home in conversation with Dave West, analyst, Forrester Research, who spoke on Lean development at EclipseCon 2012. He showed that deployment was no longer an end-of-the-Waterfall development lifecycle event. It is now a constant companion. That is because part of the Agile of goal is to deliver bits of functionality as they become available.

The new styles of deployment requirements are certainly an issue with which cloud computing administrators – as well as developers and architects – are going to have to deal. Here, cloud may drive change. It is shedding light on dark problems.

“Cloud is an interesting phenomenon,” said Forrester’s West. “I am excited about what I is doing to drive internal IT to think about its systems in a different way.” – Ryan Punzalan and Jack Vaughan
In the face of fairly rampant fear of placing data on a public cloud, much attention has been placed on private cloud – but labor and cost issues may unsettle such undertakings. What do you think?

Bubbling under the mainstream of computing these days is the fast growing phenomenon of Node.js – a framework built on Google’s Chrome JavaScript virtual machine and providing a type of server-side JavaScript experience. 

Node.js employs an event-driven architecture and a non-blocking I/O model, and it provides some blindingly fast performance to some types of data-intensive Web apps.  It seems to take a very-light-weight component approach that distinguishes it from even lightest of the lightweight Java servers, while, some would say, harkening back to C and C++ servers that predated the Java server. Node.js is written in C and C++ and, on one level at least, it seems the province of the system programmer rather than the typical application developer. But it is programmed via JavaScript.

LinkedIn, Yahoo and eBay are among ardent Node users (‘’js’’ is sometimes jettisoned and it’s simply called ‘’Node’’), and a recent West Coast Node conference was graced by none other than Microsoft, which is toying with end-to-end JavaScript coverage on its Azure cloud. But it may be said that none are more out front on the Node.js wave than IaaS cloud provider Joyent, which went ahead and hired Node.js creator Ryan Dahl. As a cloud provider, Joyent is driven to optimize performance of its server farms, especially for Web application handling.

We recently caught up with Joyent CTO and co-founder Jason Hoffman to learn more about Node.js. We asked why Joyent took the Node.js route. He said:

“Why we did it is, at Joyent we have a lot of servers, more than most companies in the Fortune500 and we write in C, in a compiled language. We needed to write servers in a dynamic language for talking to certain protocols. Basically, we had to write service endpoints. The Node part of Node.js is separate. It is designed so that it can handle a lot endpoints – on the order of a million. Most things written for the [Java Virtual Machine] can only handle 20,000 [endpoints]. Node is meant to handle a lot of I/O.So we took the node part and married that with V8 [the JavaScript virtual machine from Google].”

Node.js comes without the baggage of early platforms or frameworks. ‘’It has no history of blocking’’ said Hoffman, describing classic program languages as ‘’non-event driven languages.’’ He suggests that the idea of client side JavaScript turning around and running on the server side would not be possible if it weren’t paired with the V8 JavaScript VM. It acts like an application server, or container.

The VM enables the ability to do an event-driven server, he said. Nod, in effect, becomes a framework that shows you how to write a server in JavaScript.

“It’s meant to be very easy. It’s meant to let someone write a server,” said Hoffman. “When we look at the general interest – most businesses are having to do API endpoints today. When you let more people connect via mobile devices, you have a lot more people connecting. Rather than having to have hundreds of servers, you can add two or three.  Node.js is just a very easy way to write endpoints.”

Is it easy enough for a developer legion to grapple with? Maybe, as long as the tools that cover over the complexity for the enterprise come into being. Node.js is a far cry from Web services, representing in a way a new take on some earlier pedal-to-the-metal architectures. But it may help overall to speed and streamline REST services, especially in mobile app settings. It seems poised perhaps to give a further boost to the often maligned JavaScript language, which got a just-in-time boost via the flood of Ajax frameworks that arose almost ten years ago.