Application Platform Strategies Blog

WOA, ROA, SOA: When will it stop?

Blogger: Anne Thomas Manes

Yikes! The "WOA" term (Web Oriented Architecture) has popped up again. Nick Gall first introduced the term in late 2005 at a Gartner Summit. He described it as a subset of SOA that embraces the principles of REST and W3C's Architecture of the World Wide Web. No one really picked up on the term at the time. I suspect it was drowned out by the Web 2.0 hype.

But then Dion Hinchcliff wrote about it (and redefined it) in February this year. And now there's been a flurry of discussion about the term, starting with a post on ZDNet by Dana Gardner in early April hailing WOA as the savior for SOA. Dion followed up with another article on ZDNet recounting Web 2.0 success stories and implying that SOA might be more successful if it focused on WOA instead. But the pundit community has reacted poorly to yet another "xOA" acronym. Mike Meehan at SearchSOA summarized the discussion nicely and asked if WOA brings anything new to SOA. The same day Dana Gardner published a second article on ZDnet entitled "Enough with WOA". And just last week the ZapThinkers weighed in on the discussion, pointing out that SOA and WOA are different levels of abstraction, and proposing yet another term, "Web-oriented SOA". (Please, no!)

Personally, I don't see any value in the WOA term. I don't view it as significantly different from a RESTful style of building services, but Nick provided some additional reasoning behind the term in a post from August 2006, indicating that the W3C Web Architecture adds some additional constraints.

Dion's revised definition seems to miss Nick's subtle distinction between REST and WOA. Dion's definition is essentially REST, and I don't see the point of using multiple terms for the same thing. We already have way too many terms:

• Tim Bray calls it "Web Style".
• Leonard Richardson and Sam Ruby call it ROA (Resource Oriented Architecture) in their book on RESTful Web Services.

Note that ROA has an entry in Wikipedia, but WOA does not. No doubt someone will rectify the situation soon and ensure that the term "WOA" is formally defined and remains to confuse us all.

I find it amusing that Dion's Web 2.0 Success Stories article was indirectly in response to my post calling for SOA success stories. Advocates of WOA/ROA/WebStyle/etc claim that development of services using simpler technologies such as POX (plain old XML) over HTTP will facilitate SOA success. But as I've recounted before, SOA is not about technology. Using REST rather than WS-* isn't likely to improve the success rate of your SOA initiative. Our research makes it clear that the primary impediment is adoption (i.e., getting the business to buy into the initiative and sponsor development of services).

And actually, the most important thing to understand from a technical perspective is that a service should support access via multiple styles of interface. It should enable an application to interact with it using whatever means it wants:

• A method-oriented interface (e.g., SOAP)
• A message-oriented interface (e.g., JMS)
• A resource-oriented interface (e.g., HTTP)

As the ZapThinkers said, SOA and WOA specify different layers of abstraction. SOA specifies a system-level architectural style (i.e., how to implement capabilities so that they can be consumed by many applications). WOA refers to an interface-level architectural style (i.e., the means by which service capabilities are exposed to consumers). WOA (aka REST or ROA) advocates a resource-oriented interface. (Note, though, that many folks interpret WOA simply as POX over HTTP, which may actually support a method-oriented interface rather than a resource-oriented interface.)

SOA is about services at a conceptual level -- not about any particular technology, interface style, or protocol. You should be designing your services for the long-term. It's highly likely that the technologies that are all the rage this year will fade away into obscurity within the next five years. A service encapsulates a capability and makes it available to application consumers through one or more interfaces/protocols. Be careful to maintain a clear separation of concerns between the service implementation and the interfaces used to expose it. Chances are high that you will need to add additional interfaces over time.

Are you in Shape for SOA?

Blogger: Richard Watson

Are you in shape for SOA this summer?  Get ready for the SOA initiative you've always dreamed about by working out with us in the "SOA: Assessment And Planning" workshop at Catalyst North America 2008.

Chris Haddad and I will be presenting tools for allowing you to make an honest and measured assessment of your organization's SOA baseline and a recognition of areas that could be more toned.  As an example, here's a checklist we'll be walking through to assess your Incentive Systems:

People alignment with SOA principles
Mark as True [T] or False [F] 

• Services publicized
• Sharing encouraged
• Open source mindset is present (i.e., solutions delivered to other teams are documented, evangelized, and supported)
• Business stakeholders expected to define capabilities
• Teams discouraged from creating redundant software assets
• Compliance with corporate standards is expected

We will also be sending you away with box of tools you can use to plan the evolution of service-oriented thinking.   Another sneak preview, shown here, gives a checklist for Service Classification meta-data:

Service Classification Meta-data 

