SOA development

Oslo team joins MS data programmability group

[ANALYSIS] - Microsoft has made its Oslo design team part of the company’s Data Programmability group. The news was released via the web blog of Doug Purdy, product unit manager for Oslo. It has been a journey. Continued »

The quest for granular SOA services

I learned from a writing teacher who was not a writer at all – he was an engineer. He took an engineer’s approach to writing – or maybe I should say a reverse-engineering approach. That is: He looked at the best examples of the type of writing he was pursuing, analyzed them, and codified their practice. For example, in his class, you weren’t supposed to use forms of the verb phrase ‘to be’. Well, you could, but a point would be deducted each time you did. Oh, how the students moaned. And in turn, he would intone, “When you leave this class, you no longer need employ this method.”
 
He came to his method through the study of failure – his own failure to succeed at writing. As a youth and into college, he’d dutifully hand-in his English compositions and the teacher would scribble “Awk” – for awkward - all over the paper. “They’d tell me what I did was wrong,” he told us, “but they’d never show me how to fix it.” As a result, when he became a teacher of technical writing, he provided clear and fairly strict rules of writing.
 
All of which brings us to the issues of the day: What are truly services? How granular must they be? And how precisely granular should they appear? This is essential to success with SOA, but the literature merely says “Write properly composed services” without providing any guidance on how to do this.

In a guest column on SearchSOA.com, Douglas Barry has given a bit of such guidance for those who would create services. Give it a read and comment.

Related SOA development information
Using atomicity to gain SOA granularity - SearchSOA.com

Survey sees SOA strength

The recent tremendous upheaval in the world economy did not bring out the best in the large army of SOA pundits. The upheaval was going to be “the end of SOA” or SOA was going to be “the answer” to the upheaval. The comments did not run the spectrum – the comments ended up on one end of the teeter-totter or other.  Some SOA pundits have been on auto-pilot so long, the auto-pilot is now the pilot. Where is SOA, really? We felt asking the audiences at TechTarget Application Development Group member sites SearchSOA.com and TheServerSide.com would shed a brighter light on the somewhat murky topic. Continued »

Where SOA ends

By Ted Neward
In the rush to embrace new technologies and demonstrate “cutting-edge awareness”, companies (and individuals) sometimes create mountains out of molehills. Such was the case with XML a few years ago, relational databases before that, object- orientation, Java, graphical user interfaces…. in fact, it’s hard to name a recent technology trend that hasn’t spawned this kind of “rush to embrace” that leads to nonsensical claims, bizarre architectural suggestions, or blatant bald-faced attempts at capturing clueless consumer dollars.

One of those more recent trends has been the SOA bandwagon. Originally, though it’s hard to remember in the frenzy around SOA, the whole point of services, at least in their original form, was about designing distributed systems to be loosely-coupled and thus easier to interoperate with. Consider these original classic “four tenets of service-orientation”  http://msdn.microsoft.com/en-us/magazine…):

1) Boundaries are explicit
2) Services are autonomous
3) Services share schema and contract, not class
4) Service compatibility is determined based on policy

Nowhere in here do we find reference to SOA governance, SOA enablement, or any of the other elements that have been attached to the SOA name. In fact, it’s gotten to the point where CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department.

I always thought CTOs and CEOs had something… I don’t know… *better* to do. For some reason, I always thought it was the job of the architect to think about these things, rather than let the CTO or CEO sit around and think about how their various software systems should be designed.

Don’t get me wrong: any organization that spends time thinking about how their various software systems are going to interact with one another is already a huge step above those that don’t. Too many CEOs and CTOs just assume that their back-end IT systems are capable of talking to anything at any time–in fact, one CTO once told me, to my face, “The only reason you’re saying it’s hard is so that you can charge me more money as a consultant. Well, I’m not buying it, and I’m not buying you.”

Said CTO went on to buy a “service-oriented” software package that he claimed would solve all their integration problems. The company went under about a year later. I won’t suggest it was anything to do with my inability to convince him that he really needed to invest more in thinking about his software infrastructure instead of just buying something “service-oriented”, but I can’t help but wonder….

So what are we to make of all the “service-oriented” bells and whistles currently being hung on every product, language, or release? In the end, the same thing we eventually made of objects, XML, Java, relational databases, XML, and every other technology that’s been put in front of us.

