RSS feeds begin to bleed into enterprise applications

You've probably just gotten used to the idea of "mashups" for quickly bringing web services into applications and portals. Well, now get ready for making novel and powerful use of content via RSS feeds in a similar way.

I don't call them mashups, though, I call them "Feed Bleeds." That's because syndicated feeds can be easily bled into one another to form aggregated streams of content. Not only that, the users and/or developers can increasingly control how much of one type of content should be bled in with another.

The use of RSS feeds as conduits for distributing and managing content, data, and media acts as a complement to more programmatic displays of appropriate relational data in applications via such means as ODBC, JDBC and SQL. Whereas these data access protocols target structured content, the RSS and/or Atom feeds open up the spigot to much more information.

What's newly powerful is that nearly any kind of content can be driven through these feeds -- from documents, spreadsheets, and data to video, blogs, podcasts and online HTML instruction manuals. Feed Bleeds allow for human knowledge in natural language to mingle and complement IT-based assets such as data, application services and automated event-driven processes. Think of it as broad integration on the cheap -- and fast.

Unlike programmatic approaches, the developer can hand off to the end users the subscription to and fine-tuning of the content feeds. Users can adjust how much or how little on a subject they want. Businesses can control what feeds are allowed into the network. Get general information on one business subject and highly specific content on another. The work process need determines the right mix of procured feeds.

Indeed, the users can begin to use search in-house or and online directories to find the syndicated content they wish to add to their applications and process views. We're now seeing a lot more custom enterprise applications that contain and exploit RSS-based content. We're seeing enterprises identify more in-house content that they should expose as feeds.

I think the new Feed Bleed benefits are too powerful to ignore. By quickly finding information on almost any topic that's delivered through lightweight syndication, subscriber/aggregators can shape that information flow to help them in their work, then adjust the content qualitatively and quantitatively as needed to best contour the information to the tasks at hand.

Developers can give the users the tools to make content appear in context to business processes. RSS-enabled Windows Vista and many freely available, standalone news readers help, but a cadre of back-end servers with associated APIs also now allow the productive exploitation of feeds, content and services within applications. We're even seeing a conceptual page borrowed from service oriented architecture (SOA) in the form of RSS feed "buses." This really is a case of Web 2.0 leading to Enterprise 2.0, leading to mainstream enterprise IT.

On-premises servers provide the management and integration of feeds. There are also on-demand feed tools. Onsite feed bleed providers include Apatar, Inc., JackBe, Kapow Technologies, RSSBus, and Strikeiron, Inc. These suppliers allow all kinds of content (HTML, XML, PDFs, spreadsheets, CMS, RDBs, SOAP, REST, as well as RSS/Atom) to be bled together, organized, managed and presented. Online mashup tools come from Dapper, OpenKapow, Teqlo, and Yahoo Pipes, among others. Apatar also has a hosted online offering in the works.

What's more, software as a service (SaaS) business applications providers like Salesforce.com (maps and data merge) and Workday are providing more mashups and feeds-based and enhanced services. If it's good for a SaaS provider, it should be good for an enterprise (as it acts as the service provider to its internal and partner users).

The open source world is also a fan of feed bleeds. An increasingly effective lightweight database aggregation approach involves creating specific feeds of data from, say, MySQL data and SugarCRM applications, that are then aggregated into common feeds that provide a single view of a customer, or an order, or a business process. This allows for whole new kinds of workflows, applications, and processes -- but on an agile time-frame. Interfaces are quickly evolving to allow for drag and drop means to create and adapt feeds. Even a business manager could do it!

IBM's vice president of emerging technologies, Rod Smith, is a fan of giving users the ability to finer-tune the content they need for their jobs. IBM itself has produced what it calls a "situational application" tool, a mashup enabler built on Zend Framework called QEDWiki (Quick and Easily Done). Smith recently told me he likes the idea of bringing together the Web 2.0 and enterprise IT communities so they can begin to work together, even if they don't necessarily speak the same language.

