Pro wrestling legend Rowdy Roddy Piper immortalized the words “Just when they think they’ve got the answers, I change the questions.”
Now we at SearchSOA.com are asking you to do the same thing, sort of. It won’t involve wearing a kilt or smashing a coconut over anyone’s skull. We just want you to ask some good questions.
We’ve recently revamped our site experts roster and we’re looking to put them through their paces. The way it works is you ask a question and we send the question off to an expert to get you an answer. It’s a fairly illustrious list of folks:
- SOA standards and architecture – Anne Thomas Manes, vice president and research director at Burton Group
- SOA governance and BPM – Sri Nagabhirava, founder and chief architect nLeague Services
- SOA infrastructure – Dana Gardner, principal analyst Interarbor Solutions
- RIA and enterprise mashups – Jason Bloomberg, senior analyst ZapThink
- SOA testing and QA – Rami Jaamour, product manager of SOA solutions at Parasoft
- Data services – Larry Fulton, senior analyst at Forrester Research
- SOA development – Chris Haddad, vice president and service director at Burton Group
They’re already producing some top flight insight, like data integration best practices, where grid intersects SOA and the difference between WSDL 1.1 and 2.0. Yet good answers like that depend on good questions from the user community. We sift through heaping piles of “What’s the difference between an application server and a Web server?” (a perfectly legitimate question, but we answered it back in 2003) in order to get some of the top minds in the SOA space the best questions the user base can generate.
The process for submitting a question is simple. Just go to the topic where your question fits and click on “Pose a Question.” That will take you to a question submission form. After that, it’s as simple as typing in your query. Keep us busy. We like it that way.
Java EE 6, now in the development stage, needs to embrace the service component architecture (SCA) specification, argues Sanjay Patil, standards architect at SAP AG.
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.”
In front of a packed room of a few hundred developers at the 2008 JavaOne conference yesterday, IBM’s Jean-Sebastien Delfino gave a presentation of the Apache Tuscany project, an open source implementation of the Service Component Architecture (SCA) standard. SCA is designed to facilitate a standard method of constructing, assembling and developing composite services and the Tuscany implementation (currently in version 1.2) looks to be ridiculously easy to use.
One of the mantras in the SOA space is that it’s hard to do. Sure enough, enterprise architecture and end-to-end governance come with a high degree of difficulty, but Tuscany seemingly has made it a snap to stitch together a composite, Web-based service. According to Delfino, the idea is to abstract away the plumbing details using HTML-style annotations and map out the business logic of the service.
Version 1.2 of Tuscany (which also leverages the Service Data Objects specification) has added distributed SCA domain management, an Eclipse plug-in, Atom binding through Apache Abdera project, improved JMS binding and an OSGi runtime. Delfino used Tuscany for a demo of a fruit store which starts with an online catalog and shopping cart. For those functions he used carrot tags to name the components and declare their implementations, properties and bindings. The transport protocols could be switched just by changing a tag, Delfino chose Atompub and JSON-RPC. He noted that he was running the service a Java SE environment, saying “It doesn’t have to run in a big app server. … Basically you have an Ajax app designed as a set of SCA components.” He added the whole process takes about 15 minutes.
Then he showed how to add a new component class (vegetables in this case) and a database, the latter of which involved another Atompub feed. After that he added a third-party supplier to the service by inserting a single SOAP binding line. “You can point to a WSDL if you want or specify policies,” he said.
Finally he showed off some widget functionality Tuscany has added to the SCA process, allowing the service to communicate with HTML.
Of the widget he said, “This is still an SCA component. It still talks to the catalog. You don’t need to change the model to speak to the client side.”
It should be interesting to see what the adoption rate for Tuscany is during the rest of the calendar year, particularly in terms of who uses it, because it comes across as being a fairly simple service creation tool. Basically, if you can handle some basic HTML coding, it would seem you’ve got the savvy to use Tuscany.
If serverside developers and enterprise architects were left feeling forgotten by last year’s JavaOne conference, then they’ll be feeling positively orphaned by this year’s major keynote address.
Sun Microsystems executive vice president for software Rich Green hammered away on how Java provides “a high performance virtual machine” capable of running all your digital life applications. Amazon demonstrated a handheld media devices for downloading and reading books, magazines and newspapers. Sony Ericsson showed off showed off an upcoming unified media device (think iPhone). Rock ‘n’ Roll legend Neil Young stopped by to talk about why he loves Blu-ray technology.
Green did mention that these New Age applications rely upon a foundation of services that can be mashed up, but that was about as close as the session go to enterprise development. Even the GlassFish news revolved around how the OSGi-enabled modularity of v3 will allow GlassFish to become a multimedia app server not solely associated with the server.
Sun president and CEO Jonathan Schwartz claimed his company is “focusing on users.” He threw in enterprises at the end of his list of who those users might be, but it gave the distinct impression that enterprises are becoming a bit of an afterthought with the Java braintrust.
“There’s clearly a battle developing for what will be that next great developer platform,” Schwartz said.
With whom he didn’t say. He also didn’t explain how enterprises will leverage that platform other than RIA development for clients. Sun seems to have a clear picture for where it wants to be in consumer-based digital life in the future. Whether it has a growing vision for how to help enterprises with development problems they have today remains a mystery.
I’m heading out to the JavaOne conference this week and it struck me that Java has had a very quiet year. Two years ago Sun launched Java EE 5 and almost immediately analysts began to call it a heavyweight dinosaur not likely to survive in an SOA world. Sun and others insisted Java would become more modular in the future, but last year Sun concentrated mostly on client development during JavaOne and it’s most momentous move during that past 12 months was to acquire MySQL, which doesn’t exactly point to any new directions for Java.
So what tea leaves can we read? I asked Brad Shimmin over at Current Analysis his thoughts and he said:
My impression with Java’s momentum is that it has reached a point where the platform needs to remain “consistent” top to bottom while affording specialization — much as Spring specialized as an alternative to EJB. I think Java EE 6 heads in this direction greatly with a highly modular approach that lets ISVs certify against particular aspects of the standard. That’s a good thing. Look at GlassFish for a vision of where this whole modularity thing is heading with its use of OSGi.
Well, sure enough, GlassFish v3 has OSGi support and a bunch of cool little subprojects like RESTful Web services, XML pipeline processing and an Ajax UI. Might we see the relationship between OSGi (and probably the Eclipse Foundation) and Java deepen? Now that would be revolutionary. The JCP page on Java EE 6 also mentions that Service Component Architecture could be part of the Java enterprise platform in the future.
Yet it makes you wonder if Java EE 6 has as much to offer the world as GlassFish v4 … or v5 even. Back in 2005, Sun had two hot new kids on the technology block – GlassFish and JBI. While JBI hasn’t gone much of anywhere, Sun continues to push and innovate with GlassFish. Why break a winning streak? What more can be done with the open source application server? Perhaps the biggest news this week won’t be what’s new for Java, but what’s coming up in GlassFish.
One of our sister sites, SearchNetworking.com, just published a story on how networking pros need to collaborate with people on the applications more often these days because service-oriented apps and Web 2.0 technologies put a greater and/or different strains on the network.
The article comes out of an Interop 2008 session and quotes Shankar Ramaswamy, vice president of product management at Sonoa Systems:
“Often, we start talking to customers in the application side of the house,” Ramaswamy said. “And we say: ‘Hey, we need the infrastructure guys to buy into this. Our customers are starting to recognize that this discussion has to happen outside of our technology. We are pushing it along because we are providing something that makes these people collaborate. We urge you to talk to your application people more.’ “
The piece goes on to quote others and talk about why networking pros and app dev pros need to be locked in the same room until they figure out how to work with one another. Mind you, this isn’t revelatory news. I remember writing essentially the same story after talking to users attending the 2002 NetWorld+Interop conference. John Gage declared “the network is the computer” more than 25 years ago. All SOA and Web 2.0 technologies are doing is taking the network up on the offer.
What baffles this observer of the IT industry is why we’re still having this discussion. The connection between an Internet-enabled network that can go anywhere and applications that try to combine disparate systems and data is so blatantly obvious that you’d need to disable all five of your senses to miss it. CIOs should have demanded app dev and networking get on the same page a decade ago. Instead the conversation seemingly revolves around domain pros wondering why folks in the other domain must afflict them so?
There’s no real big secret to that one. It’s because what you do and what they do are intimately tied together. SOA stands for service-oriented architecture, not service-oriented applications. A big part of that architecture is the nervous system that enables the loosely coupled, discoverable services to operate.
We spend a lot of bandwidth these days talking about technology and ROI (or the lack thereof). I’ll hazard a guess, absent any broad-based data to support it, that ROI is as much tied to getting disparate groups like app dev and networking to work with each other as it is to anything else. It gets to the simplistic beauty of Occam’s razor. Why can’t your IT department operate more efficiently? Because it doesn’t. If it did, then you’d likely see faster and bigger ROIs. Obviously levels of collaboration and dysfunction vary company to company, division to division, but far too many people aren’t having this conversation and you know who you are.
When all else fails, you might want to try working with the people with whom you work.
I’ve been having an extended conversation during this calendar year about SOA and the telecom industry, namely that the European telecoms are often the reference models for what a service-oriented business looks like while U.S. telecoms seem to be mired in the 1990s.
Today we’ve got a curious development with the announcement of the OASIS Telecom initiative, designed to help businesses in that industry embrace SOA. It’s a fine idea and somebody needs to do it, but it’s the equivalent of the short bus. I can tell you who this isn’t aimed at: companies like BT and Deutsche Telekom. They get SOA. In fact, they do it as well as anybody on the planet.
This OASIS effort is geared toward U.S. telecoms and telecoms in emerging economies. It begs the question, “How did the U.S. get lumped in with emerging economies?” We’re talking about corporate giants which apparently require extra hand holding to help them do something that has already delivered for their overseas brethren.
As I’ve been talking with analysts, vendors and users this year about the telecom services in the U.S. market, I encounter a lot of head shaking. I keep hearing that the services available in Europe put to shame what’s being offered in the U.S., which they say mostly revolves around access rather than services.
Telecom is probably the industry most worth tracking to see how early SOA adopters are able to compete and respond to market changes as opposed to service-disoriented competitors. To be fair, there are some U.S. telecom companies that have pursued big SOA projects, but I have yet to run into anyone during the last four months, where this has been a running point of curiosity for me, who hasn’t said the U.S. is lagging behind in this industry (at least in terms of modernizing services delivery capabilities), particularly as applications incorporate more Web 2.0 technologies and unified communications.
Kudos to OASIS for trying to spearhead this sort of modernization, but the real point of interest for this observer will be watching the what happens with the telecom players who took the SOA initiative and gave themselves a head start.
In the early days of client/server adoption in the 1990s there were lots of articles lamenting the fact the client/server wasn’t living up to its promise. It was just another theory that didn’t really work all that well in practice.
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.
A lot of analysts I respect have been pushing the concept of Web-oriented architecture, or WOA, of late. For those unfamiliar with the term, Dion Hinchcliffe has covered it extensively and Dana Gardner has been singing its praises. To be honest, it looked like a term in search of a foundation to this observer. We’ve already got RIA and composite applications and mashups and Web 2.0 and SaaS and SOA, but I figured I should ask a few architects what they think of the concept to see if it’s got traction in those circles.
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.
It’s amazing what happens you put a few thousand SOA users together. Suddenly you start to get a clearer picture of what service orientation can achieve at both the business and IT levels. That was probably the biggest takeaway for this attendee at IBM’s Impact 2008 conference last week: a lot of users are well down the road with this stuff. They’ve thought about it, put it into action and it’s responsible for a significant amount of mission critical business.
Here’s a smattering of comments made by SOA users at the show:
John Roach, director of architecture and governance at Wal-Mart, focused on using SOA to help manage store stock levels and customer demand. “If SOA doesn’t trace back to you finding the right thing when you walk into our store at the time you need it, then it isn’t material for us,” he said.
Kumar Murugan, application development manager at pharmaceutical manufacturer and marketer Novo Nordisk, talked about centralized policy management and stressed the need to view all SOA projects as part of a continuous process improvement cycle. He also highlighted the importance of having a rigorous QA process.
“You need to do a system discovery for any new service,” he said. “You need to understand how reuse affects your existing services.”
Manny Montejano, CTO at Cars.com, called governance “the key thing we need to resolve to be successful” as his company deals with explosive growth.
“It’s important to say no sometimes,” he said. “You have to let people know that some things are going to be more trouble than they’re worth.”
Anne McDiarmid, CIO for Australian fabric and crafts retailer Spotlight, made a case against trying to solve every problem with a software purchase.
“I’ve got middleware hanging out of my middleware,” she said. “I don’t need more middleware.”
A whirlwind of corporate acquisitions in foreign countries has created an integration challenge for SEB, a Swedish banking and insurance company. Enterprise architect Anders Jader targeted data as a key element in bringing together this international banking conglomerate.
“We are now in a phase where we need to transform everything into one data model and then be able to use that data as a service,” he said.
Tony John, domain lead architect at Allstate Insurance, echoed the importance of data in all things service-oriented, stating “we need more data analysts and data architects.” He noted that the bulk of a $30 million mainframe-to-SAP project “was spent on understanding the data.”
John also made the case that technologists have to understand the business they work for, not just how their niche of IT functions.
“No matter what machine or network it goes through, it’s still a group of people doing some business activity,” he said.