It’s useful, but it has an “end”. There is a point in the IT implementation, where the technology simply can’t help. Consider object-orientation, for example: back in the heyday of objects, various vendors, including one three-lettered vendor who was seriously looking to displace their rival in the operating system market, slapped “object-oriented” around everything, with the full expectation that not only customers *think* the product was better, but that the product really *would* be better. Another company, headed by a would-be jazz musician, tried the same thing for its office suite, and almost jazzed itself out of existence.

Moral of the story? We learned that objects are a useful way of structuring the way programmers think. Nothing more.

Another look at the “four tenets” makes it pretty clear that services aren’t much more than that, either–it’s a way of structuring the way programmers think, and has nothing to do with “governance” or “enablement”. Service-orientation describes an approach by which we create distributed systems, and that’s all.

When a CTO starts thinking about objects, or services, or other low-level activities, she may as well be conducting code reviews, too.

CTO-driven refactoring, anybody?

Ted Neward - blogger, teacher and speaker- is principal consultant, ThoughtWorks.

As with SOA, some development costs obscured by cloud computing

By George Lawton
Cloud computing offers an extremely appealing future for enterprise IT: the ability to leverage ready services with lower initial investment and a pay-as-you-need pricing model. But it will be filled with surprises, and some of these will reflect surprises encountered in the early going of SOA. The difficulties of cloud computing will parallel many of the frustrations early SOA adopters experienced. The more loosely coupled and distributed the cloud based system becomes, the more moving parts you don’t have control over. “As a consequence, the development cycle in the cloud ends up costing more money than expected,” said John Michelsen co-founder and Chief Architect of iTKO.

Is there perhaps a hidden Cost of cloud development? Companies attempting to leverage new software models such as SaaS, third-party services, data-oriented services and cloud computing need to heed the pitfalls encountered by early SOA attempts. The applications need to integrate with functionality built by outsiders. These ‘outlying’ apps can change the service without notice, As well, hidden costs and constraints are associated with cloud testing.

One of the first challenges is that cloud functionality is created outside the organization, yet it still needs to be tested. Michelsen said that just because a set of functionality worked for another similar application does not mean it will work for yours. It is important to test the functionality of applications you did not build.
The adage after Sun’s Java promise of “write once, run everywhere,” was that you had to “write once and test everywhere.” Michelsen said the challenge is that even though an application only gets written once, its performance can vary widely depending on its particular deployment circumstances.

The problem is that the developers don’t write the requirements doc for the services they are using. They need to go through some kind of analysis by preferably working with the cloud service vendor, or build their own compliance step to check their expectations against reality.

The second issue is the need to continually validate an application against a set of service functionality. After the application is deployed, the service provider can make changes that could adversely affect the application without notice. The stuff that works today could break tomorrow. Michelsen said, “It’s not like you get to participate in the user acceptance phase of the new version of Google services.”
In traditional application development, the app is tested every time a change is made. Now the software does not have a system of validation in place. Without a system of continuous validation the service becomes brittle.

For example, one real estate firm that worked with iTKO incorporated a mapping component into its web site. Initial testing indicated that the mapping service worked flawlessly. But several months after having launched the site, they discovered that the map component was displaying the wrong address. They only found this out after one of the agents got lost trying to find a property. If the service had simply stopped working, they might have noticed much more quickly.

After an application has been tested and deployed, paying per unit of service (storage, CPU time, and bandwidth) allows a new app to get deployed with minimal cost. But these fixed costs can take a hidden toll when a company has to do any sort of testing, and particularly load and performance testing of a new app.
The problem is that the IT department is used to paying up front for hardware, rather than being presented with a bill after services are rendered.

Another constraint is that it is significantly more difficult to manage test data across multiple services. In order to do regression testing, there is a challenge in getting data to be consistent across different systems. You might need to create a set of dummy customer accounts in EBay, Amazon, and Salesforce.com, and then delete these at the end of the test. This is especially important for testing complex functionality like using business logic to present new offers.

Michelsen explained, “In the pre-cloud world, one of the challenges a testing team faces is that every time they need to test a piece of functionality, they need the data scenario to be present. For example, if you need to trigger a special offer to a card user with a low balance, that data has to exist in the system. It gets hard to create these scenarios when these systems are off-premise. I spend two-days resetting the environment for a two-hour test cycle.”