As Web 2.0 empowers younger workers to manage content online in new ways, they will want to use similar approaches on the job. Should this de done via an end-run around IT? Or should IT embrace and extend mashups and feed bleeds?

I think it's clear that this one is too good to ignore.

Apache Camel addresses need for discrete infrastructure for services mediation and routing

Read a full transcript of the discussion. Listen to the podcast. Sponsor: IONA Technologies.

One size fits all has its limits. Most developers prefer to cherry-pick their infrastructure resources, keep them lightweight, and remain as agile as they can.

Taking a clue from this philosophy, the Apache Software Foundation has dozens of open source projects under way to build out the discrete infrastructure assets through community input and involvement, while also providing a needed balance between choice and automation.

One such project, Apache Camel, a sub-set of Apache ActiveMQ, is nearing maturity milestones that will make it a unique approach to middleware services mediation and routing. It's also becoming an essential ingredient to IONA's FUSE offerings.

To learn more about Apache Camel and its value to developers and operators, I recently sat down with James Strachan, technical director of engineering at IONA Technologies, and longtime Apache developer and committer.

Here are some excerpts from the discussion:

The problem we’re trying to address is the routing and mediation problem, which lots of people have. They're taking data from various components and sources -- whether it’s files, databases, message queues, Web services, instant messaging, or other data systems, integrating them together, formatting them, and connecting them to the systems. From a higher level perspective, this could be for legacy integration of systems, for smart routing, performance, monitoring, or testing or monitoring transaction flows.

Apache Camel grew organically from code and ideas from a bunch of other Apache projects, particularly Apache ActiveMQ and Apache ServiceMix. We found that people wanted to create and use patterns from the "Enterprise Integration Patterns" book in many different scenarios.

I definitely recommend people read Gregor Hohpe's book "Enterprise Integration Patterns." He offers a really good patterns catalog of how people should do mediation and integration. Rather like the original Gang of Four "Design Patterns" book, which describes low-level programming things, Gregor’s book describes very well how enterprise integration patterns (EIPs) can work and gives us a language for describing them.

Some people wanted to use these patterns inside an Enterprise Service Bus (ESB), some people wanted to use these patterns inside a message broker, and other people wanted to use these patterns inside an application itself or to talk between messaging providers. Still other people wanted to use them inside a Web services framework or some other communication platform.

What we tried to do with Camel was give it the smallest footprint possible, so that it can be reused anywhere, whether in a servlet, in the Web services stack, inside a full ESB, or a messaging application.

We work very closely with the ServiceMix community at Apache which has created a complete Java Business Integration (JBI)-compliant container of JBI components. Camel can be deployed within the ServiceMix ESB among JBI components, but some people don’t use JBI and they may just use Java Message Service (JMS) or they may just use Web services or they may just be JAX-WS clients or whatever. So, we try to make Camel agnostic to technologies. You can use it within patterns like Spring, or JBI or OSGi, or you can use it within any application.

Across all of IT we’re seeing increased specialization in many different areas, where the specialization helps us solve a problem at a higher level. ... And because we’re doing it an open-source environment where there’s a community involved, there's more likelihood that this will be applied across many other different types of platforms and technology.

Camel is unique in a number of ways. What we’re doing with Camel is defining a high-level language to describe EIPs, which I don’t think anybody else has done before. The other thing that’s unique is that this language very closely maps to components that work inside Spring 2. ... What we’re doing is raising the abstraction level to make things very simple, reducing the amount of XML we have to write, but still exposing the wire-level access if you need to do the really hard stuff and roll your sleeves up and get down and dirty.
People don’t have to worry about the low-level details of how to use JMS, how to use JBI, or how to wire together the Spring components correctly, and so forth. We're giving people a nice, simple, high-level abstraction, but yet we are exposing all the power of frameworks like Spring and still exposing the low-level details if you need them.

People really want small and simple-to-use components that solve the problems they have. I've seen that throughout all of our customers. People ask for very specific solutions. They don’t say, "Give me a SOA." They say, "I need a message router," "I need a message bus," "I need an ESB," or "I need a services framework." Often, people have very specific requirements and are very much cherry-picking the best-of-breed components from the open-source tool set

