Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

Is REST Successful in the Enterprise?

Some might prematurely conclude that REST has won based on Programmable Web data: 73% of the APIs are RESTful. But Steve Jones, a SOA practitioner, draws attention that those APIs are used by front-end systems doing data aggregation and not by the majority of enterprise systems, and REST is not yet ready for the enterprise.

Clay Loveless, former CTO of Mashery, held the presentation “Lessons from the Failure of SOAP” at Glue Con 2011, sharing some statistics from Programmable Web, an API resource indexer, showing that SOAP has grown over the years, but it has a smaller share than REST, which has had consistent growth:

So what would doing the same query on the likes of Oracle, SAP, IBM or Microsoft's enterprise technology stacks deliver? I assumed the number to beat would be huge and got ready for some serious searching.... but the number to beat is 2368... errr seriously? I've worked in single enterprises where they had more SOAP endpoints than that. When you include the libraries of WSDLs from SAP and Oracle and the Behemoth that is Oracle AIA has so many that Oracle don't boast about it as it might make it look complicated. Back in 2005 folks at Oracle boasted about over 3000 web services across their applications.

Touching on the REST vs. SOAP controversy, Alex Williams, an Editor for ReadWriteWeb, reported from Glue Con that SOAP is not dead but it is “undead and will remain that way for some time to come”, because SOAP is entrenched in the enterprise and it is hard to get rid of it.

SOAP isn't undead, its very much living in the enterprise and indeed being the only real viable approach when integrating package solutions from a number of vendors (a massive piece of enterprise IT). REST however barely registers, less than 2500 APIs after all these years of development? Pathetic.

REST for the enterprise isn't undead... it’s been still-born for over five years.

Let’s be clear, I'm talking here about REST as an enterprise integration approach, not as a way of exposing a Web API for content aggregation but as a functional integration approach for enterprises. Something to replace the "fundamentally flawed" WS-* that REST is so much better than. So what is the progress this year? Zip, zero, nada. Yup a few minor tweaks into enterprise stacks that say they can produce REST interfaces, but in reality most of them can't and the key problems of interface publication, versioning and testing remain unsolved.

InfoQ has contacted Clay Loveless and John Musser, founder of Programmable Web, in an attempt to get their reaction to Jones posts on enterprise and REST.

Loveless agreed with Jones that SOAP will stay alive in the enterprise for a while, but REST will prevail in the end:

I think Steve Jones illustrates a good point, which I mentioned in my talk: SOAP will live on for a long time, especially in the enterprise.

The enterprise is slow to adopt to change, and is heavily driven by the vendor-customer relationship. If a middle-manager in the enterprise can't spend some money on a support contract somewhere, they feel like they're not doing their jobs right.

The enterprise has always, and will always, lag behind the commercial space. In the commercial, B2C world, REST has won, and John's [Musser] numbers prove it. When companies begin realizing that they can't hire effectively for SOA positions, and that they can build faster and cheaper with REST, they'll start shifting. This won't happen for awhile, but it'll happen. Also, the printing press is dying, as is Blackberry, though plenty in both of those camps are busy denying that as well.

Musser, who held a keynote at Glue Con 2011 on the State of the API and showing the same data contained in the charts above, believes that a trend has been set and REST will eventually conquer the enterprise:

I agree with both Steve and Clay that SOAP APIs will have a long future within the enterprise. The primary driver may or may not be a technical REST-vs-SOAP decision, be it on technical merits or something from the CIO's office, but instead driven more by incumbency. As Steve notes there are thousands of applications and many enterprise tools that are rely on SOAP and WS-*technologies.

What I was referencing in my talk last week was that if you look back at 2005 there was indeed a strong SOAP presence in web-based APIs but if you look at what's happened over the intervening 6 years, it's clear that REST is taking a larger and larger share of the market. It's not so much about total number of implementations or endpoints to date, it's about where the trend is heading. And if you look at what enterprise-focused vendors are aiming towards, it's REST. They're of course not abandoning SOAP, but take a look at what Salesforce.com is doing (they've been SOAP only for nearly a decade and now are adopting REST, or a Microsoft's Azure platform).

We also contacted Steve Jones to get more details on why he thinks REST is not yet fit for the enterprise.