SOA guidelines, if heeded, no doubt pave a better way to clouds. Methodologies and tools that were developed for SOA testing by iTKO and may help establish stronger service level requirements, continuously validating functionality and performance, and virtualizing away the constraints of fees and limited access to critical services in the development lifecycle.

Related SOA test information
SOA complicated by ESB proliferation -SearchSOA.com

Another take on OSGi

Last week, WSO2 released an update tailored around OSGi to its SOA framework. Rob Hailstone, analyst, The Butler Group told us that he rated the WS02 implementation favorably, because it ”does seem to have built out a more comprehensive set of features than most of the competitive open source offerings.” Continued »

Interoperability remains SOA bugaboo

Despite years of work on Web services standards, interoperability remains a bugaboo. Continued »

Let’s look behind those SOA implementation numbers!

There was a sky-is-falling frenzy in the blogosphere of late in reaction to a Gartner press release headlined: “Number of Organizations Planning to Adopt SOA for the First Time Is Falling Dramatically,” writes Rich Seeley on SearchSOA.com. But, perhaps, the glass is half full.

Seeley takes a closer look at the data and reports that the survey itself presents a more positive picture of global SOA implementations. The survey found that in 2008, the number of organizations planning to adopt SOA in the next 12 months fell to 25 percent from 53 percent in 2007, but it also found that 53 percent already have SOA up and running.

Get it? Fewer people are starting SOA initiatives because there are more people who have started SOA initiatives. Yes, with a major economic downturn, some of the SOA late-comers have another reason to put off SOA, but, is that news?

Now, we like a good story as much as anybody. Yet we suspect the Gartner data has been blown up in order to fit well with today’s headlines. The devil is in the details, SOA or otherwise.

What lies ahead is more work - work to tame software for the purposes of commerce. SOA arose during the last downturn, largely as a response to too many software integration projects gone haywire.

“The reality is people are doing projects to have re-useable services,” Software AG’s Miko Matsumura told Seeley. Many SOA projects are proceeding according to plan.

“Whether those projects are called SOA or they are called “pickle juice” they will still move forward,” said Matsumura.

Pursuing the purpose behind SOA is the key. Some will succeed; some will fail and try again; some won’t try. We hope SearchSOA.com’s coverage is valuable to the people in the first two categories.

There was a sky-is-falling frenzy in the blogosphere of late in reaction to a Gartner press release headlined: “Number of Organizations Planning to Adopt SOA for the First Time Is Falling Dramatically,” writes Rich Seeley on SearchSOA.com. But, perhaps, the glass is half full.

Seeley takes a closer look at the data and reports that the survey itself presents a more positive picture of global SOA implementations. The survey found that in 2008, the number of organizations planning to adopt SOA in the next 12 months fell to 25 percent from 53 percent in 2007, but it also found that 53 percent already have SOA up and running.

Get it? Fewer people are starting SOA initiatives because there are more people who have started SOA initiatives. Yes, with a major economic downturn, some of the SOA late-comers have another reason to put off SOA, but, is that news?

Now, we like a good story as much as anybody. Yet we suspect the Gartner data has been blown up in order to fit well with today’s headlines. The devil is in the details, SOA or otherwise.

What lies ahead is more work - work to tame software for the purposes of commerce. SOA arose during the last downturn, largely as a response to too many software integration projects gone haywire.

“The reality is people are doing projects to have re-useable services,” Software AG’s Miko Matsumura told Seeley. Many SOA projects are proceeding according to plan.

“Whether those projects are called SOA or they are called “pickle juice” they will still move forward,” said Matsumura.

Pursuing the purpose behind SOA is the key. Some will succeed; some will fail and try again; some won’t try. We hope SearchSOA.com’s coverage is valuable to the people in the first two categories.

-By Jack Vaughan

Policy and contract focused architecture

Perhaps architects are paying too much attention to the services when they work on service-oriented architecture implementation, writes Neil Ward-Dutton. He suggests that they might focus on “contract-and-policy-oriented architecture (CPOA).”

Continued »

Test SOA for the unexpected

Testing service-oriented architecture requires thinking outside the box to the point that your test cases hit an application with totally unexpected input, argues Thomas Fredell, CTO of IntraLinks. Continued »