The marriage of software development and service-orientation especially continues to confront testers with new challenges, says Wane Ariola, Vice President of Strategy for Parasoft Corp. The company has recently updated its Parasoft SOAtest suite to address issues SOA practitioners find as they embrace messaging integration middleware, composite applications and new REST architectures.

Messaging middleware is still new to many testers, and it is found in many a SOA.  The ”headless” nature of composite applications – often, there is no client interface with which to interact – also challenges the test team.

Meanwhile, SOA services have expanded from WSDL to include WADL, said Ariola. They have also expanded from mostly SOAP to include JSON and REST alternatives. That makes SOA testing more complex for QA, too.

Ariola said new visual analysis features in the latest release of Parasoft SOAtest help organizations quickly pinpoint the root cause of failures within complex composite architectures. Another new analysis feature he points to allows Parasoft SOAtest to connect to a JMS or MQ broker to retrieve the list of message queues – again, to enhance pinpointing of flaws. Core message testing enhancements related to JSON, WADL, REST, WS-I, EDIFACT are also part of the new parcel.

”Said Ariola: When you test composite apps, it’s somewhat of a black box. What we have done is extend the event detail perspective. This gives you the ability to really understand what the specific point of failure is.” – Jack Vaughan

Discussions of SOA have gotten too centered on “S as in service,” Ward-Dutton writes in On SOA governance: for SOA, read CPOA? on the blog for his analyst firm, Macehiter Ward-Dutton.

His discussion of the importance of policies and contracts comes in a glowing review of SOA Governance, a highly praised book by Todd Biske , senior enterprise architect with Monsanto in St. Louis, Missouri.

“What Todd’s book reminded me is that if you want to get real value out of service orientation, then it’s the ‘A’rchitecture that really makes things happen,” Ward-Dutton writes. ”Todd’s narrative keeps coming back to his definition of Governance, which revolves around People, Policies and Processes. And it also talks a lot about the concept of ‘contracts’ in the context of analyzing how service providers and consumers should work together in order to interact. Without People, Policies and Processes in place to guide your organization down the right path, and without the concept of “Contract” to focus on the responsibilities that need to be described and assigned when service consumers and providers interact, such an architecture effort will likely lead nowhere.”

This leads Ward-Dutton to advocate that architects concentrate on policies and contracts and let services be the outcome of the architecture rather than the be-all-and-end-all of SOA.

At PDC 2008, Windows 7 was unveiled as the new workman-like operating system. No more high-concept marketing titles for this version, just the humble if lucky number 7. It’s slogan: “A solid foundation for new possibilities.” In the political parlance de jour it might be known as Windows the Operating System.

The biggest news at this year’s Microsoft show was the announcement of a product that does have a Vista-style name, Windows Azure, the new Cloud Computing platform programmable in the RESTful-style. In a PowerPoint-free keynote on Tuesday, Microsoft Distinguished Engineer Don Box demonstrated coding for the Cloud platform using one API and unlimited URIs that had the developer audience cheering the simple elegance.

Whenever, one of Box’s demos failed, he harkened back to Ray Ozzie’s caveat about all the new technology being nascent.

Architects and others interested in building applications using the service-oriented approach got a better idea of what the Oslo modeling tools were all about. Box was also busy demonstrating the new “M” modeling language that is part of this offering.

Oslo is refined and better defined now, according to David Chappell, principal of Chappell & Associates, who has written a paper, Workflows, Services, and Models, published by Microsoft covering the new technologies.

“Initially, Oslo referred to a lot of different things,” Chappell told SearchSOA. “Now, Oslo refers to modeling technologies and the repository. So just in terms of clarity, that’s progress.”

In its current iteration Oslo includes “a repository, providing a common place to store a range of information about your IT environment,” the M language for describing that information, and a modeling tool, codenamed Visual Studio “Quadrant,” for working with repository information, Chappell explained.

But no Microsoft show would be complete without some controversy, so we have the interesting positioning of Windows Azure as a “fifth generation of computing” and perhaps the replacement killer app for SOA. This Cloud versus SOA debate is comparing apples and oranges, according to analysts SearchSOA talked to for an article on the nascent controversy, Is Microsoft dissing SOA just to push Azure Cloud computing?

Just asking.

In fact, a lot of feeder technologies have developed in recent years to give something ‘Grid-like’ a new chance in the market. Blade computers, virtualization, improved data centers, and cheaper memory have set the stage for distributed memory and transaction architectures that could represent a new stage in computing. So long, Grid. Enter the Cloud.