InfoQ: You said that REST has had zero progress in EA integration over the last year. What do you base your remarks upon? Do you have any numbers? Is it based on your experience inside the enterprise you work for?

SJ: I've seen some REST work done in enterprises but always at the Web end of the equation and never on the internal integration between enterprise systems. I also base it upon exactly those stats from the Programmable Web, an example is their one SAP link (https://streamwork.com/developers) which is indeed a REST API and working in the area where REST works... front end integration and aggregation.

The programmable Web lists less than 2500 APIs and only one from SAP and none from Oracle. This indicates just how little awareness the REST community has of the reality of enterprise integration and its challenges.

InfoQ:You noticed REST's progress for content aggregation, but you said REST did not make much progress for EA integration. Would you mind making the difference between the two domains? What does it take to make it useful for EA? Interface publishing and versioning?

SJ: Data vs. function. When I want to see all of the accounts from 5 different systems displayed on one page then a REST approach is great (as long as it’s backed by an MDM solution to enable the customer keys to be identified in each system). If however I want to create something that opens five accounts, communicates that to the billing system and does so in a way (and this is the critical bit) that the teams can work independently then REST breaks down.

Enterprise Integration is about separation of domains to enable them to work independently with well defined boundaries. These boundaries are often contractually enforced via outsourcing deals or technically enforced by package vendors. RESTs mentality is that these boundaries are fluid and that making them rigid is a problem, the reality is that having ridged boundaries is actually a good thing as it enables teams to work independently. Thus the ability to publish a functional contract (the WSDL) which can be consumed in multiple technology stacks is a key benefit of SOAP/WS-*.

To the point about REST and MDM, this is a good example of the boundary. REST needs to be able to aggregate information from multiple systems about the same customer. A "true" REST approach would have a central customer system that all people reference via a URI and thus this would be the unique ID. The reality is that systems like SAP and Oracle will always retain local copies of customer information so some form of functional integration is required and information synchronization. This is where WS-* comes in as it provides a way of publishing both the "create customer" functionality and the "sync customer" return.

The reality of enterprise integration is that taking an approach such as MDM has a bigger impact on the complexity and flexibility of integration than the specific technology used for the plumbing.

InfoQ: How do you see the future of REST?

SJ: Lots of hype and people complaining that others don't "get it" while ignoring the actual flaws would sum up its past to date. What I hope is that the REST crowd will wake up and start agreeing on a set of standard ways to describe the FUNCTIONAL interface for REST (http://service-architecture.blogspot.com/2010/01/define-standards-first.html) this really is the very basic stuff but many folks argue that this goes against RESTs principles. Maybe the problem is that REST is fundamentally about data traversal and aggregation and it’s not suited to more functionally oriented approaches.

InfoQ:How do you see the future of EA integration if REST is not the solution and SOAP is blamed for its complexity?

SJ: Enterprise Integration IS complex, it’s more complex than most Web Integrations that people think are complex just because they are high performance. Speed != complexity. There is complexity in enterprise integration but it has little to do with the technology difference between REST and SOAP, REST is significantly MORE complex today for enterprise programmes because of its inability to agree a standard way to define a functional interface.

Approaches that would improve enterprise and B2B integration would be the ability to add MORE formalism to these interfaces so there is less arbitrary documentation, as an example the ability to specify that a date of birth must be in the future or that a credit check has to be performed BEFORE opening an account would help significantly.

Blaming SOAP for the complexity of B2B and Enterprise Integration misses the point of where the complexity comes from. The complexity comes from the need to integrate multiple different business domains and a standard lack of core business and technology approaches (such as MDM) which would make this easier. The technical plumbing approach is just the bit that shifts XML across the wire, SOAP makes this EASIER than older approaches and so its reduced complexity. REST hasn't made it easier so it’s not being used.

Jones added on Twitter: “mosesjones: I might be wrong and REST will win in the enterprise but the REST crowd has to start being practical rather than technical.”

What is your experience? Is REST fitted for your enterprise? Have you solved the problems mentioned by Jones? Do you see REST taking SOAP’s place in the enterprise in the future?

Enterprises move fast... when it works...

Your message is awaiting moderation. Thank you for participating in the discussion.

