member login

WebServices dot org

Todays Featured Content:

StrikeIron Jump-Starts 2008 with Multiple Industry Honors

CMP’s Intelligent Enterprise Web site announced its 2008 Editors’ Choice Award winners with StrikeIron included among its 36 “Companies to Watch” in the enterprise application category. StrikeIron was also included in Robin Bloor’s list of “10 IT Companies to Watch in 2008.”

read more
StrikeIron Expands Web Services Marketplace with New Financial and Business Data Services from Gale

In-depth financial and corporate information on hundreds of thousands of U.S. and international companies: Two new Financial and Business data services from Gale, part of Cengage Learning, have been added to StrikeIron's expanding Web Services Marketplace: Gale Business Information Web Service 1.0.0 and Gale Business Intelligence Web Service 1.0.0.

read more
StrikeIron Delivers Data Web Services via IBM QEDWiki

StrikeIron Inc., a provider of Data as a Service (DaaS), today announced that it has aligned with IBM to deliver premium web services via IBM's enterprise mashup maker QEDWiki. Content available includes business intelligence services such as multiple D&B services, Address Verification, Email Verification, Currency Rates and many more.

Full story from www.ebizq.net
StrikeIron Super Data Pack

Start working with Web services and live data instantly! The Super Data Pack brings together dozens of Web services into one easy-to-use “Super” Web service. With the Super Data Pack, developers and end-users can leverage multiple data sources for use within a diverse set of rich applications at no cost or with no commitment.

read more
Featured Content provided by StrikeIron, Inc.
Next: SOA, Agile, and XML Software Development

More on “SOA, Agile, and TDD”
4th Apr 07:

Share tests? How is that done? How does a .NET person share their test with a legacy COBOL person?

The SDWest event was held this week, and it appears that one of the highlights was Amr Elssamadisy’s tutorial on how agile, test-driven development methodologies are applicable in a SOA. The article reviewing his session can be found here. Amr points out a fundamental problem of code ownership for web services developers:

"

“Agile requires that you fix what you break. So if you change the service your team is writing, you must fix whatever that change breaks in the clients using that service. You're responsible for your own messes. SOA, on the other hand, usually assumes that there be no collective code ownership. So you can't fix someone else's code. What's needed is a way for the team developing the service to run a test to see if their change will break any clients. If they don't own the code, then how does this happen? Through the sharing of tests.”

"

We totally agree with Amr. But, share tests? How is that done? How does a .NET person share their test with a legacy COBOL person? These arguments perfectly highlight a lot of the thinking around what Mindreef builds. We believe that this level of SOA quality is around the interfaces between services and the semantic ways that those services are used. We have built our tests independent of the language or platform they were implemented on. This way anyone can understand the tests and add to them. As a server we are always on, which means when there is a new consumer to a service (which may be months after the service is deployed) they can add to the test suites for that service to show how they semantically use that service. So now when the service is updated, they are running a larger set of test suites that include all of their consumers and users can actually know if they are breaking any of them. It also means that if a service does not work the way a consumer wishes, they can produce a test that shows what they need, which can then act as TDD for the next iteration of the service.
Now if we could only figure out Load Driven Development (LDD)…..


Trackback URL for this post: http://www.webservices.org/trackback/id/83621

Comments

Collaborating on SOA Testing isn't Optional

Jason English

Thursday 05 April 2007

The topic at hand in Amr's talk was munging a process model (agile) with an architectural pattern (SOA).

Amr's right about the need for testing, but it's not test-driven, it's more collaborative. Indeed, the developer/owner of an implementation needs to test, then they need to expose those tests to the larger community as proof that their components are not just structurally interoperable, but that their application components remain sound at a behavioral and performance level. And it must be continous - not just "test first (TDD)" and/or "test at the end (TATE, I just made that acronym up)..."

It would be nice if we could afford to stay in the semantic layer like Frank is mentioning -- but compliance between services gives us very little visibility into whether the implementation layer (where the business logic actually resides) is worthy of trust. All the pinouts may line up semantically, but the end result in the real world is an emporer with no clothes. So to trust SOA, we will need to collaborate at a much deeper level and think of it as a continuous process and not an event. The services, and especially the implementations, must be submitted and certifiable (functionally, and at load) to the community relying on the SOA.