Web services and composite applications, like traditional monolithic apps, rely on data. Without the right data at the right time, the service/application has nothing to execute. In this podcast, Nexaweb Inc. COO David McFarlane talks about how composite applications involve much more than just some slick tools that make eye-popping front ends. He touts data integration as a key element in composite application development and the creation of dynamic user interfaces.
Among the topics covered are:
- The semantic technical challenges involved with data integration
- The organizational governance needed to facilitate data integration
- The creation of real-time, event-driven UIs
- Event-level integration in mashup services
- The role of business intelligence in composite development and service agility
- What constitutes a true rich user interface
It’s that time of year where people dust off old chestnuts, revive traditions and take a wistful look back. This is something we ran in 2005 as part of a newsletter, but it never had an official home in cyberspace. It only seems fitting that we rectify that situation.
Information technology is a serious business, certainly it’s one we take seriously. Even with a major national holiday looming this Thursday we’ll keep bringing you the latest in SOA, Web services and integration news.
Yet, let’s face it, you probably aren’t going to be making that enterprise-altering decision this week or going live with your latest architectural achievement. Too many people will be skipping out early and trying to beat the traffic, with gravy-covered visions dancing in their heads.
We at SearchSOA.com recognize that. This isn’t the week you’re going to change the world. Rather it’s a week to reflect on what you’ve been doing and what projects will soon be on your plate. With that in mind, here’s our top 10 reasons why service-oriented architecture is like a Thanksgiving meal:
- Like a Thanksgiving meal, it takes a lot of work to put together an SOA … and no one wants to clean up the associated mess that comes with it.
- Reuse, the next round of Web services you build are the IT equivalent of next week’s turkey sandwiches and soups. You should be getting a lot of meals out of this feast.
- Unless you find a way to spice it up or make it savory, SOA can be dry and a lot of people around the table may quickly lose interest. Also, like a big turkey meal, too much SOA can put you to sleep.
- An SOA project can bring together a lot of people you rarely see. In fact, you probably aren’t sure you want to see some of them.
- SOA can give rise to lots of interesting combinations, kind of like turducken (a chicken stuffed inside a duck stuffed inside a turkey).
- Everyone offers up advice on how to cook up an SOA, but they always leave you with the distinct feeling that they aren’t so sure these tips actually work.
- Standards, on Thanksgiving the standards are turkey, mashed potatoes, gravy, stuffing and cranberry sauce. In SOA it’s WS-* specifications and communication protocols.
- You can undertake lots of small projects while you’ve got your SOA bird in the oven
- It takes a solid network and good communication to move all the food around a Thanksgiving table so that everyone gets to pick exactly what they want. In many ways, it’s a service-oriented meal dependent on a loosely-coupled infrastructure.
- Screw up your SOA and you’ll never hear the end of it.
We at SearchSOA.com are looking for the next generation of leaders in the app dev space.
You see, we’ve got this new blogs section (you’re reading it right now) and we know we’ve got some budding stars out there. We offer a heck of a nice platform with nearly 500,000 site members. It offers the chance to establish yourself as a thought leader in an arena that has become critical to the enterprise.
So who are we looking for?
First, we’re interested in end users and integrators. Nothing against vendors, but they already do a fine job of getting out the word on their particular slant on things. What we want is the people who are trying to make service-oriented architecture work, the folks who’ve had to roll up their sleeves to tackle the untamed world of service orientation. Make no mistake about it, the best resource in this industry is the user community. It’s where the best, most incisive information can be found. We’ve got the platform from which you can be heard, all we need is folks who have something to say.
Second, have a focus. SOA is a broad topic and a good blog will find a solid niche inside of it. It could be data integration or architectural design or runtime management or REST or composite applications or WS-* standards or BPM/event handling or security or network issues. It really depends on where your expertise lies. We’re open to suggestion. What we want is smart, articulate people who want to interact with the larger SOA community. Pick your topic and let us know what issues inside of that topic you plan to cover.
Third, send us a sample. It doesn’t have to be “War and Peace”. In fact, since it’s a blog we’re talking about, “War and Peace” would be overkill, but we will need to see a sample of your writing to get an idea of what to expect from you. This is going to be a blog, so you’re going to have a lot of freedom. We won’t be editing your stuff for spelling and grammar. As such, we need to make sure we’ve got bloggers who are capable and confident writers.
Fourth, remember this is a blog and not a weekly column. A good blog is a busy blog. It’s great if you want to make a regular column-style entry part of the blog, but remember to punctuate it with quick insights and links to what you think is valuable other content. A good idea can take you a long way. If it’s a good idea that can be summed up in three paragraphs, that’s fine.
If you’re interested, send your writing sample, a quick explanation of the topic you’d like to cover and a short bio to email@example.com. If we like it, you’re on the blog roster. It’s that easy. You can be impressing colleagues, friends, family and would be (or ongoing) love interests in no time. Part of our site relaunch effort is to give our community more of a voice and this is a major initiative for us. Users never have needed sober advice from their peers more than they do right now. Can you be one of the people who steps up to provide it?
And don’t forget about our current reader contest. Maybe you’ve got a lesson learned to share with the community, but you want us to write it up for you (because we’ve got professionals who are paid to do that sort of thing). Well, this contest would be right up your alley in that case. Winners will receive a copy of Thomas Erl’s new book, “SOA: Principles of Service Design” as a thanks for their participation.
Over on her ebizQ blog, Krissi Danielsson has noted that the buzzword success of Software as a Service (SaaS) has spawned numerous aaS imitators, including Data, Architecture and Voice all “as a Service.” In his ZDNet blog, Phil Wainewright added that aaS is redundant because the very function of business is to provide services.
It’s about time some sane, responsible folks pointed out that we’re heading into buzzword overkill with “as a service.” Yet we’d be remiss if we didn’t have some irresponsible fun with aaS before it becomes yesterday’s catchphrase.
For instance, here’s a list of software possibilities that still haven’t had their aaSes handed to them:
- Hidden License Fees as a Service (HLFaaS)
- Stovepipe Application Sprawl as a Service (SASaaS)
- Integration Spaghetti as a Service (ISaaS)
- Every Vendor Insures Lock-in as a Service (EVILaaS)
- Must Upgrade to the Expensive Enterprise Version If You Want It to Scale as a Service (MUttEEVIYWItSaaS)
- Rogue Services as a Service (RSaaS)
Also, as we all know fortune cookie proverbs are made infinitely better by adding ‘in bed” at the end. Let’s try that with “as a service.”
- Count your blessings by thinking of those whom you love … as a service.
- Plan for many pleasures ahead … as a service.
- Something you lost will soon turn up … as a service.
- Good things are being said about you … as a service.
- Fame, riches and romance are yours for the asking … as a service.
- A friend asks only of your time … as a service.
- Romance comes into your life this year in a very unusual sort of way … as a service.
- Stop and smell the roses … as a service.
- Someday you shall see a wise person in the mirror … as a service.
- He who shows too much cheek to a lady may have it slapped … as a service.
At the Ajax Experience in Boston last week, I caught a presentation by Joshua Gertzen, primary architect at ThinWire, called “Dodging the Pitfalls of Enterprise Ajax Applications”.
Gertzen and ThinWire came into the Ajax/RIA space through an interesting side door, working on desktop banking apps at an ISV called Custom Credit Systems Inc. So Gertzen’s perspective is that of a programmer with a business focus than one who likes to make pretty Web pages. In fact, he noted that the Web traditionally doesn’t handle data-centric applications very well, which is no small issue for those building data-heavy business apps.
Even more than that, he said that a serious financial application can have thousands of business rules attached to it (16,000 was his number of choice) and it can make for a presentation layer nightmare when it doesn’t understand a rule change. The degree of difficulty only rises when you add Ajax and Web services to the mix.
“All the new application endpoint handlers on the server could number in the hundreds,” Gertzen said.
Gertzen’s proposed solution is that logic and events should be handled on the server to allow full access to server resources and to make debugging easier. That will allow developers to create a tightly coupled Ajax/RIA interface that doesn’t get bogged down with too many rules.
Of course, since this is an SOA blog, I probably just hit a trip wire for many of you when I used the words “tightly coupled.” Aren’t we trying to get away from tight coupling? Well … yes … though obviously there comes a point where you have to implement and that may involve some tight coupling.
I caught up to Gertzen after his talk to bounce that very question off of him. What does the application architect need to consider when tying these rich interfaces to a Web service that may have shifting data sources and business rules? How do you rationalize the tight coupling of the interface with the loose coupling of the service?
Gertzen suggested having the server make a Web services call to itself to create a new, separate instance with which the interface can interact. That way state and change management don’t become rolling trouble spots.
Let’s take that ball and run with it. Say you’ve got an enterprise that runs a few hundred Web services inside its SOA and you want RIA interfaces for all of them. That would seem to be a real sweet spot for virtualization tools. You could make those new instances part of your overall SOA governance strategy (specifically in how you handle change management). It’s amazing how all of these hot, new areas in IT can potentially fit together. Whether virtualization will become the secret sauce in the RIA/Web services sandwich remains to be seen, but it certainly would seem a handy way of getting around the problem of tightly coupling an interface to a service that will not remain static.
We’ve got a new reader contest at SearchSOA.com. It involves the very thing our readers tell us they most want to hear, yet it’s what they least want to talk about.
It’s worst practices, which are always fascinating when it’s someone other than you. We love other peoples’ pain … our own, not so much. Yet the demand is such that we figure some of you out there are willing to sound a warning for your colleagues out there. Users are hitting the majority adoption phase of SOA and they’re rightfully nervous about the potential pitfalls. Plus we figure part of the tale has to be how you corrected the mistake since people normally fix a mistake once they realize they’ve made one. Mac Daddy and Daddy Mac from Kris Kross don’t still wear they’re clothes backwards.
Anyway, for those interested, here are the contest details. Winners will get a free copy of SOA: Principles of Service Design by SOA guru and SearchSOA.com site expert Thomas Erl.
It is common for small and midsize business to wait out technology bubbles. If a hot new technology bursts onto the scene, the SMBs don’t immediately adopt it. Expensive and unproven technologies aren’t usually their cup of tea. It’s a sensible approach that keeps IT from being too much of a cost center for users who don’t have a ton of cash to spare.
Yet, as we all repeatedly hear, service-oriented architecture isn’t a technology. Rather it’s an approach to using technology and, like Jennifer Lopez’s love, that don’t cost a thing. Service orientation is an approach toward business that has been around for decades and embodied in things like ITIL. Enterprise architecture is a discipline. On the face of it, SOA requires nothing an SMB can’t do.
A while back, I spoke with Sandy Carter, IBM’s vice president for SOA and WebSphere strategy, about SMB adoption and she noted that three quarters of mid-market companies are using Web services and that “I’ve never seen this fast of an uptick for a technology in the SMB customer base.”
Carter then caught herself and added, “Well, we don’t consider SOA just a technology and maybe that’s the reason for the uptick.”
She noted that service orientation was allowing SMBs to create value added services and to connect to larger trading partners and markets with a minimum of custom work involved. The thing those sorts of projects have in common is they’re revenue generators. Carter said that while larger companies are often focused on cost cutting (viewing IT as a cost center), SMBs who’ve entered the arena seem to view SOA as a way of running IT as a profit center.
Ask anyone what the ideal startup project for an SOA should be and you’ll almost invariably hear the answer that it should be tied to a revenue stream in order to provide the necessary ROI for the work involved. It should be the first step in a strategic plan, but tied to a tactical business opportunity. Could it be that SMB’s fundamentally understand SOA better than some of their supersized counterparts?
Carter pointed to some other advantages SMBs might have in this area.
– “Because there are fewer business and IT people involved, they can align faster. Often the CFO has business and IT reporting directly.”
– “Big companies have significant governance issues. SMBs can be focused on targeted processes, not fixing overall categories.”
– “In a smaller business, people often wear multiple hats. They have a broader view of the business than just what they do.”
Gary Grandlienard, director of enterprise architecture for Railinc Corp., a $51 million rail industry information services business based in Cary, N.C., agreed with Carter’s take that SMBs have decided advantages over large companies when it comes to SOA.
– “I’m able to work directly with the project teams and that ensures there’s consistency in the tools they’re using.”
– “It’s a lot easier to educate everyone involved, executives and developers, about what we’re trying to achieve with SOA. It’s much easier for us to communicate with one another.”
– “A lot of our apps were using the same information, but we were still building stovepipes. The truth is we’re too small to not be sharing this information across our application portfolio. The problem isn’t so big that we can’t get our arms around it.”
– “One of the reasons we’ve been able to sell SOA is because it’s part of our data quality initiative. It’s tied to our core business.”
– “We meet weekly with our application architects to make sure they think interface first. We can do follow up at the enterprise level.”
Smaller scale has its advantages, particularly when it comes to governance. The enterprise architect can work directly with the project teams and report directly to the executives. While a lot of SMBs may lack the confidence to try a full bore SOA implementation, here’s a guess that in the coming years many of the leading SOA success stories will be coming from the SMB ranks. They can best see a targeted three- or five-year plan through to the end and they’ll probably realize SOA-related gains the quickest. In fact, expect a lot of larger companies to look at those SMB case studies and ask, “I wonder if that would scale for us?”
Michael Meehan, Site Editor, SearchSOA.com
Those of you who have been longtime SearchWebServices.com readers might have noted our recent name change to SearchSOA.com. The shift was inevitable and, being totally honest, we probably should have made the change a long time ago.
Certainly our coverage has been focused on service-oriented architecture since late 2004. Web services are an important adjunct to that, but we long ago devoted our resources to the big architectural picture rather than the integration plumbing issues in this area. In essense, SearchSOA.com is a proper statement of who we are and who we’ve been for quite some time.
In terms of our topics of coverage, nothing is changing. In our taxonomy, we have broken down the SOA topic into four main areas — strategy, governance, infrastructure and data architecture — in order to make for better navigation of the site, but our writers have long been on top of those subjects. It should be noted that we fully intend to continue to cover Web services, standards and integration like we always have.
In terms of what to expect from the site, the answer is more. We’ll be adding numerous blogs beyond this one. We’ve got new lessons coming in our Service Orientation for Architects School. We’re going to be trotting more columns and a brand new bookshelf page along with reader quizzes and contests.
In other words, what you can expect from SearchSOA.com is what you got from SearchWebServices.com with the volume cranked to 11. We pride ourselves in being the top site on the Internet for independent coverage of SOA. That won’t change, we’re just upping the ante. Make sure to check in daily at the SearchSOA.com homepage because it will be constantly restocked with news you can’t afford not to use.
Michael Meehan, Site Editor, SearchSOA.com