I think Clay is wrong on the enterprise being slow to adopt to change... when it works. It was about 4 years from SOAP/WS being a twinkle in people's eyes to it being the de-facto approach to enterprise integration. REST folks like to pretend that the enterprise is slow, cumbersome and a bit stupid but the reality is that when a technology works it spreads exceptionally quickly, hence the reason that it took only a few years for WS-RM, WS-Security and the rest of WS-* to be agreed... enterprises move fast and their vendors move very fast which meant that tools, automation, testing and security products were all available exceptionally quickly.

By contrast in the REST space the "evolution" of the last 5+ years has seen a few more APIs, with a couple from enterprise class vendors, but few standards, even on new meta-types, and practically no tooling or automation.

Maybe REST will win, but in the enterprise integration projects starting today my experience is that SOAP is still totally dominant with MQ Series and other message based approaches being second, REST might come in fourth behind ETL.

Web APIs for the Browser / SOAP/WS for the Backend at our Enterprise

Your message is awaiting moderation. Thank you for participating in the discussion.

The look-ma-no-contracts style REST does not actually exist (maybe we should give the term REST some rest). What we have is web APIs that have implicit contracts (but no metadata to describe the service interface).

Server-to-server interaction is usually WS* based because the tooling can easily handle WSDL based service interfaces. Browser-to-server services end up being HTTP based.

There are many compelling reasons for sticking with SOAP on the backend. For example, pub-sub and asynchronous messages through ESBs and XML Gateways; B2B messaging with WS-Security, etc. Seems that enterprise developers prefer certainty of XML Schema (at the cost of some flexibility) for service interfaces.

relieved agreement - but the technical debate is not pointless

Your message is awaiting moderation. Thank you for participating in the discussion.

These observations match perfectly with my experience in integration projects - and it's with some relieve that i say this, as i was wondering whether my sample of the software development space is hopelessly unrepresentative. I can now resurrect my long-held suspicion that it's merely under-reported in the technology media.

However, the "purely technical perspective" of "the differences between SOAP and REST" is not a "pointless discussion": it may be stale now and exhausted, but without contrasting and comparing technologies on a purely technical basis we would lose the rigour that any technical domain requires. Of course there is more to the discussion than the "purely technical perspective", but i've always had the impression that this has been addressed adequately with the notions of "architectural style" and "business services". What Jones seems to be advocating instead is a discussion of "success" and "failure" as measured by adoption across the industry, and to look for reasons of such measurable "failure" (such as the lack of a precise interface definition languages such as WSDL).

What's more to the point is "people complaining that others don't 'get it'", as Jones puts it, as this points to the unfortunate fact that as people become immersed in one way of seeing the world (you might call it an ideology; such as WS-* or REST, or statically typed or dynamically typed) they inevitable come to see it as the truth - it becomes so obviously true. But it isn't: it's just one way of making sense and reasoning about what's out there (with particular characteristics and properties - which is why we (also) need the purely technical debates). Sadly, in software development, truth claims for one's own viewpoint often end in insults against the opponents: they "don't 'get it'".

REST - POS over HTTP

Your message is awaiting moderation. Thank you for participating in the discussion.

It never ends, the debate over distributed point-to-point communication protocols. And, needless to say, it never will. I've programmed all the great protocols, believing fervently in everyone. And yet REST reminds me of POX/HTTP with a slight text-like twist. As much as I dislike a WSDL, at least it's a discoverable and programmable contract. Yet I still dread the WSDL/XSD relationship; yet have no better idea (besides my own protocol;). May the the distributed protocol war continue! I'm a big fan.;)

Re: REST - POS over HTTP

Your message is awaiting moderation. Thank you for participating in the discussion.

Mike,

there is a difference between saying a bunch of BS and discussing the merits of approach A) vs approach B), (and we all know that software engineering is all about tradeoff). If you want to call that a "war" you are free to do so, but in the end nobody wins that war except the few individuals who started it. I deal daily with people trying to invoke X,Y or Z so called REST API who can't set the headers properly, sign properly, be sure of which verb to use, there are so many options that you have to set manually, that basically everything is up in the air.