If you go to http://open.iona.com, there is a whole raft of documentation online forums, a wiki, and so forth.

Read a full transcript of the discussion. Listen to the podcast. Sponsor: IONA Technologies. Produced by Interarbor Solutions: analysis, consulting and rich new-media content production.

Citrix makes bold virtualization move with XenSource acquisition

Citrix Systems Inc. today roared full throttle into the ever-expanding desktop virtualization arena, when it announced its intention to acquire XenSource, Inc. of Palo Alto, Calif. The news comes right on the heels of VMWare's huge IPO pop.

The $500-million acquisition will provide the Fort Lauderdale, Fla.-based Citrix with a major piece of the virtualization puzzle, adding XenSource's infrastructure solutions, based on the open-source Xen hypervisor, to Citrix's existing application and presentation technologies. This will add the vital OS component to their virtualization engine.

Citrix has said it expects the virtualization market to grow by $5 billion over the next four years. Today's move will put the company right in line for a piece of that pie. It had better, given the rich price Citrix is paying for XenSource.

The acquisition also sets the stage for Citrix to move boldly into the desktop as a service business, from the applications serving side of things. We've already seen the provider space for desktops as a service heat up with the recent arrival of venture-backed Desktone. One has to wonder whether Citrix will protect Windows by virtualizing the desktop competition, or threaten Windows by the reverse.

The acquisition also piggybacks on XenSource's release of XenEnterprise V4, which added new management, availability, and ease-of-use features to the company's flagship product. That release earned high marks in a head-to-head product comparison published this week by Computer Reseller News (CRN). XenSource also said its installed base has doubled to over 650 customers in the last 90 days.

Fellow ZDNet blogger Dan Kusnetzky has some good thoughts on the news.

Historically, the attempts to meld technology companies having dissimilar management styles and cultures have not turned out very well. It doesn’t take long to find disasters. Some examples are IBM’s acquisition of Rholm or CA’s acquisition of Ingres are really good reference points. In both cases, the key talent that made the companies what they were left quickly after their home was acquired. Both IBM and CA were left holding very expensive shells of what had been thriving, innovative companies. It’s hard to imagine how Citrix will be able to meld an open source company into their heavily Microsoft-focused environment.

The move further cements an already strong relation with Microsoft on the part of Citrix, but complicates the picture when it comes to open source. XenSource has worked with Microsoft to ensure interoperability between XenSource products and the upcoming Windows hypervisor, code-named "Viridian." But Citrix had worked with Microsoft much longer and more deeply in the Windows application delivery, application networking, and branch office infrastructure markets.

Indeed, few companies have straddled the Microsoft co-opetition vacuum as well as Citrix. Interestingly, both companies have thrived by each other, even while on a strategic level one could easily project potential discord ... some day.

While Citrix has had a strong presence in user-tier virtualization, the XenSource acquisition will extend the company's reach into the logic and data tier, extending virtualization to the servers that run the business logic of applications and the storage system that manage applications data.

Citrix said today it intends to distribute the XenEnterprise product line through more than 5,000 channel partners with expertise in datacenter solutions, and to work with server and datacenter infrastructure partners to create additional routes to market through OEM channels.

When it comes to the desktop, Citrix says the combination of its Desktop Server with XenEnterprise v4 will create comprehensive desktop solutions, and Citrix intends to incorporate such other Citrix technologies as:

• EdgeSight -- for end-user experience monitoring
• Access gateway -- for secure application access
• WANScaler - for accelerated delivery to branch office users; and
• GoToAssist -- for remote desktop support.

The deal, includes the assumption by Citrix of approximately $107 million in unvested stock options, has already been approved by the boards of directors of both firms, and now requires regulatory approval and the approval of XenSource stockholders.

The deal wasn't a total surprise, and was predicted by Dennis Simson and Philip Winslow writing at DABCC last week. Their take on the acquisition was generally upbeat:

