REST will free business process management from its shackles: prediction

REST will free business process management from its shackles: prediction

Summary: Growing interest in the cloud, and a desire for more vendor independence, may drive REST deeper into the enterprise BPM space.

SHARE:

The REST protocol has been known for its ability to link Web processes in its lightweight way, but at least one analyst sees a role far deeper in the enterprise. This year, we'll see REST increasingly deployed to pull together business processes.

ZapThink's Jason Bloomberg predicts the rise of RESTful business process management, which will enable putting together workflows on the fly, without the intervention of heavyweight BPM engines.

People haven't really been employing REST to its full potential, Jason says. REST is more than APIs, it's an "architectural style for building hypermedia applications," which are more than glorified Web sites. REST is a runtime workflow, he explains. It changes the way we might look at BPM tools, which typically have been "heavyweight, integration-centric tools that typically rely upon layers of infrastructure."

"With REST, however, hypermedia become the engine of application state, freeing us from relying upon centralized state engines, instead allowing us to take full advantage of cloud elasticity, as well as the inherent simplicity of REST."

The shift will take time, beyond 2012. But with growing interest in the cloud, and a desire for more vendor independence, means its time for RESTful BPM.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

7 comments
Log in or register to join the discussion
  • RE: REST will free business process management from its shackles: prediction

    I hereby deem "REST" to be an overused term, that has strayed far from its original meaning -_-.
    CobraA1
    • RE: REST will free business process management from its shackles: prediction

      @CobraA1 REST has ALWAYS included the constraint that hypermedia are the engine of application state. But it's quite true the meaning has strayed. I'm helping to bring it back.
      jbloomberg123
  • But you promised us that with XML!

    I predict the next integration tool will be called "Wolf".
    jorwell
  • Business Value not Dogma

    REST is widely misunderstood, but it is no more the 'silver bullet' for everything than SOA ever was. Adopting all of REST's constraints dogmatically, including HATEOAS, involves trade-offs as with anything else in Software Architecture. REST promotes loosely-coupled clients, but that poses an issue regarding 'Shared Understanding' between Client and Servers - if they are truly loosely-coupled, how do they share intent/meaning? To date, there is no global standard on the Media Types that might make this happen. There are quite a few other considerations as well. It's not to say there can't be REST-based processes, in fact they exist already, but they have some limitations.

    In addition to describing the architecture of the Web, Roy Fielding, in his seminal dissertation, promoted 'intentional architecture'. His biggest contribution might be to have gotten people to re-think conventional approaches and build solutions up from a 'null-set' of constraints.

    We might find the best solutions fuse aspects of SOA and REST architectural styles in thoughtful new ways.
    dduggal
  • RE: REST will free business process management from its shackles: prediction

    Hi.<br>1. Sorry, Joe, but I need to clarify that REST is Not a protocol as you state in the first line. Sorry.<br><br>2. Cesare Pautasso has a couple of presentations in InfoQ discussing about BPM and REST relationship, although it gets confusing sometimes at the approach. At one time it is said BPM can use REST web services, and at other time it is said we can use BPs as resources in REST.<br><br>3. Christina Lau mentioned this idea long ago (2008) when presenting the Zero project from IBM at Devoxx, although the REST concept was not quite right.<br><br>4. Finally, using REST as a workflow is just taking ONE part of the constrains (the HATEOAS) and use it as a workflow idea. All the other ones may be an actual mismatch of what BPM requires. Say, REST is a data-in-a-network oriented style, not suitable for high processing, while a business process is actually a process! I feel a derivation of REST ideas may be used to reduce BPM underlying infrastructure, but for sure full REST is not suitable for that.<br><br>William Martinez Pomares.
    willmarpo
    • RE: REST will free business process management from its shackles: prediction

      @willmarpo Thanks for the clarifications, William. Is it more proper to refer to REST as an 'architectural style'?
      joemckendrick
      • RE: REST will free business process management from its shackles: predictio

        Sorry! So long time waiting for the reply, but I didn't see this question before.
        Yes, sure! REST is an architectural style, whose constrains may be used to construct architectures. People may say it may be use to create APIs or Services, but those are secondary products, not its main objective.
        Cheers!
        willmarpo