I recently ran into an architect who was trying to wrap his head around SOA. He had sorted out most of it, but one thing was gnawing at him: what makes for a good WSDL?
Obviously that can change dependent on the service in question, but it dawned on me that a good set of examples would be in order. Thomas Erl has listed some essentials for what should be in a service description:
- the service endpoint
- each service operation
- every input and output message supported by each operation
- the data representation model of each message’s contents
- rules and characteristics of the service and its operations
That’s a great starting point, but it’s no substitute for the finished product. Fortunately there is a reservoir of WSDL expertise out there, namely you, or at least some of you who are reading this. What we’re looking for is your WSDL examples. Send them to us and we’ll publish them so that other architects and developers will have some concrete examples to reference.
It can be WSDL 2.0 or WSDL 1.1. If some of you have tried to use WADL for REST-based services, we’re interested in that as well. You should include an explainer of why you made the choices you did and any key takeaways for those who are referencing your example. What we’ll do is create a specific spot on the SearchSOA.com site for all the submissions, a working WSDL resource center.
Enough people are doing this that we ought to provide them with guidance on how to do it well. You can e-mail submissions directly to email@example.com.
I was talking with Wayne Ariola, Parasoft’s vice president of strategy and corporate development, last week about the concept of SOA quality. Parasoft’s been using the term “SOA quality” as part of the latest rollout of its SOAtest product, which now is able to query UDDI registries so that WSDL verification tests can be performed at the time they’re published.
Quality is a key element in software development and it should go without saying that the more business that gets pumped through Web services, the more important it will be to have a good QA process in place for those services. Noting that “lack of central visibility” is normal in the classic software development lifecyle, Ariola listed what he thinks are key elements in that SOA quality process.
1. SOA necessitates centralization, a role played by the registry/repository. He argued that stovepipes become inevitable without it.
2. A health check needs to be performed to make sure the asset meets the requirements. Among the potential requirements, he highlighted defining the asset’s consistency and the boundaries for its reuse.
3. You need a convenient way to emulate the service. Taking down a component could cause unintended chaos once it’s being leveraged in multiple places. Testing and changes are best handled in the virtual arena in order to avoid that trap.
4. If a component or service is going to reused, the testing expectations need to be made readily available so that different orchestration scenarios can be vetted. In general the testing environment should be as open and accessible as possible.
5. Make sure you fully and accurately define your SLAs, future users of that service will need to understand the true behavior expectations behind it.
6. Be prepared to do some sort of compliance monitoring in order to make sure your services are being properly used.
Last week WSO2 released a REST-based SOA registry, joining Mulesource, which released a REST-based SOA registry in January. Together they’re doing something we haven’t seen a lot of in the SOA space over the past few years: they’re innovating.
So much energy has been poured into establishing standards, building out distinct product markets and fleshing out platforms that it’s been a while since we’ve seen much in the way of innovation. Early in this decade the ESB, the services registry, Web services management software and XML networking hardware pushed the IT envelope. They gave users a way to combine applications in a whole new way. Suddenly component assembly was on the table and loosely coupled, autonomous, stateless, composable, reusable services moved from theory to reality.
The REST-based registry isn’t likely to create that sort of paradigm shift, but it does shake up a marketplace that may be getting a bit complacent. Both of these releases are open source and both try to support the service-oriented concept of discoverability without using the UDDI standard. You might be asking, isn’t SOA supposed to be standards-based? Well, yes, it is, but that doesn’t mean that UDDI has to be one of those standards. REST is built on the HTTP standard. It also opens up the question of how can we better enable the princples of service orientation?
I’m not implying WSO2 and Mulesource have found a better way to build a registry, UDDI may still be the gold standard as far as that’s concerned, but they have opened up the subject for debate by attacking discoverability in a new way. They also might be setting the table for the next wave of innovation in SOA. Going back to a December podcast with Forrester Research’s John Rymer, the area of dynamic business applications begs for real-time innovation. Perhaps Microsoft’s Oslo initiative will break ground in model-driven design. IBM may be unveiling its REST-based Project Zero this spring.
Wherever the innovation comes from, we need to remember that it will come. We’ve been conditioned to think of SOA as a set of products and standards that popped up seven years ago, but what it really entails is an approach to technology that will allow you to best incorporate the next wave of innovation … and the one after that … and the one after that. These REST-based registries may be the precursors of advances to come.
In the world of application development, data is king. Unfortunately many new-fangled approaches to app dev, like SOA, have neglected that importance of turning data into an accessible, reusable resource. This podcast with Marcia Kaufman, partner with Hurwitz & Associates and co-author of Service Oriented Architecture for Dummies, delves into some of the all-too-frequent data mistakes being made by users.
The podcast will cover:
- The drivers for data integration
- Why data needs to be treated like a shared and reusable resource
- The importance of data quality
- Why you need more than an ETL tool to integrate your data
- The necessity for creating a standardized way of handling data
Web 2.0 and enterprise mashups were the hot topics at this year’s Web Services/SOA on Wall St. conference. Michael Ogrinz, principal architect for global markets at Bank of America, revealed his company was heavily pushing the mashup concept to its internal users. He argued mashups are a way to overcome low user expectations that the Internet can become a dynamic, useful tool in getting their jobs done.
He also said end user IT departments ought to get involved in mashup development.
“The reason you see the emergence of these mashup vendors is IT has failed to provide the service,” he said.
That’s an interesting take, that vendors are rushing in where users haven’t dared to tread. The panel on which Ogrinz sat lauded mashups for their do-it-yourself nature and expressed hope that more companies would catch the DIY spirit.
Jonathan Rochelle, a senior product manager with Google, stated that mashups not only stand to get corporate employees to avail themselves of powerful modern tools, but he also said, “The concept that mashups will be there is what drives the architecture.” Essentially, his point was that compelling new applications are what makes all that architectural rigor worth the while.
Always ready with a good analogy, Miko Matsumura. vice president and deputy CTO at Software AG, broached the same topic as Rochelle, saying “Mashups are sexual reproduction for your apps.”
Well, that sure does sound like more fun than we’re used to in the IT business, but Matsumura was driving at something more biological, specifically “How does evolution produce variation?” He noted that humans share something on the order of 95% of their DNA with chimps. Similarly, most applications will share the same architecture (once you get a solid architecture in place). From there, variation can take place.
As Matsumura explained it, “You’re looking to enable an infinite number of things you can do in business, but a finite number of things your IT people have to do.”
That sounds like a solid plan, Web 2.0 evolution on top of an enterprise grade SOA. Yet, as Marc Adler, senior vice president of equities and head of complex event processing at Citigroup, noted, data services have a sizable role to play in that enterprise grade SOA and it has been tough to bring DBAs into the fold.
“They kick, they scream, they holler, they don’t want to let their data out,” Adler said.
He suggested a carrot and stick approach to bring the DBAs on board. The carrot is that by opening up their databases, DBAs stand to elevate their status inside the organization. The stick is having executive’s mandate the change.
At SearchSOA.com we spend a fair amount of time writing about the importance of governance and how you aren’t likely to succeed with service orientation unless you put a solid governance model around those efforts.
Yet let’s be honest, the term “SOA governance” sucks. It reeks of someone else telling you what to do, hectoring you over every little detail of a project. It sounds about as desirable as a colonoscopy with an IMAX camera.
It’s a particularly sticky term here in the U.S.A. We don’t like a lot of governance. In fact, we get uppity when we think we’ve been placed under the yoke of too much governance. We’ll dump your tea in the harbor when that happens. In fact, you can be sure many project teams have formed some unprintable thoughts about governance without representation.
That said, can we admit that stovepipe application development leads to needless duplication of effort and that it actually prevents businesses from pursuing new opportunities? Being a cowboy sure sounds like fun, but if that’s what you want, then go buy a horse. If you want to work for a company with stockholders/investors and a comprehensive benefits package, then maybe, just maybe, you might want to consider how what you do affects the bottom line.
At the end of the day, that’s the crux of SOA governance – let’s put a little organization around all these disjointed IT efforts in order to make them more profitable. I suspect everyone whose hackles rise at the sound of the word “governance” would agree with that statement. No one wants to be the square peg begging for a hammering. Beyond that, who doesn’t want their work to be considered valuable?
The rub comes in how to sum up all of the things that exist under the heading of SOA governance in a term that doesn’t cause automatic resentment. As ZapThink’s David Linthicum noted recently, SOA governance encompasses a lot of import facets in application development and management. We need to call it something. I’ve heard “productivity” and “business value” tossed around as replacement terms, but those still sound a bit too buzzwordy.
As a believer in the wisdom of humans, though, I figure someone out there has come up with a term preferable to SOA governance. Feel free to inundate us with suggestions. We’ll pool them together and then put together a poll to see which one our readers prefer. Who knows, maybe we’ll come up with something that sounds more like something you want to do and less like something someone else is forcing you to do (or trying to sell you).
SearchSOA.com has gone international. Just recently we launched a version of the site in China. Now, technically speaking, we don’t have a billion new readers on the site, but you get the idea: namely, we’ve launched the site in the most populous nation on the planet.
Apparently a lot of those emerging businesses in China are thinking it might make sense not to build a haphazard and unmanageable application infrastructure. Imagine that? These companies might actually start with a well-conceived reference architecture and adhere to the basic principles of service orientation. They might be employing the best practices covered in our Service Orientation for Architects School inside those pristine greenfields with which they get to work.
It’s actually not the most comforting notion when you get right down to it. You’ve got who knows how many emerging companies looking to run IT as a profit center instead of a cost center. What if they’re agile and you’re not? How many partnerships will you miss out on? How much business will go to someone else? Suddenly the world isn’t as flat as Thomas Friedman theorized. Instead you’re surrounded by mountains to climb in every direction.
It should be fascinating to see how SOA adoption goes in China. Will the Ertan Hydropower’s Yalong River Dam project be the standard over there? If so, then app dev really will have entered a new world order.
Of course, maybe we’ll confuse our Mandarin readers as much as we help them. For instance, when our lead writer Rich Seeley makes a reference to Yogi Berra at the top of a story, it could cause people to think Yogi Berra is some famous IT guru whose wisdom must be sought out … and that could be a big clog in their machine.
Unless you’ve been under a rock, you’ve probably heard by now that Microsoft has placed a $44.6 billion bid to buy Yahoo!.
We’ll leave it to others to ponder the Wall St. implications of the move, but in her All about Microsoft blog, Mary Jo Foley posits “a Yahoo! purchase would irrevocably change the kind of company Microsoft is.” Foley focuses on advertising in her comments, but it could represent a change in Microsoft’s application development focus. Microsoft built itself around operating systems and desktop applications, the things you do with a computer. Of course, with the advent of the Internet, what you do with a computer has changed radically. Yahoo! and Google have made hay in offering up Web-based applications, leveraging search capabilities and creating dynamic user portals.
Microsoft has tried, mostly unsuccessfully, to gain a dominant position in those arenas. While Dana Gardner speculates a Microsoft-Google partnership might be a mess, it could represent a return to Microsoft’s core applications business. Yahoo! and Silverlight (for RIA and composite apps) represent where the next wave of applications are headed. On the enterprise side, easily distributed Web apps and multimedia mashups are where a lot of companies want to go. It’s where the innovation is and for Microsoft, a company which has always fancied itself an innovator, that’s a good place to be. There are those who think enterprise mashups will be the killer app once users get a service-oriented architecture in place, the idea being that a loosely coupled infrastructure will lead to dynamic new applications.
It’s no secret Microsoft has long faced criticism in SOA circles because its remedy for users grappling with a heterogeneous application environment has been to pursue homogeneity on the .NET platform. Microsoft’s Oslo model-driven development initiative is still in the planning stages, but a Yahoo! purchase begs the question “Why bother with application infrastructure?” Obviously no one expects Microsoft to pull its irons completely out of that fire, but if that’s not going to be a big growth area for the good folks in Redmond (and IBM and Oracle/BEA are gobbling up large chunks of that pie) then maybe it makes more sense to concentrate on New Wave application development. Microsoft could make leveraging service orientation its app dev enterprise play rather than implementing service orientation.
Let someone else do the tedious work and be the company that does the cool stuff.
There’s so many facets to this offer that it’s impossible to assess the true implications of a Microsoft/Yahoo! merger, but going after Yahoo! does indicate where Redmond’s heart is. If Microsoft really wanted to pursue application infrastructure, BEA Systems was a completely complimentary acquisition target. It would have given Microsoft unparalled reach across the .NET and Java platforms. Yet it didn’t make that play. Instead it’s made a Web play which could build on top of of what the application infrastructure vendors provide, potentially expanding its enterprise app dev audience well beyond the .NET platform.
Last week we got flooded with requests to extend the deadline for our Products of the Year Awards submissions. Normally we’d have taken a “no soup for you” stance on this, but when the requests topped the dozen mark we figured we should grant an extension.
Now you’ve got until February 15 to fill out the nomination form. It will push back the announcement of winners until March, but we believe this will be the most comprehensive set of awards handed out in the SOA space and we wanted to make sure absolutely everyone gets a chance to submit.
For those of you who don’t know, we have eight categories:
- Service design and modeling (including BPM)
- Service assembly and integration (ESB, orchestration)
- Service performance (testing, QA)
- SOA runtime management
- Data services/integration (including BI)
- SOA security
- SOA governance (including registry/repository)
- Composite application assembly (portal, Ajax, RIA)
Products need to have been released between Dec. 1, 2006 and Nov. 30, 2007. You can check the nomination form for more details, though we highly recommend you explain how the product enables SOA and adheres to the principles of service orientation in your entry.
Let’s face it, service-oriented architecture is boring. I mean, with all that planning and attention to detail and consistency. Maybe that appeals to the small percentage of people out there who lead highly organized lives, but for most humans in your app dev shop the efficiency and better business productivity of SOA isn’t going to set off any internal whistles.
For them the selling point on SOA is that if you get organized over here then you can do some cool, new stuff over there. It’s a tradeoff. You want to do some fantastic enterprise mashup? Guess what? That’s not going to happen until you’ve got loosely coupled applications with easily digested data. It’s the adult equivalent of having to eat your vegetables before you get dessert.
Anyway, we know that plenty of companies out there want to pursue rich Internet and/or composite applications. What we don’t know is how far along you are with that work. So we put together a RIA and composite apps survey to get a better sense of your progress in this area and to find out what sorts of pain points you’re experiencing. It’s quick and easy to take and we aren’t requiring you to provide any intimate personal information (seriously, we don’t want your DNA).
If we know more about your interests and concerns in the Web 2.0, we can better focus our coverage on your needs. Whether you’re working on an internal portal, a trading application or a cool Web site like BreakThru Radio, or even if that’s what your company would like to be doing, we want to know about your RIA experience.
We know you’re out there, looking to push the application envelope, yearning to turn all this organization into something creative. Make sure you chime in on the survey and it will help align our coverage.