While these companies’ virtual infrastructure management tools are more immature versus more-established vendors, if Citrix can develop robust management software through increased R&D while leveraging the open source Xen hypervisor, Citrix could establish itself as a strong competitor in both desktop and server virtualization within two to three years.

ZDNet bloggers Dan Farber and Larry Dignan see the move as an opening gambit in a virtualization land grab that got underway with VMWare's IPO.

Not everyone is jumping with joy over the acquisition. CRN found some customers who expressed dismay that joining with Citrix would diminish XenSource's agility and turn it into just another commodity product. What people think is more important among the community development crowd, a place Citrix has not had much experience to date.

6th Sense Analytics gathers unique view into aggregate developer behaviors, preferences

I wrote about 6th Sense Analytics as the company was emerging, and wondered how powerful the developer productivity measurement tools they offer would be if the data could be aggregated -- and larger use trends could be uncovered.

Well, some of the first community insights have arrived ... they are quite interesting.

Some of the big takeaways for me:

• No need to wonder about how popular Eclipse IDEs are, they are clearly dominant, with a substantial lead over Visual Studio tools in terms of time used.

• Firefox has catapulted as a browser to develop with, and while still behind Internet Explorer is nonetheless a substantial player, and is by no means a niche Web client for developers.

• General development language use is dominated by Java and "other," while .NET lags significantly.

• When are developers in "the flow time," when are they heads-down productive on coding? By day it's -- Sunday and Saturday (no meetings!) ... and it's not Mondays and Fridays (meetings?).

These findings are not scientific and may very well represent a bias toward the types of companies and regions that dominate the current sampling. For example, 60 percent of the developers tracked are outside of the U.S., mostly in Southeast Asia and East/Central Europe and therefore more indicative of outsourcing organizations and offshore development ISVs and contractors. Yet these would be the very organizations where productivity is paramount, and where costs must be kept low and developers kept busy.

And these are not survey results. They are the use data aggregated from some 500 active developers over past several weeks, and therefore make a better reference point than "voluntary" surveys. These are actual observations are on what the developers actually did -- not what they said they did, or tried to remember doing (if they decided to participate at all). So the results are empirical for the sample, even if the sample itself may not yet offer general representation.

Over time, and with more results from the same organizations to compare and contrast, the observations of developer behaviors, habits and preferences will be even more valuable, more representative.

6th Sense Analytics has opted to make some of their data available to an open community, and yet even more data open to subscribers and users of its products that gather visibility into globally distributed software development activities. Subscribers can gain breakdowns on specific use of tools, technologies, types of development effort and "flow," as well as work-types of activities. Custom queries are also available, so that development managers can distinctly determine what works and what does not.

One of the lessons learned from the initial data, and not too surprisingly, is that 80 percent of the work is actually done by 20 percent of the people. Some trends never change.

Disclosure: 6th Sense Analytics has been a sponsor of BriefingsDirect podcasts.

SOA Insights analysts discuss 'Future of SOA' at Open Group conference

Read a full transcript of the discussion. Listen to the podcast.

I had the pleasure to moderate a panel of BriefingsDirect SOA Insights Edition regulars and guests at the recent the Open Group’s Enterprise Architecture Practitioners Conference in Austin, Texas.

The topic was "The Future of SOA," and the panel really rose to the occasion -- from BPEL4People to semantics issues to what ultimately constitutes SOA success.

The live panel consisted of Eric Knorr, executive editor-at-large at InfoWorld; Tony Baer, principal at onStrategies; Todd Biske, principal architect at MomentumSI, and, Beth Gold-Bernstein, vice president of ebizQ Learning Center.

Here are some excerpts:

Dave Linthicum anticipates that, in as few as five years, the role of enterprise architect and the role of SOA architect will meld.

Five years is definitely ambitious. ... [But] the sooner the SOA architect’s role is rolled into enterprise architecture in terms of governance the better. It is, as Dave said, best practice in architecture. We’ve known that for a couple of decades actually.