There are no better models of effective distributed computing today than the Web powerhouses of Google, Amazon and Yahoo. Their Web sites, replete with seemingly infinite server farms, support a type of computer architecture known as the Cloud.

Developers and system architects are watching Google and the others quite closely, reverse engineering their best ideas. Some of these firms have begun to open up the Application Programming Interfaces to their Clouds for on-demand computing needs of outsiders.

Is the Cloud different than the Grid? At this year’s OpenGrid Forum I asked that question of Irving Wladawsky-Berger, a key planner of IBM’s 1990s largely successful Internet and Linux efforts, and now Chairman Emeritus of IBM Academy. IBM, which did as much as anyone to promote the Grid, has also begun to promote the Cloud.

Wladawsky-Berger told me the Cloud is a subset of the Grid. “What is new is massive scalability,” he said. “Things change qualitatively when you have massive scale changes,” he continued.

Be it Grid or Cloud, the new computing architecture will require some application and systems programmers to re-think their strategies. For some Web services folks, the change may only be a small one in the way they work with APIs. Deploying these applications will require greater interaction between development teams and data center administration teams.

Like previous technologies, Cloud will be overly touted. Its benefits will be sung – its short comings will be glossed over. Watch for startups to spring up, solving provisioning and reliability issues that arise as the Cloud spreads.

There is a school of thought that says that the Cloud and SOA is a marriage based in heaven. We’d like to know what you think. Do you have thoughts to share on this subject?

Related SearchSOA Grid/Cloud content
Dana Gardner on Grid and Cloud
Dana Gardner on Grid applications and SOA infrastructures
Bill Brogden on Grid and JavaSpacesDana Gardner on Grid and Cloud
Bill Brodgen on Backup to the compute cloud 

The Java Community Process Web page for Java EE 6 indicates that SCA is being considered for the next version of the enterprise platform. So in a conversation at this week’s Java One with the SAP standards guru, SearchSOA editors asked Patil if consideration should move to implementation.

Should SCA be part of Java EE 6?

“I certainly think it should,” Patil answered. “The main reason is SCA is really about assembling applications in a technology neutral way. If it was about a specific platform, such as Java EE, you could say there are enough APIs and libraries for Java applications. But if you look at the key value of SCA it’s about recognizing the fact that customers have different technologies, Java EE, BPEL, BPM systems, traditional EAI systems. They have a variety of communications mechanisms including Web services, JMS, and EDI.”

Facilitating SOA development in these heterogeneous environments was the driver behind the creation of the SCA specification by a vendor group that included SAP, IBM, Oracle Corp., and BEA Systems Inc. SCA is now making its way through the standards process at OASIS.

While there was a dearth of official talk about enterprise Java in the Java One keynote, Patil said the Java Enterprise Edition will be a major player in service component development.

“One of the main component technologies is going to be Java EE,” he said. “Our NetWeaver product is based on Java EE 5. So in our view it is important that Java EE support this high-level composition standard, SCA.”

But after a few years client/server was just the way application development was being done. It wasn’t a theory any more, and too some extent it ceased to be a hot topic for debate. It was old hat.

New technologies including XML, Web services and finally SOA became the hot topics. Of course, as a Gartner Inc. analyst pointed out in a talk a few years ago, SOA pretty much began in the mid-1990s as an extension of client/server.

“Customers were doing SOA then although they weren’t calling it that,” Massimo Pezzini, vice president and distinguished analyst Gartner Inc., said in a 2006 talk. They tended to use the terms of the 1990s for their projects, calling them client/server. Pezzini said that is the secret few SOA gurus want to let out of the bag: SOA is an update of classic client/server.

In a recent article about the problems with SOA adoption, Ron Schmelzer, senior analyst with ZapThink LLC., also credits Gartner with the transformation of client/server into SOA in 1996.

So it seems client/server, which didn’t live up to its promise, has morphed into SOA, which isn’t living up to its promise. But lots of organizations did client/server even if they did it imperfectly, and it appears organizations are now doing SOA albeit imperfectly.

The nature of things humans do is that they are generally not perfect and almost always could be better. With the exception of 4.0 students, most of us got educated imperfectly. The interstate highway system in the U.S. is far from perfect but we’ve been getting around on it for decades. City planning, which Schmelzer says may be the best analogy to SOA because both are always works in progress, does not produce perfect cities. But it could be argued that city planners in many cases help design more liveable and workable cities.

Interviews with CTOs, architects and developers who are actually doing SOA indicates that progress is being made despite the lack of perfection.

