The purpose of service-oriented architecture is to better marry IT to business initiatives … or at least that’s what SOA proponents keep telling us. Yet what are the technologies that enable that? John Rymer, vice president and principal analyst at Forrester Research Inc., has laid out what he calls B3, the essential ingredients for creating dynamic business applications. B3 includes business process management (BPM), business rules and business intelligence (BI).
He recently sat down for a podcast to describe the architectural underpinnings of dynamic business applications.
Topics covered include:
- How SOA supports BPM efforts
- What kind of data BI needs to provide in order to enable real-time business agility
- What kinds of business rules need to be prioritized
- How BPM, BI and business rules can work together
- A sensible starting place for those looking to create dynamic business applications
Anyone interested in finding out more about this subject can get a free copy of Rymer’s report on Dynamic Business Applications from Forrester.
In a recent survey, our readers reported security is the top organizational requirement for SOA. All of the agility in the world doesn’t matter if you can’t provide it in a secure fashion.
Yet traditional security isn’t sufficient to lock down a services infrastructure. Applications aren’t being housed on single servers in a static network. Changes in the application domain necessitate changes in the security domain and it is incumbent upon the application architects to plan for the different types of security that service-oriented architecture will require.
With that in mind, we’ve launched our new security lesson inside our Service Orientation for Architects School. It provides essential resources for architects looking to bake in the security that is essential for a proper SOA.
Burton Group’s Anne Thomas Manes offers up a Webcast on a holistic approach to SOA security. It deals with network options, end point intelligence and identity management practices. Steve Craggs of Lustratus Research identifies the top 5 SOA security traps in a podcast.
Craggs also has a written tip on the flexibility-security tradeoff.
It is no secret SOA is creating new vulnerabilities. It will be the users who educate themselves about how to protect against those new vulnerabilities, the ones who don’t expect someone else in the organization to find the holes, who make the most successful switch to service orientation.
We spend a lot of time these days talking about governance and management when it comes to SOA. There’s a good reason to take that macro view, because far too many people get lost in the trees and fail to see the forest when it comes to service orientation. We are talking about enterprise architecture after all, so an enterprise-level view would be appropriate.
That said, you can put the perfect governance model in place and it won’t mean a thing if you don’t understand messaging. SOA requires a lot of integration work and integration, more often than not, requires messaging. With that in mind we created a messaging lesson in our Service Orientation for Architects School. It features a Webcast with WSO2′s Paul Fremantle on service-oriented messaging, in which he breaks down a slew of messaging alternatives, including JMS, HTTP, REST, SOAP, WS-Addressing, WS-ReliableMessaging and traditional message queues.
Yet more than that, Fremantle delves into messaging practices that will aid you on the SOA front. It’s one thing to boil up a big pot of integration spaghetti, quite another to architect a reliable messaging infrastructure. The lesson is focused on the latter.
The goal of mediation is to help create a flexible messaging backbone for your company. The tip covers a host of mediation techniques, including Web Caching, load balancing and message-based routing.
It’s an ideal chance to catch up on the architectural underpinnings of messaging as they apply to SOA. Even for those of you who feel fairly confident about your messaging skills, this lesson is sure to give you a few pointers to hone your skills.
It’s probably a sign of our times that we view BEA Systems Inc. as a little fish unable to defend itself against larger predators in the software industry ocean. According to its 3rd quarter financial report, BEA is on track to rake in $1.5 billion this year. It still needs to prove in the 4th quarter it hasn’t been crippled by Oracle Corp.’s $6.7 billion October takeover bid, which it rejected, but a conversation I had last week with a BEA customer proved enlightening.
The customer in question, a CTO whom I contacted on a totally separate matter and wished to remain anonymous, believes BEA’s approach to technology can help it weather this storm.
“They adhere to standards and their tooling is open enough that we see no reason to stay away,” he said. “If a change we didn’t like occured after a takeover, we don’t feel like we’d be locked in with BEA. They get loose coupling. We could unplug from them if we had to.”
His basic argument was that BEA has become open enough and embraced heterogeneity to the extent that it can continue to compete for customers based on functionality. It’s got a service-oriented defense system.
“We need technology that works,” he said. “This takeover drama might be interesting to Wall St., but it has nothing to do with my projects. From a user standpoint, BEA was in more trouble four or five years ago when we weren’t sure if they were going to embrace more open systems. They did and because of that we’ll continue to look at them.”
He reinforced what we already know, BEA has proven successful at selling software during the past decade and it shouldn’t be taken for granted that users will stay away from a vendor that has delivered for them in the past. This isn’t some overly leveraged wannabe without the means to support itself. BEA has been a viable player in the app dev space.
Here’s something I wrote in October about why Oracle might want BEA:
While there’s massive overlap between BEA’s offering and Oracle’s Fusion line, BEA does have three particular strengths that Oracle might be looking to leverage: data services, internal portals and external transactions. Those were the three most popular types of service-based applications our users reported they are either working on or plan on undertaking in the next year. Even more importantly, the demand for these types of applications increased sharply with respondents who reported their companies had achieved some measure of architectural maturity. In other words, the farther along users are with SOA, the more important those projects are likely to become.
BEA has its AquaLogic Data Services Platform, it has its WebLogic Portal product as well as the portal functionality it acquired when it bought Plumtree Software in 2005, and it has the Tuxedo transactional business on which it built itself. So the BEA goose might be sitting on a few golden eggs … and that’s not a bad pet for a would-be giant to have.
Yet if that’s a good set strengths for Oracle to buy, then it’s also a good set of strengths for BEA to have. If a user has a data services, portal or transactional project in the works, then BEA (which reports that more than 60% of its revenues are derived from services) stands to be a player.
While the Oracle bid surely staggered BEA, don’t be surprised to see BEA do a fair job of fighting back this quarter. The fact that it has enough going for it to be a takeover target also means it might have enough going for it to fend off Oracle’s advances.
I was reading a recent blog entry by Joe McKendrick in which he noted that service-oriented architecture can save money during hard times and add revenue during good times. It got me thinking about something I’ve heard fairly regularly over the years, namely that SOA often sounds like something out of an infomercial.
You mean SOA slices, dices, chops, cooks things to perfection, cleans up easily, prepares healthier food and has zero environmental impact? You almost expect Ron Popeil to pop out from around the corner and announce that, “But wait, there’s more.”
Let’s face it, SOA sometimes sounds too good to be true. It also leads one of the great misconceptions about SOA, that it’s a tidy thing you can buy. People want SOA to be tangible. They want to be able to point to it and say, “There’s my SOA.” It’s why so many glommed onto the enterprise service bus concept. The ESB is a piece of integration middleware that follows certain service-oriented principles, but many made the mistake of thinking that buying an ESB gave you a de facto SOA. It’s a natural reaction. When something new and compelling comes along, you want it in your hands, preferably now.
Yet SOA isn’t some secret spice that comes in its own box, something you can add liberally to every project. SOA is a consistent and sensible approach to architecting your business. It’s rigor and diligence more than technology.
This week we’ll get deeper into that issue with a podcast with esteemed IT analyst and co-author of “Service Oriented Architecture for Dummies” Judith Hurwitz, in which she directly addresses the whole faulty concept of “SOA in a box.”
That brings me back to the (fair) complaint that SOA sounds too good to be true. Critics are correct that no one thing will solve all your app dev problems. That said, rigor and diligence in building a modular, adaptable architecture is exactly the sort of thing that can help you in mulitple, often diametrically opposed, situations. When the bad times hit, it can help you with cost containment. When the good times hit, it can help you seize opportunities. That’s what an adaptable infrastructure does.
Just last week, we had a story that noted an SOA infrastructure had helped Sprint/Nextel speed up integration with new trading partners twentyfold. That’s a case of saving you money and making you money in one fell swoop. Doing things in a service-oriented manner creates business agility, which is the real goal.
Building a more agile business isn’t something that sounds too good to be true. Large numbers of companies are doing it right now and they are reaping the benefits. It may be hard work, it may require creative approaches to change the corporate culture, but it is not a flimflam promise. SOA is an approach to technology, which opens up a greater number of business possibilities. It can promise more because flexibility is at its very core.
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 firstname.lastname@example.org. 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.