[SOA] fundamentally changes the way we create applications. That means developers need to change the way they are architecting applications, and that’s very different. It's going to take quite a while until we build up the different levels of services.

If you had a "boundaryless information flow," if you had agility, and you could have IT work at the pace of business, what do you think the impact would be on how IT departments actually behave?

It would be a dramatic shift from what we see today. Adopting SOA is a fundamental change in the way that IT operates. It’s a culture change.

We're used to building a solution, putting it into production, and going on to the next project. It’s a very project-based culture [now]. ... If you move to SOA, you have to shift more toward a product-based culture, where you have a life cycle that goes on over multiple versions and doesn’t end until you take that service out of production.

The move from a project-based culture to a product-based culture will be the biggest shift. If you want a good example, look at companies that practice product management, and at the things that they sell, and you will probably get a good idea on how IT needs to operate.

I look at the information integration problem, or master data management, enterprise, logical data model, whatever you want to call it. It's actually a good space to look at and say, “Okay, what do we need to fix to do SOA right?”

We need to figure out how to make this information relevant to the projects that need to execute properly, and take those incremental steps to get us there. Clearly, having a consistent semantic model is critical to the success of SOA. If we don’t get the consistency across our services, we wind up creating more work for the consumers ... It’s not about producing. It's about creating services that are easy for our consumers to use.

Part of a SOA success trajectory would be the ability to consume, as an enterprise, services in a marketplace ... and drive for lower costs and higher benefits. ... My sense is that what has to come of all this is not just a random coupling. There are going to be partnerships. We were starting to talk the other day about semantic integration, but behind every successful semantic integration is a successful human partnership.

SOA not only opens the floodgates to some of these other technologies [such as BI, BPM, analytics and event-driven processes], but also opens the floodgates to more ways of acquiring and consuming services outside the organization.

As you see SOA methodology spreading through the organization and the ISVs, you'll begin to see a more component-oriented way of developing applications that will permeate the commercial software vendors.

We already see popularity of things like mashups, RSS feeds, and content brought to bear on business processes. Do you think that, as SOA matures and we look to the future, there needs to be a delineation between internal and external content, and who's going to be in role of managing that boundary?

... If you have a couple of internal data sources, and maybe Google Maps on the outside and you throw some Salesforce.com data on there too, you can begin to illustrate for upper management what agility looks like. That’s one good thing about mashups.

There is a lot of rogue application development going on there under the radar, that nobody in upper management really knows about. ... Eventually this kind of stuff outside the firewall will be folded into the greater SOA somewhere down the line. In a way, that’s really what's most exciting about SOA, and most different is the ability to begin to connect to those external services and bring them into the fold.

If SOA is successful, it seems like we're dealing with a complexity of integration, but then that opens up the complexity of semantic issues, and people and behavioral issues, and then boundary and political and government issues. So does the business recognize enough return on investment to say that SOA was worth it, and when will we reach that sort of an economic business rationale?

We need to work this from the ground up instead of the grand enterprise data model. We have to take an incremental approach, and don’t try on that project to boil the ocean. Then, after you’ve done that, if you can somehow sell it to the business, there might be some internal budgeting mechanism or brownie points, where there can be some sort of internal trading system, and maybe there is a way to subsidize that extra 20 percent of development.

That’s not going to work, saying "everything is ground up." You need this middle-out approach, but it has to be driven by the business strategy. ... It all has to come back to the business strategy.

The way to determine "Have I been successful?" is, "Have I been successful in adopting my business strategy and meeting my business goals?" If I have, then I am doing the right things. Every enterprise is going to vary the extent to which IT contributes to those goals. ... It all comes back to what the business is trying to do, and to try to understand how IT can contribute to that solution. If I don’t have any idea on how IT contributes, I am never going to be able to say I was successful or not.

Companies are competing in ways that they never had to before. So perhaps competition -- the ability to compete and win markets, to outflank your direct competitors, to partner efficiently, and do mergers and acquisitions well -- is the big payoff from SOA ... because your IT department can keep up with the business strategies.

