'Bare-knuckle SOA': workaround to complexity proposed

A way to stand up services without complex tools or frameworks. More Guerrilla SOA?
Written by Joe McKendrick, Contributing Writer

Johannes Brodwall, software architecture advocate, is floating a concept he's calling "bare-knuckle SOA." Essentially, he urges a simpler and cleaner way to stand up a service, without relying on complex frameworks.

"I’ve encountered teams who, when working with SOA technologies have been dragged into the mud by the sheer complexity of their tools," he writes. This is a challenge seen across the spectrum, from Java to C#.

This has shades of Jim Webber's "Guerilla SOA," which advocates lightweight service engagements that emphasize rapid, incremental service development and deployment working closely with stakeholders, eschewing reliance on middleware, frameworks or enterprise service buses.

Johannes admits that while his bare-knuckle approach "requires more hard work than adding a WSDL (web service definition language. Hocus pocus) file to your project and automatically generating stuff," it "comes with added understanding and increased testability."

Ultimately, the end result is faster deployment of services, he says.

Johannes offers a multi-step process for quickly building and deploying a geolocated currency email service that identifies a user's primary currency based on location, and notifies them when their currency drops below a threshold relative to the US dollar:


  • Create your active services by mocking external interactions.
  • Create a test and a stub for each service – starting with GeoLocationService.
  • Validate and create the XML payload. "This is the first 'bare-knuckled' bit," Johannes states. "Here, I create the XML payload without using a framework. I add the XSD (more hocus pocus) for the actual service to the project and code to validate the message. Then I start building the XML payload by following the validation errors."
  • Stream the XML over HTTP.
  • Create the stub and parse the XML.
  • Write a separate test to check the service.
  • Validate and parse the response.



Editorial standards