Yes, I can see situations where you would want to put up with all that crap, because SOAP and XML would actually be worse. Now trying to tell people to jump ship and leave behind what works reasonably in their context is, how should I put it? ... I'll you decide how you want to call that, but I am glad the enterprise is no falling for that. As Tim Bray was saying, ... the REST emperor has no cloth, REST is beyond naked IMHO.

Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Service Orientation is the wrong paradigm for information-intensive applications. Encapsulation precludes practical run-time customization of service boundary based on context, so you are left with design-time smells. Commodity Services are either too generic to be useful, or too specialized to be broadly applicable - there goes your specialization and re-use.

REST is an architecture for Ultra-Large Systems, not for enterprises, but Resources are the ideal artifact for next generation distributed enterprise networks.

We offer an integrated data and application virtualization platform completely based on Resources. Dynamically configured protocols coordinate Resources at run-time to perform as Services.

The result is rich information-intensive and context-aware apps of ERP and Expert System complexity, using a Uniform Interface with no CRUD; just Resources configuring Resources in event-driven, goal-oriented, serial mashups guided by declarative protocols.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Dave,

>> Service Orientation is the wrong paradigm we would have to agree on what is meant by SO to agree that it is wrong. In the end REST raised a lot of important questions in terms of what are the optimal semantics of communication within connected systems and what are the relationships between these semantics and the programming model on each side of the communication.

Unfortunately these questions always were overtaken by the BS to hype a "new" way to do something as old as computing, and the need to "burn" everything else down.

I was talking to the CTO of a well known startup in the valley recently who told me "what are the RESTafarians thinking?, this thing makes no sense, all we are doing is API calls" I think that's where we are today, 10 years behind, where we were in 2007.

Today, I can safely predict that HTTP will be phased out quickly as people start realizing how much optimization can be done when billions of calls are made to a given endpoint ... This story is far from finished.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi JJ - In our past communications you've been enthusiastic and even praised our use of Resources, declarative protocols, etc., but in any case...

You dropped a material part of my statement - "Service Orientation is the wrong paradigm for information-intensive applications." So it was qualified comment, one that is supported by most anyone familiar with the distinctions between Resources and Services. You could argue that the need for Data Services in a separate virtualization layer is enough to bear out my point. Of course, Data Services themselves don't escape limitations of encapsulation.

I never said SOA or anything else was irrelevant, so your response seems to be a bit over the top. We virtualize Services and Business Systems with RESTful endpoints, so we can augment other environments including SOA quite nicely.

Technology is neither good nor bad, but it can be optimal or suboptimal for purpose - I'm going to stick with my statement.

Re: Web APIs for the Browser / SOAP/WS for the Backend at our Enterprise

Your message is awaiting moderation. Thank you for participating in the discussion.

Server-to-server interaction is usually WS* based because the tooling can easily handle WSDL based service interfaces.

Faisal,

I agree that in *certain* situations the tooling can easily handle WSDL-based service interfaces. This would be when you have a simple WSDL and simple types and "compatible" WS toolkits. But I can assure you that in other cases, that is decidedly not the case, and the word "easily" should be replaced by the word "not", as in the case with Microsoft's very complex Exchange service, to give one example. SOAP, interestingly, fell into the same trap that CORBA did, in which we were supposed to have interoperability, but with all the complexity layered on, that wasn't the case. So perhaps in the "enterprise", where the WSDL and the WS libraries can be controlled, SOAP is workable, but in other cases, REST may be a better choice. Which is what I think this whole discussion is about. Put me in the "entrenched in the enterprise/sunk costs" boat.

In other comments on this post, I've seen the argument that SOAP is discoverable. To take up Jean-Jacques's challenge, here's Steve Vinoski's (wrote the book on interoperability) thoughts on that:

As I once remarked in a blog entry, I've never seen anyone develop an IDL/SOAP/WSDL-based client without referring to human-readable documentation. Nobody writes a client that simply goes out, discovers such services, and starts using them. Among other problems, the specialized interfaces required to communicate with the newly-discovered service makes this hard to do. Keep in mind that each specialized service interface is effectively a new application protocol.

Re: Web APIs for the Browser / SOAP/WS for the Backend at our Enterprise

Your message is awaiting moderation. Thank you for participating in the discussion.