Circumstances have a nice little way of concentrating the mind. When you, all of a sudden, are faced with putting two organizations together, which happens pretty often in the business -- M&A is not exactly the exception these days -- at some point you have to say, "Look, we need to take an architectural approach. Our tried and true methods have been tried and they are true, but they may not be valuable. We keep just going back on our traditional way, our traditional path of execution, and we're just going to develop ourselves into a brick wall."

Read the full transcript for more IT analysis and SOA insights. Listen to the podcast. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.

Red Hat beta release of Developer Studio sports Exadel tools, Seam integration

Red Hat today released the beta version of its Developer Studio, an Eclipse-based integrated development environment (IDE) designed to help developers, as companies migrate to and exploit open source runtimes, frameworks and stacks.

The beta releases sees the merger of products that were contributed to Red Hat by Exadel in March and introduced under open source in June. The Exadel products contributed to the project included Exadel Studio Pro, RichFaces, and Ajax4jsf. The new release combines these with such JBoss middleware software as JBoss Seam and Hibernate, providing a development environment for enterprise Java, Ajax, and SOA applications.

Among the benefits of the new release are:

• A seamless, unified programming model that provides new tools around JBoss Seam to build applications in a single, consistent manner.
  
  
• A powerful and integrated Ajax development environment with JBoss Seam and JBoss Ajax4sf frameworks, JBoss Richfaces components and WYSIWYG tools for creating Ajax-enabled Web pages and interfaces.
  
  
• Comprehensive JavaEE tooling with two-way WYSIWYG and source editing of JavaServer Faces (JSF) and Facelets pages, dynamic code assist, and a rich component palette.
  
  
• An integrated runtime, which Red Hat says is the first open-source Eclipse-based development environment that brings together the runtime with the tools, and provides an out-of-the-box IDE.

The Developer Studio beta can be downloaded now. The final release, which will be licensed under the GNU Public License v2, is scheduled for later this summer, and will be available by subscription.

Red Hat developer support customers will have automatic access to Developer Studio as part of their subscription.

Ruling on Novell's Unix assets bolsters OSS, binds Novell and IBM

So Novell really does now finally seem to own the Unix copyrights. Linux finds itself on a high-ground pedestal of long-term, low-risk use (unless Microsoft buys Novell [should have when they could have, eh?]). And IBM and Novell are closer than ever.

Fun times.

The folly of the SCO Group FUD fiasco hurt more than SCO's 2003 investors. It has shown that the PR war approach to undermining confidence in Linux and OSS is a loser's sport for wannabe spoilers.

And while Microsoft thought it bought Novell a pair of permanent knee pads with its Windows-SUSE Linux indemnification pact last year, IBM will now come around to stand Novell back up on its feet, perhaps for good.

Someone should write a novel about Novell's travails with Microsoft over the years. More plots than a first-year Fortran class.

And there's irony, too. IBM and Novell, for example. Who would have predicted 10 years ago that IBM and Novell/Unix/Linux would make great partners against Microsoft, Red Hat, Sun, Oracle and BEA? It's too good not to be true.

We just saw some first hard evidence of the deepening relationship with the IBM-Novell middleware and OS stack bundle news last week. And it's not too whacky to consider Novell's long, tortured journey finding a quiet resting place on the outskirts of Armonk, NY. Set the rocking chair with a nice view of the Hudson. Tea at 4 p.m., lovely sunsets.

I believe the slow-motion tennis ball lob on Linux risk FUD never quite made it over the net. The federal judge on the Unix case just knocked it back in Microsoft's court. SCO as proxy is no more. OSS and IBM's lawyers are the only winners. So let's close the book on that sordid chapter.

Much more interesting now is the market dynamics over how far and how fast up the datacenter stack open source components/solutions will move. Will the Red Hat/JBoss/Apache incubator code move the bar on OSS disruption into the echelons of serious enterprise middleware and beyond? Will data services get an open source foundation? Maybe an OSS metadata layer makes sense, just like OSS ESBs do?