In a user story this week Manny Montejano, CTO at Cars.com explained how he is achieving the elusive SOA goal of getting business executives and managers to drive SOA initiatives. But at the same time, he pointed out that his SOA implementation is only about 30 percent of the way to achieving its ultimate goals. And there have been bumps in the road but he views them not as failures but as learning experiences.

 ”I’m not saying we’ve done everything perfectly every single time from the get-go, which is where our lessons come from,” Montejano said. “We’ve learned lots of lessons specifically that this is a business initiative not an IT/technical initiative.” 

Most of the people who are actually doing SOA talk about it in turns of evolution, or to use Schmelzer’s city planning analogy, an on-going project that is always changing and evolving but is never complete.

Shibashis Mukherjee, lead enterprise architect at Con-Way Inc., the transportation company, actually began work in 1996 on what has become his company’s SOA implementation. 

In his account of more that a decade of working on the evolution, Mukherjee recalled: “We started with the component-based development methodology. At that time SOA wasn’t the big thing yet. We realized it would help us develop faster if we had reusable components to build applications. As our development process matured and SOA came into play, we figured out how to compose the services.”

Perhaps if SOA is viewed as a process we would be less impatient with its lack of perfection.

Granted, I only polled half a dozen people (though I’ll note here that they are half a dozen really smart people). The response I got from all of them is that WOA strikes them as redundant and nothing particularly new, an empty suit if you will. One wrote, “It reminds me a lot of the attempt by someone to gain some name recognition with the ‘SOA 2.0′ concept (which one vendor did try to use and then dropped after it was rejected by the SOA community).” Another responded, “It’s the same old thing, relabeled with an even MORE unwieldy name.”

Yet another noted, “This is just composite Web apps.”

Not a single one of them voiced a problem with the notion that Web-based development is an excellent place to concentrate your resources. In fact, some of the architects stated they are eagerly pursuing these sorts of development strategies.

That said, no one showed any love for the “WOA” acronym. “God forbid this take hold because it could complicate something the industry has been trying to simplify,” said one of the architects. He listed numerous reason why WOA, as a term, could do more harm than good:

• Users should have exactly one enterprise architecture, many don’t and they don’t need the confusion of “which architecture should I use?”
• WOA doesn’t really have an underlying architecture, it’s more a set of best practices around REST, RIA and composite apps.
• If users perceive WOA to be outside the principles of SOA, it could prove an excellent vehicle for building Web-based stovepipes.
• WOA toes and sometimes crosses the line of being technology driven. “We plan on using Google Apps, but Google Apps needs to fit into our structure, not the other way around.”

That last point about the potential technology driven nature of WOA was a point of contention for another architect. “One of the big problems we’ve had to fight is people who act as if SOA is tied to middleware or specific standards like SOAP or to a specific data format like XML. Nothing could be farther from the truth. Just because you’ve got some new technology to use doesn’t mean you go back to shoddy engineering. Everyone should know better than to let a specific hot technology drive the bus. It will cool off and you still need to be in business.”

Strikeiron CEO Dave Linthicum has also blogged about the upside of WOA. He pitched WOA as a potential gateway to SOA.

What is changing quickly is that enterprises are finding that the path of least resistance is in essence to build their SOAs on the Web, using Web resources, including content, internet delivered APIs, and Web services. Once there is success with WOA you’ll see the same patterns emerging behind the firewall, or SOA.

The polled architects viewed that as a perfectly legitimate approach, but one noted, “It’s still SOA. I just don’t see where WOA adds anything. Terms like this tend to make people in the field angry. In this case, it’s an attempt to sell them something they’ve already bought. I don’t know anyone who doesn’t want to use REST or build composite apps using Web tools.”

Time will tell whether WOA gains traction, but these architects expressed an unequivocal desire to have no more than one something-oriented architecture in their lives.

In an interview discussing the Oracle approach to the problematic nature of JavaScript this past fall, Farrell said: “In the Ajax space, JavaScript access to portlets and data sharing is very difficult and in a lot of cases, it’s actually impossible.”

His opinion hasn’t changed. Speaking this past week about the Oracle tool development that relies on Java Server Faces (JSF) to spare coders from JavaScript, Farrell said, “We don’t want our developers programming in JavaScript, which is a pain in the neck.”

Oracle has standardized on a JavaServer Faces (JSF)-based RenderKit, which allows the developer who has learned JSF to assemble disparate components into a Web 2.0-style mashup.

Enterprise customers are looking for ways to avoid getting caught up in such complexities, so the philosophy behind the tools Oracle has in beta is to automate the rendering technologies, so developers only need to work with components and pages, he said. This approach also is designed to insulate developers from the on-going changes in underlying technologies for RIA, he said.