Robert,

I agree that human readable documentation is required in addition to WSDL/XSD but that is supplemental. Most of the heavy lifting of building the plumbing code is done by the tooling; greatly reducing programmer burden and errors.

Even for human readable content, we are leveraging WSDL/XSD in-line annotation and surfacing that via an InfoPath form for easy human consumption.

By and large this system is working well and service use is seeing healthy growth within the enterprise and with our B2B partners.

For B2B, we route Web Service messages via XML Gateways where we enforce schema validation and WS-Security (x509 based signing and encryption). Or run the (one-way) messages via an ESB (leveraging WS-Addressing) to reduce temporal coupling and to improve reliability.

Which is not to say that WSDL/XSD based interfaces are perfect and there are no issues - but on the whole the system is working for us.

If something better comes along then I am all for it but I am still waiting.

I think there is mass confusion about what REST is. Most people think Web APIs are REST. As Dave Duggal points out REST is not about SOA; it is about building long-lived networked applications that are resilient to changes (in resources). As JJ stated, proper REST is *very* hard to do.

For building services without machine processable metadata - most Web APIs - or with - Web Services, Protocol Buffers, OData, etc. - I tend to favor the latter. Maybe the answer is RDF/OWL or what Ideate is offering (both with machine processable metadata).. still waiting.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Dave,

I have explained several times how "Resource Orientation" was essential to a healthy "Service Oriented Architecture" and how the two related via the concept of a resource lifecycle, I'll step away from these statements because they represent the fundamental way how "information" operates ;-). I obviously disagree with your statement, SO IS-A great paradigm for "Information-Intensive" applications.

>> Technology is neither good nor bad, but it can be optimal or suboptimal for purpose - I'm >> going to stick with my statement.

The problem with "technology" discussions is that they always obfuscate the foundation in which they are built. And since they are built by individuals, with more or less understanding, time and resources, technology is generally far less representative of the foundation they are supposed to reveal.

I would rather speak at the fundamental level, we see with Roy's thesis, the benefits of doing that. Independent of any technology, including HTTP and push well beyond the boundaries of Resource Orientation, well beyond "REST" and Roy's thesis.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi JJ,

We can agree to disagree, agreeably. I'm not a fundamentalist, but we were intentional in our design and as you know we use protocols to choreograph Resource transformations and lifecycles with full audit history.

I agree that semantics plague human communications, but we won't solve that problem. You have a specific definition of Service Oriented Architecture that is not universal as you yourself point out in your attacks on various standards.

We don't use SOAP or WSDL, we are not message based. We use declarative protocols, which are Resources, to choreograph fetch/transformation of other Resources to perform a business function. If you want to include us under some 'big tent' definition of Service Orientation, that's fine - I don't seek gratuitous argument.

I do feel that both SOA and REST as conventionally defined have an issue with 'shared understanding', that's what we sought to address. I expand on this in my response to a related Steve Jones post - bit.ly/mUjKTq.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

>> We can agree to disagree, agreeablyI am not quite sure we disagree much.

>> You have a specific definition of Service Oriented Architecture that is not universal It is fairly universal ... in infrastructure products, it is called SCA. Most of the people in our industry don't care to look, even though they might use it every day under the cover...

>> We don't use SOAP or WSDL, we are not message basedwell, if you are "communicating" you are message based... there are not many other ways to communicate between systems. You can layer higher semantics on top of messages, but you are message based, just open a socket if you are not convinced. The whole, an only, question at stake is what is the necessary and sufficient semantic layer on top of messages. Is one enough? or do we need more than one?

>> as conventionally defined have an issue with 'shared understanding'Have you ever tried to communicate with someone that didn't have any "shared understanding" with you?

So we agree, Data IS-THE problem, Data IS relational and that relationality breaks every possible encapsulation mechanisms, there is simply PUT, no way around it, be it object, services, functions, ... Data is a big ball of mud, that you can and need to shape each time you use some of it, yet it always remains a ball of mud.

There are many valid ways to deal with that relationality problem, you found one, great! The "uniform interface" is the least desirable way to deal with that problem. It is actually not even dealing with it, it is pushing the problem to all the developers pretending that 4 HTTP verbs are enough to replace SQL. What a fallacy, how can our industry fall for that?