IBM is the arbiter to watch on this transition. Novell can help them manage the timing, while covering a flank against Red Hat. BEA can only watch and wait. Oracle can time the infrastructure transition while nimbly moving up the stack to vertical business applications and data services. Ditto SAP. Sun can play around with trial-and-error open source models roulette while laying off its way to a niche hardware business.

HP could be very interesting. This will be the year for HP's SOA play. It needs to find a way to master the OSS/support/hardware/solutions/consolidation process. But where to chase for the next margins? Who is friend or foe? There won't be too much room for error on this one, not too many chances to recover from missed opportunities or misplaced bets.

The timing is key. And managing transitions from commercial to OSS up and around the stack (to ding competitors while remaining key to major accounts) is the game. There won't be any more Red Hat/JBosses, or such accidental empires. But there may be an OSS applications and services ecology on the horizon. And SOA will soon drive they types of choices that require businesses to focus on such an OSS services ecology.

So like the days when Unix was the infrastructure law in the core corporate datacenter (and Windows was only hype-ware there), we may be back to a period where the major transitions have little to do with Microsoft's rate cards. Microsoft will be at an ongoing disadvantage in the commercial-OSS transitional disruption march across back-end servers as long as it has no OSS strategy (other than FUD). And that FUD strategy has just come up wanting.

SOA Insights analysts explore SOA appliances, BPEL4People and GPL v3

Read a full transcript of the discussion. Listen to the podcast.

Appliances for IT infrastructure have evolved to include everything from email servers to network routers to XML accelerators. Some would argue that "appliances" can be hardware, software, or both. Purists have a more strict definition that they say will make the locked-down and all-inclusive devices of great appeal to growing legions of IT operators and SOA architects.

For the latest BriefingsDirect SOA Insights Edition podcast, our panel of IT analysts and experts are joined by someone who knows appliances inside and out, Jim Ricotta, vice president and general manager of appliances within IBM’s software group. Jim offers some hints that IBM is betting big on appliances across more aspects of IT solutions.

Our expert panel digs into this and other recent trends in SOA and enterprise IT architecture in the latest BriefingsDirect SOA Insights Edition, volume 21. Our group also examines the emerging BPEL4People specification for making humans and SOA better, if only loosely, coupled. The discussion ends with a look at the GPL v3 and the importance, or not, of the Apple iPhone.

So join noted IT industry analysts and experts Tony Baer, Jim Kobielus, Brad Shimmin, and Todd Biske for our latest SOA podcast discussion, hosted and moderated by yours truly.

Here are some excerpts:

... On IT infrastructure appliances and SOA

The basic concept of an appliance is to allow customers to get their projects going more quickly, experience lower total cost of ownership (TCO), etc. ... We have a broader remit and we are looking at a number of different appliance efforts for different parts of the IBM product set.

The idea with an appliance is that the clients don’t care what’s inside. They care about the functions that the device does. The way we have architected our product, we do have lots of choices. We can pick the right processors.

[But] it’s really much more ... than performance. ... it’s about TCO and then "time to solution" and "time to deployment."

I’ve heard big global IT organizations, when they do their TCO calculation, say a router is $100 a month to support, a server is $500, and a DataPower SOA appliance is maybe $200 to $250. Those are the kind of ranges I hear.

So, we are talking a potential 50 percent reduction in total cost? Yes.

Our customers say, “Geez. We could do what your box does with software running on a server, but the operations folks tell us it would be two times or four times more expensive to maintain, because we have to patch all the different things that are on there. It’s not the same everywhere in the world in our infrastructure. Whereas with your box, we configure it; we load a firmware image, and it’s always the same wherever it exists.”

So, our view is an appliance is three things that the customer buys at the same time: They buy hardware, software, and support, and it’s all together. That’s really what we think is the core value proposition.

A manager I worked for had the term "Dial-tone Infrastructure." You want to plug it in, pick it up, and it works. That’s the model that everybody is trying to get to with their solutions. But, when you're dealing with an appliance, you have to have that level of integration between the hardware and the software, so that you're getting the absolute best you can out of the underlying physical infrastructure that you have it on.