“As technologies change, we can change our framework but they don’t have to change their pages,” Farrell said.

He describes the Oracle RIA tools as “very WYSIWYG.” The developer designates that a page will be Ajax with Flash from Adobe Systems Inc., Farrell said, and that is all the coder needs to know about those technologies.

“You don’t have to learn those technologies,” he said, which in the case of Ajax is basically JavaScript. “Our visual editor will show you how the page is going to look. You can drag a component like a table onto the page. You can bind that to some backend databases or Web service, wherever you are getting the data from.”

Farrell said the Oracle RIA tools are in an advanced beta stage prior to the official release. Interested developers can find out more information and even download them from the Oracle Technology Network.

In all we received 395 responses and 44% said rich Internet applications were part of their enterprise IT/business strategy. Another 30% reported that RIA would become part of that strategy in 2008. 85% reported that RIA was an important to extremely important piece of their SOA strategy. Only 2% said RIA wasn’t important at all to their SOA plans.
Most strikingly, 74% reported they expect the importance of RIA to their IT/business goals to increase this year. In other words, for 3/4 of our survey respondents, RIA is a big deal that will be getting bigger. Rich Web front ends were the most popular type of app being built or planned (79%), with Ajax (81%) being the most popular technology employed to build those apps. Yet 55% also reported they are building/planning database composite applications and 35% reported they have entered or will enter the fairly new space of enterprise mashups. That’s a fairly massive amount for a category that would have been in the low single digits two years ago.

Oddly, mobile apps only drew a 29% response rate. That could be read a few different ways. Our respondents were mostly senior folks in the app dev or IT department. It’s possible rich mobile development is being done outside their auspices. Yet the fact that the more senior people in the app dev arena aren’t connected to it would also mean that rich mobile development hasn’t become a major enterprise initiative. The other way to read it is that mobile devices have yet to become a major business initiative. In fact, mashups using unified communications might be the path that mobile devices take rather than strict mobile app development.

The top two benefits sought by those building out rich/composite apps were improving the user experience for customer facing apps/services (65%) and providing expected levels of business functionality to end users (61%). Lack of internal knowledge/resources ranked as the number one obstacle to adopting Web 2.0 technologies (21%). It also ranked high as a secondary issue (35%). Yet a whole host of issues fell in the 27-38% range for secondary issues: techinical readiness/back-end support, selecting the right technologies, security, data/application integration issues and application performance issues.

Finally, IT management ranked as the top evangelist (28%), technical decision maker (34%) and financial decision maker (40%) when it comes to Web 2.0 technologies. Yet an interesting person ranked second in evangelism (27%) and technical decision making (26%) – the architect. Maybe this has something to do with polling the membership of an SOA site, but it speaks to how architecture is becoming a primary concern in all applications work these days.

It should be remembered that for years analysts have been saying that a primary benefit of pursuing SOA is to get ready for whatever comes next, to be able to deploy new technologies on top of the existing IT infrastructure in a way that makes sense. It would seem from our survey that those predictions are now taking shape in reality. RIA is happening parallel to and in conjunction with SOA and it looks like many users will have interesting stories to tell later in the year.

Mike Milinkovich, executive director of the Eclipse Foundation, told SearchSOA that this is important news for architects and developers working on service-oriented architecture (SOA) projects for three reasons:

1. “OSGi itself and Equinox as its implementation has a service-oriented component to it. It is a technology that you use to pull together services in a runtime.
2. “EclipseLink, which provides persistence to enterprise applications for storing either relational data or XML Schema supports the acronyms enterprise architects love like FDO [Feature Data Objects]. You can get implementations of that specification through EclipseLink.
3. “It is part of the Eclipse Swordfish project, which is a full SOA runtime.”

When Swordfish was announced earlier this year, Anne Thomas Manes, research director for Burton Group Inc., said OSGi added “real value” and is a good fit for the Eclipse plug-in philosophy.

“There’s a lot of nice features to OSGi,” Manes told SearchSOA. “You deliver software in something called a bundle. As part of the bundle it identifies the manifest of all the things that are in there and also identifies the dependencies that this code has. Then the OSGi runtime can look at it and say in order to deploy this I have to get these things that are listed in the dependencies, and get those installed first. It’s a very clean and elegant way to package stuff up. The idea here is that you are going to package up services using OSGi.”

There is currently a discussion thread on TheServerSide.com regarding Equinox, EclipseLink, OSGi and its relation to the Java Community Process work on the Java Persistence API (JPA 2.0).