Why API services need more intelligence to interact

Why API services need more intelligence to interact

Summary: Service-based infrastructures are still too brittle. Time for 'agent oriented architecture,' says a long-time service integration advocate.


One of the challenges of REST or SOA-enabled service integration has been its brittleness. Integrated configurations often break when changes are made to metadata associated with APIs, relates EnterpriseWeb's Jason Bloomberg.

National Gallery of Art Photo by Joe McKendrick
Photo: Joe McKendrick

"Whether they be Web Services, RESTful APIs, or some other type of loosely-coupled interface, every approach to software integration today suffers from the fact that interactions tend to break when API contract metadata change," Jason states in a recent post. 

To that end, Jason, a long-time SOA advocate and author of The Agile Architecture Revolution, proposes something called "agent oriented architecture," in which intelligent agents address changes in APIs. (EnterpriseWeb offers such a product.) Intelligent agents can "resolve differences in interaction context between disparate software endpoints dynamically and in real time," he writes.

An intelligent agent would sit between the clients and the source of the service, essentially posing as a RESTful client itself -- even when the software client does not, Jason explains. The agent can interact with any type of resource, and "constructs a custom response based on latest and most relevant information available."

Don't confuse intelligent agents with traditional service brokers, he adds. While traditional broker "must rely on static transformation logic to resolve endpoint differences, the agent must be able to interpret metadata, as well as policies, rules, and the underlying data themselves to create real time interactions that maintain the business context – an example of dynamic coupling, a central principle to AOA."

AOA, Jason adds, helps enterprises move beyond the static API structure that currently characterizes many integration efforts. "The focus of both SOA and REST has been on building loosely-coupled interfaces: static, contracted interfaces specified by WSDL and various policy metadata when those interfaces are Web Services, or Internet Media Types and related metadata for RESTful interactions," he writes. "Neither approach deals well with change. AOA, in contrast, relies upon dynamic coupling that responds automatically to change, since the agent interprets current metadata for every interaction in real time."

Topics: Software Development, Cloud, Enterprise Software, Web development

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