Any software-based approach that’s on a commodity hardware is not going to be optimized to the extent that it can be. You look at where you can leverage hardware appropriately and tune this thing to get every last ounce of performance out of it that you can.

[SOA and appliances] dovetail because the very concept of an appliance is something that’s loosely coupled. It’s a basic, discrete component of functionality that is loosely coupled from other components. You can swap it out independently from other components in your architecture, and independently scale it up or scale it out, as your traffic volume grows, and as your needs grow. So, once again, an appliance is a tangible service.

SOA has its own version of an ISO stack with the WS-Standards and the layers from things like BPEL, all the way down to XML and the basics. That’s what enabled this approach of putting together a device that supports a bunch of these standards and can fit right into anybody’s SOA architecture, no matter what they are doing with SOA.

We see ESB as a key part of any SOA architecture and deployment. If you do it properly ... you tend to get a performance solution. You’ve done optimization. You’ve done a pruning back of all the potential functions. ... You tend to have good performance from, as well as the other benefits I pointed to, easy deployment and low TCO. So, given that ESB is the core of SOA, in many ways having an appliance alternative is important.

A lot of this space in the middle in SOA is all about what I would call a "configure-not-code" approach. Appliances, by definition, are something you configure, not something that you are going to be developing code for. So, it’s really tuned for an operational model, and not for a developer having to go in and tinker around with it.

And that’s really where a lot of the savings can come in the total cost of ownership. It isn’t how much work you have to go through it to actually make a change to the policies that are being enforced by this software appliance or device, and there are big differences between the products out there.

An appliance can act as an enabler for other pieces of software in terms of providing that level of performance and scalability that those pieces can't do on their own. Such as we are seeing with ESBs and other areas. Those pieces of software need desperately some piece of hardware somewhere that can get them the information need in any timely manner.

We [at IBM] have some discussions underway with network providers that have big corporate clients who are now launching their first B2B Web services, and they are basically utilizing SOA-type functions between organizations across Wide Area Networks. These carriers are looking at how to provide a value-added service, a value-added network to this growing volume of XML, SOA-type traffic. We see that as a trend in the next couple of years.

On BPEL4People for SOA ...

The BPEL4People specification came to fruition this week. ... It’s interesting that they made both spec proposals separate. But, it’s not any type of surprise. IBM and SAP have been talking about this for about 18 months to two years, if I recall. What was a little interesting was that Oracle originally dissented from this, and now Oracle is part of that team.

The SOA folks have looked at BPEL and find something interesting. It does well with machine-to-machine, or at least with designed-for-automated processes to trigger other automated processes based on various conditions and scenarios, and do it dynamically. But, the one piece that was missing was most processes are not 100 percent automated. There’s going to be some human input somewhere. It was pointed out that this is a major shortcoming of the BPEL spec.

So, IBM, SAP, Oracle, BEA, Adobe and Active Endpoints have put together a proposal to patch this gap, and they’re going to submit it to OASIS ... BPEL4People. We’re going to add a stopping point to say, "Put a human task here." That’s essentially BPEL4People. It’s a little more than that, but essentially boils down to that.

Where I tend to see the value in this is that invoking a human task as a service is not necessarily a call for relationship with orchestration. You don’t necessarily have to orchestrate in order to invoke a human task.

I think that we definitely need this. There's a constant tension with trying to take a business-process approach within IT when developing solutions. If you look at the products that are out there, you have one class of products that are typically called "workflow products" that deal with the human task management, and then you have these BPM products or ESBs with orchestration in them that deal with the automated processes. Neither one, on their own, gives you the full view of the business process.

As a result, there’s always this awkward hand-off that has to occur between what the business user is defining as the business process and what IT has to turn around and actually cobble together as a solution around that. Finally getting to a point where we’re saying, "Okay, let’s come up with something that actually describes the true business process in the business definition of it," is really important.

Read the full transcript for more IT analysis and SOA insights. Listen to the podcast. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.