• Service Overview (e.g. name, description)   
• Lifecycle Attributes (e.g. version, version relationships, lifecycle status)
• Classification (e.g. basic, composite, infrastructure, business)
• Endpoint Deployment Attributes (e.g. protocols, location, WS-* specifications)
• Data Model (e.g. XML Schema, WSDL, version, semantics, validation)
• Service Level Requirements and Policies (e.g. availability, capacity, responsiveness, security, transaction rate)
• Mediation (e.g. routing, queuing, caching, transformation)
• Service Dependency Attributes (e.g. services, databases, directories, frameworks)   
• Physical Instance Dependencies (e.g. application platform, security, management)
• Business Process Model (e.g. UML diagram, business classification)
• Contract information (e.g. consumers, providers, utilization)
• Usage Guidelines (e.g. time of day, availability, # of users. throughput)
• Accounting or remuneration options (e.g. pay per use, subscription, chargeback amount)

Other tools in that goodie bag include a customizable SOA maturity model, those circuit training assessment surveys and samples for creating your own organization’s SOA roadmap.

OSGi - A Component of the Next Generation Platform?

Blogger: Kirk Knoernschild

There are many forces that influence technological evolution. After a decade of building enterprise applications on the web, today’s enterprise application platform is slowly evolving to the next generation application platform. What exactly are the components of this next superplatform?  Without question, as the next generation platform slowly evolves, a significant aspect will be the programming models and frameworks that team members use to develop and deploy enterprise applications.

The OSGi Service Platform is a dynamic component system for Java. Succinctly described as “SOA in a JVM”, OSGi provides extended capabilities on the Java platform that include the ability to deploy multiple versions of a component, discover new components dynamically, and deploy components without restarting the system. Because component relationships are carefully managed by the OSGi runtime environment, the benefits of modularity yield the potential for dynamically adaptable software systems. After flourishing anonymously in the embedded systems and networked devices market for almost 10 years, OSGi was popularized by Eclipse upon the foundation's adoption of OSGi as its core plug-in technology in 2004. While still in its infancy within the enterprise, OSGi is poised to surface as the core component model of the next generation Java platform.

While Burton Group believes OSGi is an important technology standard worth adopting, what is your perspective? As part of upcoming Burton Group research, I’d like to ask that you take a few moments to complete a brief survey that will inform us on your point of view on OSGi adoption within the enterprise. I'll leave the survey open until May 30, 2008. I appreciate your help

In Search of SOA Success (SOSS).....

Blogger: Chris Haddad

How do you measure SOA success? Why is SOA a risky proposition? Which steps should you take to gain and maintain business support, funding, and SOA initiative momentum? Our recent SOA investigation yields new insights, timely reaffirmations, and straightforward guidance on how to better shape Burton Group’s research and client interactions. In an early June telebriefing titled In Search of SOA Success, I will  present our contextual research methodology, SOA project questions answered, and research project revelations on how we can best partner with you. The presentation will preview  sessions that Anne and end-user speakers will present at Catalyst 2008. 

The following table presents a high level overview of how we structured the consolidated data. How many questions are adequately answered within your organization?

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Report   Card
Question	Focus
Why create a scorecard?	Needs and elements
What is the report card score?	Findings (people,   process, technology, and results)
Why is SOA a risky proposition?	Success Killers   (disconnects,   dysfunctions, missing elements,   mis-directions, and   mis-information)

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Roadmap   dynamics
Question	Focus
Why invest in SOA?	Understand goals   and drivers
How do I implement a service oriented   environment?	Establish   foundation and educate
How do I gain and maintain support,   funding, and momentum?	Establish   credibility, trust, influence, and participation
Is the world flat?	Sell new reality and   path (improve outcomes, realize opportunity, and transform business)

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

<>

 

Success   factors
Question	Focus
How do I mitigate risk?	Success factors
How do I gain social capital and buy-in to   the path?	Think IT1
What actions facilitate adoption?	Take Small Steps
How do I move beyond my current state?	Deliver value

I look forward to our future conversations.  Stay tuned for an update to the telebriefing registration page.......

Face-to-Face Guidance on REST, SOA, and SDLC

Blogger: Chris Haddad

Have you viewed Pete Lacey's REST Take5 presentation?

The REST presentation is a short introduction to Burton Group's popular REST Easy workshop. The workshop will be presented at Catalyst North America 2008;. Additional workshops will cover 'SOA:  Infrastructure Reference Architecture', 'SOA: Assessment And Planning', and 'Improving the Software Development Process'.   

If you are interested in getting face time with Burton Group experts and discussing REST, SOA, or SDLC topics, take a deeper look at the workshop abstracts.