Log in or register to join the discussion
  • SOA and REST?

    Sorry, but SOAP does not equal "Web Service" except in Microsoft's mind a decade ago. A RESTful or REST-like service is just as much a Web Service as anything rigidly bound through WSDL. SOAP is basically dead.

    Web Service does not equal SOA. You can use Web Services to implement any old architectural patterns.

    "Agile" is a buzzword used by traveling medicine show types, peddling their books and speaking engagements and consulting services. Little ever comes from these and the entire field was discredited years ago when Tom DeMarco recanted and spilled the beans about these scams.
    • This isn't a Microsoft article.

      Why are you mentioning MS?

      This is about APIs.
      • Vaguely

        "This is about APIs."

        Vaguely. Recently, Joe seems to have taken upon himself to use the term "API" in unusual ways that I'm not sure anybody else really agrees with. He's practically using it as slang for "languages" and "protocols" now.
        • REST facilitates the provision of APIs

          It doesn't even really do anything else - there must be an API for REST to be of erred. It would be passingly strange to do a REST related article and not discuss APIs!!!
      • I don't agree with the comment

        but it is an appropriate comment. Microsoft played a big hand in the rise of web services, and it would be a strange thing indeed for them not to have come up in this discussion at some point.

        That said, REST is definitely a web service technology. REST was a reaction to the complexity of SOAP and XMLRPC, and how you had to set up complex binding and metadata just to get talking. Some of the languages or environments take the complexity away (Visual Studio and PHP do, for instance), but the complexity is still there.

        But REST is used as a "web service", so why on Earth wouldn't it be called one? They are services, and they are on the web. An obvious, "duh!!"
  • What drivel...

    Intelligent agent? So he wants to introduce an AI middle layer that automatically translates from an old contract to a new contract? How delusional. How about this instead. Don't integrate APIs whose authors don't provide smooth transitions from version to version.
    • Problem is

      You never know when someone is going to go rogue like that. I agree with you, that's the best solution, but it is hard to know in advance when someone is going to decide to cause you that kind of grief.
  • I don't think REST services tend to have this problem too much

    as they do not have contracts. There is no metadata. The only reason a REST service would have problems continuing is if the posted data (in JSON or XML) sends in an array or collection as parameters that is incompatible, or gets one back that is, and a developer taking care not to blow up client calls, could make sure that all the changes are additions, and not subtractions.

    The biggest problem in all of this is not in the technology, it is in the people offering services on it... a good example was when DropBox simply downed their old 1.0 API, and offered a new one. That kind of thing is a real pain in the butt, as it breaks shipping apps that are out there. If you want to make changes that drastic, just deprecate the old one, but for heavens sake, keep it running!

    Rather than an "intelligent agent" (which probably puts the onus on the client developer), if the service developer doesn't want to maintain an earlier code base (a la the deprecated API scenario described above), they could turn their old API into a compatibility wrapper, keeping the maintenance aspect to a minimum.
  • Agent-Oriented SOA

    Jason’s 1,200 word blog post is marked “introducing…”, it doesn’t strive to tell the whole story, rather it introduces concepts that we implement in our software platform that is in production on four continents. I’m glad it has triggered a healthy discussion.

    As I’ve already noted on Twitter, we’re happy to be considered part of a big-tent, non-dogmatic SOA. In that regard, AOA is a way of denoting that we extend/enhance SOA in interesting ways, just as EDA is a style that compliments SOA – the use together is not contradictory, it’s explanatory.

    AOA can be summarized as APIs with Uniform Interfaces to Models that are dynamically interpreted by Agents. If we must use OOP terms, the system is a façade of sorts for a behavioral pattern of sorts. This allows greater separation of concerns as data and methods bind late (dynamic configuration). Agents act as distributable Transaction Managers / Context Brokers that translate models to concrete resources in real-time based on context (models, metadata, policies, algorithms). The agents handle all connection/transformation details “for free” – they automate interoperability itself, extreme late-binding helps fulfill an original vision of SOA providing semantic “find and bind” that was never realized.

    In addition, we are providing a “full service”. Models can be nested so functional and non-functional concerns can be handle together, eliminating challenge/discipline required to do this in a conventional SOA environment. In this way business compliance, IT governance and system controls can be all dynamically policy-controlled. Our agents are able to do this at millisecond speed including writing and indexing all updates for a “live” self-curated environment.

    I understand folks who have wrestled with this for a long time maybe skeptical, but as Galileo is purported to have whispered under his breath after recanting the motion of the planets around the sun “and yet it moves”.

    Yes “agile” is a buzz word that has been abused, but it does accurately depict a platform that supports real-time responsive / adaptive applications and processes.

    I’m glad that SOA is an established and now finally a broad concept for modular software architecture, but no one can claim SOA, in and of itself, has been an unqualified success or that the Enterprise IT Architecture journey is complete.

    While SOA is the defacto architectural style for the horizontal and elastically scalable Cloud infrastructure, conventional Service Orientation has left us building apps with the same-old 3-tier vertically integrated architecture. We’re simply recreating same ol’ silos in the Cloud, compounding the on-premise IT management challenge with distributed geographies and diverse SLAs. The SOA app layer is brittle, the SOA process layer is stateful, governance is challenging – this is sub-optimal at best.

    Our dynamic platform with its Agent-Oriented-Architecture style is helping push SOA to the next level.

    We are at an inflection point in IT, disruption is here. It’s a time to be curious, not reactionary.


    Founder/Managing Director
    • Hmm, not the way I'd want to work with agents

      That's just bringing back the pain of EDI, which web services were a reaction to. Nobody wants to publish to some huge interface with a thousand touch points, because the agent has buried an API into some of the standard touch points.

      The best way for agents to work, if that is to be, is to provide wrappers that emulate earlier versions of an API, but talk to the newest version. That's the least painful thing to do to calling clients, at any rate.
      • Clarifying

        Hi Mac_PC_FenceSitter - This is not your father's EDI. The system is fully Declarative, all relationships and history can be projected as graphs and can be navigated by humans and systems (dependency maps, interaction trace, etc). We provide visibility, particularly when you consider rise of composite apps, that folks don't have otherwise. I appreciate historical references, we do build on some of the earliest ideas in CS re: high-level programming, but we implement them in a way that is performant, scalable and manageable. You might just need to see it to believe it.

    • Complex as SOAP

      This just sounds like a lot of additional complexity, bringing it to the level of SOAP in that regard. This just sounds like a dynamic ESB to me.
  • word game

    First, I find it very indicative that Joe has not expressed his own opinion on this another "revolution" from Jason (well I know both for some time already).

    Second, reading these accurately chosen and composed extracts, I do not see _any_ difference between represented "agents" and normal business services defined and described in OASIS SOA standards (RM and RAF). And who has said and when that a service broker has to work with static endpoints? This is how vendors implemented ESB products but an ESB Service Pattern does not have such limitation: a bus has to resolve the destination end-point using any possible way - static or dynamic. I hate when people, especially specialists, mix architecture with technology implementation sins.

    I think that the whole game here with new "agent oriented architecture" is only about showing that SOA is not needed anymore and can be replaced by API. What a naive movement! Service Orientation was for centuries and will be the only one basis of any business, with or without technology.

    Also, what does mean "agent oriented architecture"? If a consumer is interested in something to be done according _fixed_ agreement with Service, there is no need for orientation on agent; it does not matter how a consumer interacts with the service, via REST or telephone, from the business perspective. If IT starts to orient on agent, it will end up the same way when it was oriented on Web Services instead of Services, i.e. in a grave (since 2009). Neither Web Services, nor REST, nor Agents constitute a service. This is what Jason taught me years ago about SOA, and I thankful him for THAT.
    Michael Poulin