Here is another valid one, that is quite simple, which has been overlooked since it's inception: it is based on forward compatibility of services. It also work beyond data for bi-directional action oriented protocols.

In the end we will never make real progress at the communication level as long as the programming model will remain where it is, progress means changing the programming model, it seems that you are also exploring that way since you introduced the concept of lifecycles. SCA has solved both elegantly with an incredible surgical precision (without displacing existing technologies).

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Nothing against SCA. SCA is glue code for composite applications, a suite of specifications.

The motivation behind SCA is to help support composite app assembly in increasingly complex Service Oriented Architectures, which is great. Service Orientation, as we seem to agree, obviously needed some help with data and assembly (Data Services and SCA are the evidence).

It's quite far from even a 'fairly universal' adopted standard. Given struggles with achieving originally marketed SOA benefits (re-use, discovery, etc.), I imagine SCA itself will have a long adoption curve. That being said, it is a completely sensible movement. Given it separates implementation from service we could readily work within the specifications - I don't see this as competitive.

SCA depends on 3rd party components for execution. Processes are orchestrated through BPMN/BPEL or choreographed through CDEL. We can execute process natively.

SCA would manage virtualization and MDM through other middleware components - we perform both natively.

SCA doesn't perform integrations itself, we do so natively (real-time and scheduled).

SCA doesn't yet support event processing (though I understand it will), we do so natively.

While SCA models security, transaction and reliability as policies - we take that further and model all logic (business rules, governance policies, transaction controls, security, etc.) as policies.

We were motivated not by technical desire to prop up REST or SOA, but rather a business goal to, as our slogan says, "Put Work in Context". Since context is relative and temporal, this dictated a dynamic protocol based system in which generalized protocols of interaction would be contextualized by in-band and out-of-band context. A fully dynamic system in which EVERY interaction is an event. Neither REST nor SOA stand up well to this test from a practical perspective. We chose Resource Orientation for practical not dogmatic reasons; it is best suited for a holistic Information Oriented Architecture.

You said 4 HTTP verbs not being enough, I agree that's why I described our dynamically configurable protocols. We are internally consistent and intentional in our use of GET, PUT, POST, DELETE, but we use them as a standard transport - the semantic is product of the interaction and the protocol (it's not just shared, it's co-created). In this way we achieve the 'functional' web, without limitations of a functional model.

The bottom line is a practical, lightweight, scalable and highly expressive app framework well suited for increasingly dynamic business environments - more for less.

If you think we'd benefit for SCA or SCA would benefit from us, let's catch up offline.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Data IS-THE problem, Data IS relational and that relationality breaks every possible encapsulation mechanisms, there is simply PUT, no way around it, be it object, services, functions, ... Data is a big ball of mud, that you can and need to shape each time you use some of it, yet it always remains a ball of mud.

So true.

To put this into perspective, a typical large enterprise has in the order of 5000 major interlinked entities/classes and 25000 attributes (10 year old data).

"Silver bullets" to tackle the data problem have included RDMBS, COM, CORBA, EJB, XML, SOA, and REST - to name just the major ones.

IHMO the next silver bullet is semantic technologies (RDF, OWL, etc.) – if this fails we will just have to resort to voodoo. For now at least, semantic technologies have the right theoretical underpinnings to slay the data Hydra.

Firstly, RDF/OWL treats data and metadata as graphs. And in computer science graphs are the most generalized structures that can represent anything. Most processing can be defined as combinations of different types of well-understood graph traversals.

Secondly, the graphs can be linked together over the network more seamlessly than any other data structure. We can have a well-defined way of managing distributed graphs.

Thirdly, with triple stores, graph databases and different serialization formats, we can represent graphs uniformly across different mediums - in-memory, disk, over-the–wire, etc.

Now many structures have graph-like properties (e.g. relational structures, objects, etc.) but my point is that we ought to go a step further and makes graphs a first class citizen. Don’t brush graphs under the rug – embrace them. To be sure that cognitive and computational burden will increase but that is a price to pay for the value we will receive.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Faisal,

thanks, yes it looks like a lot of people don't seem to realize that level of complexity and keep throwing their "wisdom" at us anyways and tell us that a uniform interface of only 4 little verbs can tame this complexity.

I agree with you that the solution has to be in the semantics space where consumers and providers are able to understand and self-configure each other at that level.

Yes, I think it has been proven that the "hyper-graph data model" can be mapped to/from all the other data models (OO, relationsl, hierarchical...)

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Dave:

my estimate is that 80/90% middleware runs on SCA but nobody knows. IBM, Oracle and Tibco all have refactored their architecture to run it on SCA.

SCA is FOSS ... you can download your SCA platform on Apache.

I don't doubt that you provide value and have an interesting solution, but please let's drop the silver bullet attitude, we all know that there is none, and it is all a matter of context, you choose the solution to solve the problem, not the other way around, you don't start with a solution and apply it to any kinds of problems. That is what is wrong at the end of the day.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

JJ - I appreciate your last attempt at balance, but I need to respond on several fronts.

I never said we were a silver bullet to every problem, you did!

I did not attack SCA, I even said we could adopt SCA fairly readily if it made sense for us from a standards perspective.

I provided specific points how we differentiate (you didn't dispute any of them). Note: My points are valid whether SCA is FOSS or not.

How many businesses (non-software vendors) build applications in SCA... answer very, very few (this is fact, not attack). So, as you say, 'let's drop the silver bullet attitude'. You are looking for a fight where none exists.

My points re: SOA and REST were reasoned, not argumentative - and you agreed with them or made like/similar points, as did others.

My comments have been topical - is REST successful in the Enterprise, answer, it has its successes, but is not central to the Enterprise operations. Steve Jones comments highlighted the lack of functional capability. We remedy that with our Resource-Oriented approach - read/write/execute web.

You have a lot to offer. Misdirection and attacks do little for your arguments.

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

Faisal - Agreed, no silver bullets. For the record, we are based on a graph model. We use our RESTful calls (HTTP as standard transport) to our Protocols (themselves Resources) to trim the graph using in-band and out-of-band context at run-time.

REST vs SOAP

Your message is awaiting moderation. Thank you for participating in the discussion.

Just my 2 cents:

SOAP is cool, the only real problems I had with it is the hidden dependencies in the headers/intermediaries due to WS-* complexity among different stacks on both ends of the call. And: passing references to other services is not easy (requires WS-Addressing complexity). The advantage is that you have simple client code and interfaces.

REST is cool too, but the problem there is that you get links to navigate so you need a hypermedia model/contract and you need to do more 'plumbing' to consume a service. Plus, pub/sub and eventing is not as easy as I would like it to be.

Bottom line is:

For across domains, REST is probably worth the overhead because it offers more loose coupling. "What you see is what you get":-)

Inside one domain, SOAP offers the simple programming model you probably want. And a platform like SCA can take care of the hidden dependencies for you so you don't have to bother.

Strategically - IMHO - the cloud platform (enabled by SCA and remoting like SOAP) will offer the programmer-friendly API/DI model that people find easy to develop in. I expect to see a resurrection of SOAP in the cloud.

Then again, for all things that follow a hypermedia approach, loosely coupled, and where the ability to express references to services is important: here REST will prevail. It seems logical to me, no?

Re: Not SOA or REST, but Resource-Orientation

Your message is awaiting moderation. Thank you for participating in the discussion.

@Dave:

>> (you didn't dispute any of them)this is quite slizzy, how can I even try to dispute them when I don't know your product. If you want to talk about that topic, publish an article, then we can talk. I don't have time to explore your product and then make an informed opinion about what you said, so why would I even engage in this kind of discussion.

>> You are looking for a fight where none exists.I really don't understand what -you- are looking for. Everyone has opinions and experiences. My general recommendation for "connected information systems" is SCA, from everything I looked at, this is the best paradigm I know, it does not mean this is the best paradigm ever. I don't think this would qualify as "fighting". Now I don't know your product, and from your attitude, there is really no chance that I will ever take a look at it.

I would appreciate if you don't try to make me imply what I didn't say -in no way shape or form, people know me enough to know that I am not afraid to say what I want to say and I don't need "hints", I am usually "blunt". I don't find your approach very professional, that's not the first time...