Skip to Content

As the echo of #SAPPHIRENOW resonates through the ecosystem people keep talking about the new trinity of on-device, on-demand and in-memory computing. Personally I feel it may be about time to re-cap on the technology that has brought us here in the first place and then move to the here and now. Why’s that? Well, to paraphrase one of my favorite artists:

You know where it ends? Well,it usually depends on where you start!

We’ve came from Enterprise Application Integration (EAI) to Message-Oriented-Middleware (MOM) on to Enterprise Services Buses (ESB) and the Business Process Platform. Yet, the underlying idea has always been the same – to get better access to all the data and functionality residing within and outside of corporate networks. Easy access to all the data AND tools to analyze this data in order to make smart decisions is vital for any business.

This is what ultimately led enterprises to think about the concept of a Service-Oriented Architecture (SOA) – the idea of having a central repository of all available services in order to make the most out of all the data flourishing in one’s landscape. The idea of having a pool of re-usable services that would allow for developing better tools to gain more insight: on details as well as on the big picture. The idea of fully leveraging the potential of one’s system landscape..

Did SOA deliver on its Promise?

Critics may argue that SOA has just been yet another hype. And I tend to agree… yes, we witnessed the typical hype cycle as according to Gartner, I guess. Yet, I have been among the early pioneers of the SOA movement at SAP and bringing it to life at customers’ sites has turned me into a believer … and evangelist (so just that you know where I’m coming from.)

Personally I would argue that SOA has matured… and I mean that in a good way, the non-KOD way. So, as the rest of the IT world may have moved on to other topics it may lead people to believe that this lack of attention proofs that SOA is dead:

It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary.

Interestingly, Anne’s blog post is still relevant and up to the point even after two and a half years after publishing – especially if seen from a SAP-centric perspective. For too long people have been reducing the idea of SOA to the most prominent implementation pattern leveraging WS* standards only:

But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.

Last year at TechEd, Volker Stiehl and I were Loose-coupling and strong bonding @ TechEd 2010 on how-to map SOA principles into architecture blueprints for SAP-dominated landscapes. Picking up on the “SOA is dead” theme we summarized what we call “Sustainable Architectures for SOA” in a SAP TechEd live interview with Mark Finnern. In a nutshell, SOA is far from being dead, the opposite – the need for services is as prominent as it ever was.

In the meanwhile – elsewhere

Switching scenes to the here and now, SOA is hardly talked about anymore: on-deviceon-demand and in-memory computing is where it’s at. But is that a new theme?

We (meaning SAP) may not be as verbose as we used to be in regards to SOA, but if I break down the new dimensions it all looks so very familiar. It’s all about the need to access data provided by services and being able to access these services:

  • everywhere (on-device)
  • anytime (on-demand)
  • and faster than ever before (in-memory computing)

So, for bystanders it may sound as if SOA is not worth being talked about anymore. One may get the impression that the new kid on the block – project Gateway – will be the long-awaited hero that finally tears down the wall and liberate all the functionality residing in the SAP fortress … (well or at least provide a gateway to allow for flowing traffic.)

In Technical Terms

And yes, at first glance the public discourses about whether or not REST is superior to the commonly found WS*-Standards approach may have added to the false impression that project Gateway is (intended to be) the successor of SAP Enterprise Services and SOA. Based on the motivation to shed some light on this rather controversial technical discussion the SAP Mentors organized a webinar entitled “SAP Mentor Monday: “REST and Enterprise Services Demystified”.” Unfortunately, the audio signal was lost and as such this very info-taining webinar is of limited use as a reference.

In my own words, the essence of the conversation was about the technical differences between REST and the WS*-Standards-based approach. The light-weight character of  RESTful services was compared to the more complex architecture of Enterprise Services. We then got to speak about that additional overhead complexity introduced by the Web Service Standards and why Enterprise Services have been designed as complex as they are.

Let’s stop here for a moment as I feel it’s important for the discussion onwards. In such conversations people arguing in favor of REST may talk about the overhead of the WS* protocols. Well, overhead is not an absolute term, but a relative one. You can be pretty sure that this overhead clearly serves a purpose and that it hasn’t been introduced without reason. Maybe this aspect helps in finding the answer to the question: “What should I use: REST or Enterprise Services?

The answer is a classic: “It depends…

At a closer look it gets obvious that the two approaches do no compete against each other, yet they address complementing use cases. While the more complex Enterprise Services have been primarily designed for A2A and B2B communication scenarios, the light-weight character of RESTful services makes them ideally suited for instant-value apps and simple consumption scenarios. As such, a lot of the complexity we see in former may be negligible to some degree in simple(r) consumption scenarios as they do not intend to be used in distributed, cross-system transactions. I could put it anyway I want, at the end, it would still end up being second best compared to the excellent summary that Dick Hirsch wrote about this very topic: “The specified item was not found.

The Story continues…

Just two days after the SAP Mentors webinar I stumbled across an interesting Tweet of Kaj van de Loo in which he mentioned giving a keynote on SOA at the International Conference on Service Oriented Computing (#icsocsf) and I asked him if there would be a recording available. Unfortunately there wasn’t, yet he offered to present the session as a SAP Mentor Monday webinar. For those who haven’t heard about Kaj: he has earned quite a reputation for being able to explain SAP’s technology strategy in a very comprehensible way as well as for being a very open and honest communicator. As such, the SAP Mentor wolf-pack was eagerly looking forward to his session…

SOA Meets Reality with Kaj van de Loo

In his presentation Kaj summarized the lessons learned in 10 years of SOA in just 30 minutes, followed by another half an hour of Q&A. He started by explaining SAP’s approach of evaluating these new technologies (such as WSDL and SOAP) considering the responsibilities coming along with being the world leader in enterprise software. Knowing that 85% of the Fortunate 500 companies are running SAP software makes you aware of all the long-tail considerations that need to be considered when establishing such a concept as fundamental as SOA.

He continued by elaborating on SAP’s systematic approach of developing the platform first before rolling it out internally (SAP Business Suite) and then externally (customers) and about how customer adoption steadily increases since 2006. Towards the end, he addressed the status-quo (the good and the less good) and concluded with an outlook on what he coined as “SOA 2.0” (~ 28:30 min). I strongly encourage everybody interested in the topic to watch the session.

SOA 2.0

So, a few minutes ago we argued that SOA is dead and now we start talking about SOA 2.0? How did that happen? Well, when confronted with the question on why SAP keeps talking about SOA (while the rest of the world seems to have abandoned the term) Kaj replied: “It’s intellectual honesty.” (~ 37:50 min)

Sure, there may have been inflated expectations that (enterprise) SOA did fail to deliver on (yet) such as “Deployment Flexibility and increased User Productivity,” as Kaj pointed out (~ 27:00 min).

So instead of abandoning the term we opt for evolving SOA or better to re-focus on the most fundamental idea of SOA:

[def.] SOA: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

[OASIS definition of SOA]

Taking the lessons learned from 10 years of SOA and pair them up with all the new capabilities provided by the three new dimensions does indeed sound very promising to me.

The idea is to enhance the current SOA experience by adding the capabilities that project Gateway brings to the table in regards to opening up the IT landscape by providing simple(r) access to the underlying data.

Lowering the entry barrier to developing applications for SAP backend systems sounds like a good step to attract more developers. If matched by equally appealing licensing models there is little reason why developers should not consider it as a target platform. More developers means more apps, more apps  means more users. (And as you all know, we are thriving for one billion…so, the more, the merrier!)

Outlook

So, with that I want to slowly wrap it up and call it done for today. Well, maybe one more thing… towards the end of the Q&A part of Kaj’s session we briefly scratched the topic of business events. After the webinar I reached out to Kaj with some follow-up questions that may also be of broader interest, yet we’ll keep that for another blog post. Stay tuned…

 
[Ed. note] I do know that we barely scratched the surface of the topic so far with this post. Yet, the intention was to recap on the past and to take a look ahead before we continue with further explorations. Setting a basecamp if you will… or as the members of the “Atlantis” society may call it: a beacon! So, what do you think – anyone interested in further deep dives?

 

PS: Special thanks to Kaj van de Loo, Matt Harding and Alisdair Templeton for taking the time to review this post. Very much appreciated!

To report this post you need to login first.

35 Comments

You must be Logged on to comment or reply to a post.

  1. Gregory Misiorek
    Hi Matthias,

    if this was scratching the surface..then i want to do more scratching. i like the differentiation between consumption and integration or quick and short term vs durable and long-term solutions. many times, independent developers are tasked with coming up with durable solutions that need to be delivered quickly, so any tools (Gateway?) to get them there go a long way to keep them attracted and dedicated.

    OT, did i get this straight? the current assignments are:
    1. on-demand -> ByD,
    2. on-device -> SUP,
    3. in-memory -> HANA

    rgds,

    @greg_not_so

    (0) 
    1. Miloslav Mil
      OT, yes, you did.
      ByD, SUP, HANA are applications of technology in form of application suite, platform, memory to achive old goal to access critical information from anywhere and anytime nowadays with accent to deliver agilely, rapidly, instantly and with model pay-as-you go…

      Best rgds

      (0) 
    2. Matthias Steiner Post author
      Hi Greg,

      well, as you just demonstrated there are plenty of good follow-up questions, hence “just scratching the surface” 😉

      I assume that OT stands for “on theory”, right?

      In principal, as a rough guideline your mapping is correct, but there’s more to it for sure:

      1) on-demand: ByD is the most prominent example for sure. But then there are also LoB solutions like the Sales onDemand app. We should also not forget about project River, StreamWork and so on…

      2) on-device: sure, the unwired platform is a center piece. Add Afaria for device management. And then there’s that entire UX topic (HTML5, Web 2.0) partly driven by the native vs web-app domain. Gateway as an enabler of consumption is also in that “dimension”.

      3) in-memory: HANA. Well, again… HANA is just the beginning. Next to the appliance we will see tons of apps build on top and especially for the in-memory database. The entire BI tools should also be mentioned in the same sentence to give them justice…

      If you got 15 minutes I’d highly recommend to watch Kaj’ sessions about Technology Strategy at SAP Part 1 and 2, where he explains all that.

      Thanks for tuning in Greg!

      Cheers,
      Matthias

      (0) 
  2. Sascha Wenninger
    Hi Matthias,

    please keep it coming! If I understood you correctly, you’re implying (among other things) that one of the reasons nobody really talks about SOA anymore is that everyone’s now doing service-orientation much more naturally and it’s just not so “special” anymore…

    Many other good things to consider, and I’m sure you have plenty more to write about in a deep-dive!

    Thank you for sharing!

    Sascha

    (0) 
    1. Matthias Steiner Post author
      Hi Sascha,

      yeap, I’d back up that statement. I think there are several reasons why people have stopped using the term:

      – some may feel it has a bad taste to it
      – some may say it can mean anything and nothing
      – and, as you stated… yes. I’d say it trickled through the enterprises in the meanwhile – hence I said it matured.

      Thanks for showing your interest in the topic!

      Cheers,
      Matthias

      (0) 
    2. Miloslav Mil
      Hi,
      Nowadays SOA as the term is not sexy for businesses, maximally only for business technologists.

      Also according to my experience, it’s true to don’t call it SOA, but do SOA…

      Mila

      (0) 
  3. Matthew Harding
    Nice work Matthias, and thanks for the mention even though you didn’t have to do that (happy to help when it comes to good discussion pieces).
    The main point I would make (I’ll wait for more of a deep-dive to provide more input/feedback) is that I constantly find that when you come from a custom development background; many of the concepts that have a name, are what you’ve been doing for years (albeit to varying degrees and different techniques).  It’s just the technology improves (ESB’s, Gateway, etc) or maybe you get a more open or consistent standard (web services standards) and can move away from more locked down integration approaches like DCOM Connector (1998) or Business Connector (2001) style integrations. Maybe the solution requirements change, and you suddenly have a requirement for this new Web Dynpro for JAVA technology to require a good way to lightly interact with your back-end system while making sure you’re not defining a new interface every single interface (welcome back RFC back in ECC 5 in 2004).
    I think the Utopia is getting closer (though it may possibly never be Tom Cruise dragging Gateway resources/services over an iOS or Android interface together with his Minority Report style Wii hands) but for now, we still need more people to embrace best practices or at least not do stupid things for the sake of a project timeline.  For example, it’s really stupid to create an expensive to support interface (as all interfaces usually are when you throw in security, audit ability, upgrades, etc), without thinking – could this be tweaked to make it more usable and if I did this could it be leveraged elsewhere.  Or alternatively, not think, how coupled do I want this system to be to the implementation of this integration.  Or ask a 3rd party system to develop an interface to call your ABAP system with this iDOC format.  In fact, maybe this is what SOA 2.0 needs – a list of ever expanding obvious questions to ask yourself whenever you need interfacing or cross system business process orchestration/management. 
    Being pragmatic should be the job of an architect, and no single term should dictate how you do things; but you should know enough to do your job and have the essence of SOA knowledge in your kit bag.
    In regards to this last statement, I’ve coined the obvious term the “Development Architect” (probably not – but I never hear anyone else use it).  The point here is that regardless of how obvious these concepts are; there are people who know custom development including integration, workflow, UI, etc; and these are the types of people that will get your SOA strategy right and they may not even call it SOA (I still do though)! The problem with SOA – we need more of these people. 
    Anyway, it’s late here, I’m rambling and not really getting my point across but I just wanted to comment to say you’ve done another great and readable blog and add my 2 cents.
    Cheers,
    Matt
    (0) 
    1. Matthias Steiner Post author
      Hi Matt,

      it’s very re-assuring to hear your words as I find myself on similar grounds.

      A pragmatic approach to SOA. Word!

      As everything in the enterprise space SOA needs to be taken with a grain of salt and a healthy dose of reality. Or as I always say: you need to know the rules to know when you face the exception.

      I agree a 110% that we need more development architects in this sense (well, as that is my official title I guess I’m somewaht biased).

      It goes hand-in-hand with the downhill developer debate amongst the egheads. Lowering the entry barrier via simple REST interfaces may also result in a a lot of sub-par apps as we see them in the consumer app stores…

      Experience is hard to replace and as such I draw my “sustainability” joker when it comes to tightly-coupled hacks. “You get what you pay for – why not just get it right at the first time and be over with it?”

      Looking forward of pulling together that SOA piece with you Matt!

      Cheers,
      Matthias

      (0) 
  4. Alisdair Templeton
    Hi Matthias.

    I echo Matt’s comments – Great Blog! (and I too appreciate the mention).

    IMHO I believe that REST will compete directly for a piece of the A2A and B2B space usually reserved for the WS-*/ESB approach. That said, SOA as a concept will still be needed to define the functionality that is exposed to support business needs. 

    There has been a lot of discussion on REST vs WS-*, especially around Reliable Messaging/Idempotent Services and Transactions. Personally I feel comfortable that these requirements can be met using a RESTful approach – the details of which are probably best saved to be discussed over several beers at Tech Ed!! 😉

    As someone said “My Internet is bigger than your Enterprise”.

    There is also some discussion on the web on RESTful SOA. My initial impression is that this is an attempt to make services look like resources by using adapters and anti-corruption layers. More like Frankenstein’s monster…but I could be wrong (it has happened before 🙂 )

    In case you hadn’t seen it, there is a good article on InfoQ on the state of SOA in 2011. I particularly like Jim Webbers view of the world…

    http://www.infoq.com/articles/soa-2011-panel

    AT

    (0) 
    1. Matthias Steiner Post author
      Hm, a double AT post… does that make you AT-AT now? If so, dang – I didn’t bring my lightsaber to work today! 🙂

      Back to more serious terms… I am really looking forward to taking this a little further with Matt, you and whoever else feels joining in. I see lots of learnings in such discussions…

      And you certainly have a point, the internets are bigger than an enterprise and as such REST will be a very common connectivity pattern to speak to the outside world (coming from an neterprise perspective.) Yet, those lines are more and more diminishing and with Gateway REST will become 1 1st class citizen at SAP.

      I’m so looking forward to our talks at TechEd – and I’ll bring a few surprises – you’ll sure gonna like!

      The Panel was interesting for sure – I love the quote about Guerilla SOA: “Think about SOA not as a protracted effort, but as a series of short winnable skirmishes that happen as change is driven through your market or organization.”
      Soo true!

      Cheers,
      Matthias

      (0) 
      1. Sascha Wenninger
        At the risk of throwing another old tire onto the fire…:

        “SOAP is Not Dead – It’s Undead, a Zombie in the Enterprise.” – http://pulsene.ws/1K4ps

        Maybe I’m sort of sitting on the fence here… I do think SOAP has its place as a largely fire-and-forget messaging mechanism and places far fewer demands of intelligence and robustness on the consuming systems than REST because locked-down contracts protect each of the parties from recklessness or stupidity.

        On the web, you don’t have these restrictions and can thus relay far less on ‘good behaviour’, which in turn requires Postel’s Law to be adhered to much more strongly by all parties… Martin Fowler recently tweeted some stuff on the “Tolerant Reader” and “Magnanimous Writer” patterns which resonated quite strongly with me and in my mind fits better into the RESTful sphere than into the SOAP world and contracts, schema validations and so forth…

        Echoing Matthias, as systems become more open (dare I say ‘cloud-based’ here), the lines will blur ever more. To me, this makes the strictures of SOAP ever less reliable and more and more brittle, which in turn makes REST ever more attractive…

        However, to me SOAP != SOA; depending on how you look at it, the distinction between a service and certain kinds of resources can be quite fuzzy, especially once you go beyond resources which directly map to your entity/data model and are more abstracted (e.g. a report, music charts, etc). If the ultimate aim is to expose application functionality via widely-understood interfaces, then surely that’s A Good Thing.

        We can always continue this in Vegas 🙂

        Sascha

        (0) 
        1. Matthias Steiner Post author
          Hi Sascha,

          Wow, some very interesting links here Sascha – thanks for sharing!

          Enjoyed reading through that little dilemma you illustrated in your respond – can so relate. 😉

          I’m pretty sure that we’ll see both SOAP and REST being used along side in the enterprise. Especially in on-demand scenarios and next generation apps.

          Would be great to continue prior and during TechEd in Vegas. (Cannot  commit yet, but chances are good on my side.)

          (0) 
  5. Alisdair Templeton
    Hi Matthias.

    As Matt said, Great Blog! And I too appreciate the mention.

    IMHO not only will REST find its way into the Enterprise for UI centric applications, it will also compete for the A2A and B2B scenarios which are usually the domain of the WS-*/ESB approach. That said, SOA as a concept will stay, guiding the Enterprise on what pieces of functionality to encapsulate and expose as autonomous services/process components, regardless of whether they are accessed RESTfully or via WS-*. The conceptual part is important – it gets the foundations right.

    A lot of the discussion on REST vs WS-* is based on Reliable Messaging/Idempotent Services and Transactions. Personally I’m convinced that REST can meet these requirements…but will reserve the details for a conversation over many beers at Tech Ed 😉

    As someone said “My Internet is bigger than your Enterprise”

    If you haven’t seen it there is a good discussion over at InfoQ on SOA in 2011. Personally I like Jim Webbers view of the world…

    http://www.infoq.com/articles/soa-2011-panel

    AT

    (0) 
  6. Jonathan Wilson
    Hi Matthias,

    Thanks for putting together a really thought provoking blog.  The background on SOA development at SAP is really interesting, and sets the scene well for the next generation of services and events. 

    To my mind the name “SOA” is not important (although I personally agree with Kaj’s stance on this) but what is important are the standards that allow the interoperability of different systems and platforms.  We have moved a long way from proprietary protocols (even if they are still with us), and it is the standards (HTTP, XML, SOAP, WS-*, JSON, etc) which were and are the enablers of this change.

    Whether you prefer REST or WS-* isn’t the issue, what is key are the business issues you are trying to solve and the standards that you can leverage to add stability, longevity and reusability to your solution.  However, with options comes choice, and choosing the right standards is now a key aspect of any integration project.

    Technical flexibility is one thing, but we also need standards to evolve beyond pure technical enablement, to encompass business enablement.  Perhaps business events are taking us in that direction – I hope so.

    Really looking forward to a continued discussion on this.

    Cheers,
    Jon

    (0) 
    1. Matthias Steiner Post author
      Thanks Jon for stepping by. Glad to hear you liked the blog post.

      Your right about “with options comes choice”… I think that enterprise architecture knowledge will remain a vital skill 🙂 (good news for all the developers!)

      Looking forward to our future discussion!

      (0) 
  7. Jan Penninkhof
    Thanks for the excellent blog Matthias. I completely agree with the fact that SOA is now mature and definitely not dead. Many organisations have take it as a new realm and demand new applications to be developed according to their x-layer model, that usually comprises a message bus or other SOA related tools. Usually the web-services built in these x-tier development projects are eventually stored in the ESR or at least documented somewhere.

    After reading your blog that mentioned Gateway, I realised that development processes that include usage of Gateway may look fundamentally different. Although you could mark the REST services as enterprise services as well, they can’t be used on a servics bus and can’t be included in the ESR.

    Although I do like to light-weight characteristics of REST, I somehow have the feeling that this makes REST a SOA 1.0 protocol rather than an evolvement.

    I would be very interested in your opinion about this.

    (0) 
    1. Matthias Steiner Post author
      Hi Jan,

      lot’s of good points indeed.

      I guess that now would be a good time to refer to the standard disclaimer that all my blog posts are my own thoughts and not any official communication by SAP! So, please consider that when reading further…

      Personally I can relate to your thoughts. As far as I can tell Gateway is primarily designed to cater to light-weight consumption patterns (mobile devices etc. )

      In other words, one may regard it as part of the UI/UX layer intended to reach broader adoption and massive consumption.

      One thing people wanted to avoid with Gateway is all the governance overhead typically required (in a healthy dose) for SOA and to have something in addition that provides more simple/light-weight consumption.

      Especially people who love REST do so for its simpleness. OData adds to that. SAP Data goes on top. Purists may be concerned we are already strechting it again…

      So, how does Gateway and other SOA components as as an ESB, ESR, Service Registry and CE fit into the picture?

      Good call!

      I think here we are just seeing the tip of the iceberg.

      As you mentioned n-tier architectures. To fully leverage HANA we would also put some of the heavily lifting and procesisng closer to the the database. As such, we loose db abstraction. I have been thinking about architecture blueprints that would allow to treat functions residing in HANA as an optional capability by allowing for a graceful fallback based on functions residing in the connectivity layer.

      But again, we are at the beginning…

      Coming back to Gateway and REST-based services.

      From my perspective it looks as these technologies are means to address the “last mile” so to speak. Something I’d associate more with UI binding than for B2B and A2A communication patterns. I know others thing differently though.

      Throughout my career I’ve always tried to keep the UX layer thin in an attempt for clean seperations of concerns. Yet, the dilema was always the navigational state and where to keep it. Here REST, OData and SAP Data protocol seem a good fit.

      Now, I know that several brilliant minds in our community see REST-based services in a different way and see them in the same space as WS* (SOAP)-based services. I’m yet to be convinced and I’m looking forward to continuing these discussions 🙂

      So, based on that … SOA only makes sense if there is a central repository for the services available for integration and composition scenarios. So, the question will be if REST-based services will conquer that space I think.

      I’m planning to continue with such architecture discussions in SOA projects and for those interested please join in/me at TechEd!

      Cheers,
      Matthias

      (0) 
      1. Jan Penninkhof
        Hi Matthias,

        I totally agree with the “It depends” to the question on when to apply which technology.

        It depends:
        – It doesn’t make sense to send a message of a few gigabytes to a http-server. Web-servers aren’t made with that in mind, and will probably cough your message out after some time-out timer triggers. SOAP would be the better contender here, especially if that message if supposed to be consumed by multiple target systems.
        – Quick, flashy, low-bandwidth, low-cpu mobile user-interfaces? No doubt, REST would work much better.

        In fact after reading your reply, I realized that I want both SOAP and REST in my toolkit as two coexisting technologies, each with its own strengths and weaknesses.

        Perhaps the combination of the two can be called SOA 2.0 😉

        Cheers,
        Jan

        (0) 
  8. Jens Steckhan
    I heard a very interesting heise developer podcast on architecture in general and REST in particular.

    They maintain that SOA doesn’t use the full potential of the HTTP protocol. This makes it difficult to make use of its advantages – e.g. in order to cache results, you would need to introduce additional parameters in your SOA call rather than use natural caching options of your existing HTTP infrastructure.

    Rather than a plethora of SOA interfaces with plenty of parameters they favour a toolbox of simple rest-based services.

    Their point is that REST based services are the natural successor of SOA. Since large companies such as SAP have heavily invested in SOA, it would take a little longer for them to make the transition though.

    I would be curious to hear your opinion on this 🙂

    (0) 
    1. Jan Penninkhof
      Hi Jens,

      Maybe just a little comment from my side, I hope you don’t mind.

      SOAP was not set-up to be bound to HTTP, but is able to just use HTTP as a transport media. It is also possible to e.g. use SMTP of even FTP. To be transport-layer agnostic it wouldn’t be a very good idea to incorporate features of a specific transport-layer in the SOAP protocol.

      Actually in your message your implicitely hitting another point about REST vs. SOAP. If you’re using REST, you’re limited to using HTTP only, while SOAP supports  a bunch of other transport-layers as well. Would a successor allow you to use less transport-layers?

      Cheers,
      Jan

      (0) 
      1. Jens Steckhan
        Hi Jan,

        I don’t mind your comment at all – in fact I highly welcome it because it allows me to clarify my point 🙂

        This is exactly what it comes down to: is protocol agnosticism a strength or a weakness?

        agnosticism PROS: you are free to chose your protocol. And yes, theoretically, you could run SOAP on FTP.

        agnosticism CONS: you cannot use any advantages of the underlying protocol, you will have to add any functionality that you need in your own abstraction which ads overhead. Plus you cannot take any advantage of any infrastructure that is geared towards a specific underlying protocol.

        I find the advantage of running SOAP over FTP rather theoretical. However, we have a very strong and real HTTP-based global infrastructure around the world. 

        Let me pick up the cache example once more: suppose you want to retrieve a simple, cachable information. In REST, you would use a GET, which would be cached on a highly optimized webserver level. Do the same with SOAP: for the webserver this would be a HTTP POST, it could not cache and you would use a load of overhead.

        I know well that SOA is protocol agnostic. But given today’s infrastructures, I see it as a disadvantage.

        Best regards
        Jens

        (0) 
        1. Jonathan Wilson
          Hi Jens,

          I don’t believe that being agnostic means you can never use the features of the underlying protocol, it just means you have to be more careful about the way in which you do it, to ensure that you don’t prevent alternative implementations.

          While earlier versions of the SOAP specification only supported the POST method, the SOAP 1.2 specification supports the use of HTTP GET in response patterns for exactly the caching example you describe.

          The SOAP 1.2 specification also says that “Other specifications in future could define SOAP bindings to HTTP or other transports that make use of the other Web methods (i.e., PUT, DELETE)”, so perhaps a specification that makes SOAP more RESTful (or REST more SOAPy?) isn’t an impossibility in the future .

          Cheers,
          Jon

          (0) 
          1. Jens Steckhan
            Hi,

            good point, SOAP is learning and with 1.2 you could cache in theory and with good luck even in practice.

            However I still don’t see the advantage of protocol agnosticism. In my eyes the HTTP infrastructure is overwhelmingly dominant; REST uses its advantages elegantly in a light-weight fashion. Why add overhead?

            Is the case for SOAP over SMTP or FTP really that pressing?

            Cheers
            Jens

            (0) 
            1. Jan Penninkhof
              Hi Jens,

              There are indeed many HTTP-servers in the world. In many cases these HTTP-servers will be able to do the job perfectly, but in others they are not the ideal.

              Most web-servers haven’t been built to process large messages (e.g. incoming product catalog, batch of orders etc) or 1000s of messages simultaneously. Another area where web-servers are lacking is when connections need to be kept open. Although there are technologies such as Comet or long-polling, they’re far from perfect, while SOAP works perfectly in combination with e.g. XMPP or sockets.

              These are just example I could think of, there are probably more reasons why another protocol than http might be preferred in certain situations.

              Cheers,
              Jan

              (0) 
              1. Jens Steckhan
                Hi Jan,

                I wouldn’t go so far as to claim that REST is the silver bullet and SOA has no reason of existence. Nor would I maintain that we should always rely on HTTP for every problem or that every HTTP server were highly performant.

                Thank you for your strong examples – they prove that there are cases where a SOA approach would be superior (or REST simply not feasible).

                Yet my gut feeling is that in a very high percentage of cases, these limitations are not relevant. And that is where the SOA overhead of protocol abstraction is not justified.

                So I still maintain that REST will be the better approach in the standard case.

                Best regards
                Jens

                (0) 
                1. Jan Penninkhof
                  I think every situation has its own requirements and I think the answer to the question “when to apply what” is probably “it depends”. Also have a look at my reply to Matthias reply.

                  A user-interface would probably work best when it’s based on REST, A2A messaging is probably better of with SOAP.

                  Generally, I’m just very happy that these standards are there and that we have a choice between many good implementations. Coexistence doesn’t always work very well, but I think SOAP and REST complement eachother in an excellent way.

                  Cheers,
                  Jan

                  (0) 
                  1. Matthias Steiner Post author
                    A little late to the party – sorry! Really happy to see that Jens, Jan and Jon (3Js) continuing the discussion. Yeap, SOAP is not bound to HTTP, yet as Jens said this seems to be the 80% case for sure. Don’t we (IT) always preach to go for the 80% case?

                    Then yeah… there may be use-cases for other transport layers than HTTP(S).

                    I think it just shows that it would make good sense to have some architecture blueprints for common scenarios and to intensify our discussions and collaborations to know what works for certain challenges.

                    Thanks for engaging and sharing!!!

                    (0) 
  9. Martijn Linssen
    Matthias,

    nice topic. Plenty of TLA’s, some of which you try to explain by pointing to other URLs

    I don’t know much about SAP. Or Oracle. Or Siebel. Or any other monoculture out there – I come from the exact opposite

    What is the best way to go to work? Car, train, tram, metro, bicycle, bike? Leased or privately-owned? New or secondhand?
    It’s a silly question, because the answer is “it depends”. The same goes for HTTP discussions vs SMTP, (S)FTP, Filesystem, (MS)MQ or AS1/2/3 or X400 or any other protocol out there
    Is there a best way? No of course there isn’t. Well then which should you support? The answer is easy: all those that return more money to you than it takes to sustain them

    What is the best language to speak? German because SAP is German and most code still is in German? English? Dutch then because those are really smart and cool people?
    Again, a silly question, and an identical answer. You shouldn’t speak Dutch when in Germany, or German when in the UK. Neither should you speak UK when in the south of US or AUS, because they don’t get that version of the language there. The same goes for XML discussion vs JSON, Atom, comma-delimited flat file or X12 or EDIFACT or HL7 or Swift or TRADACOMMS or any other message syntax out there
    Is there a best language? No of course there isn’t. Well then which should you support? The answer is easy: all those that return more money to you than it takes to sustain them

    REST? Meaningless when it comes to Enterprise Integration, doesn’t even cover 5-10% of all the requirements
    SOAP? Same. Once a SOAP, always a SOAP, useless from the start: badly specced, missing the necessary details, forcing everyone to make their own bilaterally-agreed-upon proprietary SOAP “standard” that wasn’t even interoperable with the app next door
    Web services? Likewise. No web service in the world is interoperable with another. Well, maybe a few then

    Now look at your own IRL. Gas – you can fill up your car anywhere. Water – you can get that from anywhere, anyhow. Electricity. All these are extremely consistent products and real standards, because everyone agreed upon them. Because they are so simple, people can PUT and GET them via any form, via any way of transportation <<== think about that really, really hard for 60 seconds please

    Standardise the products.
    Standardise your services.
    Describe them on a functionally unambiguous level, publish those in Word or PDF.
    Make them serviceable and maintainable, absolutely intelligable and interpretation-free for any techy, any functional guy or gal, and most importantly: any business man and woman on the face of this earth
    Build a business model around them so people will want to pay for them, because they make their life easier in stead of harder

    Then, make that available via XML or XSD or EDIFACT or JSON or Atom if that ROI’s for you. Kick ‘m around via SMTP, fax, email, telco’s, Skype, FedEx, Twitter, Facebook, whatever.
    Make ‘m UDDI-able and pay-per-use, sign ‘m and secure ‘m

    Nothing is fixed in this world. How many of you were XML-fans 10 years ago (when I said it was crap and absolutely unfit for application integration). How many of you were SOA fans 10 years ago (same)? ESB adepts 10 years ago (same)?
    Did any of that make even a dent? Well yes for sure, in enterprise wallets, a huge dent it made, and it filled vendor pockets, especially the likes of IBM and system integrators

    Stop fussing about the nitty-gritty stuff. Focus on what matters, what is important.
    There’s a whole world out there with tons of different kinds of SAP even, but SAP is just a tiny minority.
    There is an extreme diversity out there of transport protocols, messages, systems, all evolutionary, some will die, others will grow, some will be born or even reborn. Some fast, some slow, some with help from others, some by merit

    Stop the stupid tech OR-OR discussions (that goes for everyone in IT btw). You put gas in your tank, water in your mouth and electricity in your laptop.
    You know what happens when you swap them

    (0) 
    1. Matthias Steiner Post author
      Hi Martijn,
      thanks for that delightful comment, which I tremendously enjoyed reading. And it sure didn’t come unexpected… not at all.
      Before I take the time to reply to your comment in more detail let me explain that I spend quite some time detailing the structure of my blog post. My frequent reader would be able to tell that the entire post was resolving around a theme – in a very conversational style. It was never the intention to really get at the essence of the topic, yet to gauge interest in discussing the pros/cons of the available technologies to achieve something that people refer to as SOA, yet w/o having agreed on a common definition of the term. Sure, we could do bullshit bingo and throw TLAs at each other non-stop (hey, we even do that to amuse ourselves!)
      So, yes “it depends”… that was the essence of the post – that there’s no such thing as a one-size fits all silver bullet. Sorry to be the bearer of bad news. It takes some experience and skill to come up with a solution that fits best for any given scenario.
      Now, that is certainly not “hot news” or “a mind-blowing concept” I talk about here (hence I added the disclaimer right from the beginning). Yet, that wasn’t my intention at all… I explicitly addressed people within the eco-system that know about all the hype and fuzz there is – actually that was the whole meme of the blog 🙂
      In fact, I think you gave a good example. The best language… surely it depends on the context. But what if the question would be: “what would be the best language to get maximum reach?” AH…. I’d say English, this is why I blog in English – even as a non-native speaker.
      Now, isn’t that what we are talking about here? What’s the best language to use to communicate globally and do that in a reliable, secure, convenient, simple manner. That’s the whole point…
      I think that discussion is a valid one. Especially now, that we want to reach out to 1 billion people and want to make our platform more simple to consume.
      As such I don’t find the discussion “nitty-gritty”, nor “stupid tech OR-OR discussions.”
      I think it is vital to make all people involved aware of the fact that we should talk about what worked, what works, what could work, what didn’t work and how it should work.
      The blog was just a teaser to find people interested in driving the discussion. We can go as deep as you like. I’d be happy to do my part…. I’ll continue to blog about it (at my own pace) and engage with people on their blogs.
      In order to get more developers to build apps we need to continue our dialog on SCN and share best practices. This is what made this place what it is now – one of the biggest, most active and most successful enterprise social networks.
      PS. One more thing 🙂 -> the most important rule of enterprise IT: don’t take it too seriously, if you are getting too close – catch the daily Dilbert 😉

      Cheers,
      Matthias

      (0) 
      1. Martijn Linssen
        Matthias,

        that’s a lot of disclaimers there, but fortunately you say “What’s the best language to use to communicate globally and do that in a reliable, secure, convenient, simple manner. That’s the whole point…”

        Still, that’s the wrong question. The right question would be:
        – what are the three most-used business industry standards?
        – what are the three most-used message syntaxes?
        – what are the three most-used message encryption standards?
        – what are the three most-used transportation encryption standards?
        – what are the three most-used non-repudiation standards?
        – what are the three most-used business industry standards?

        Apply those questions to your current customers and industries. To enterprise customers but also SMB, to developers and suppliers: consider your entire ecosystem for now and in the near future – and realise that it will continually change

        Here’s how deep I have gone: http://www.martijnlinssen.com/2011/03/perfect-integration-ebook.html

        (0) 
        1. Matthias Steiner Post author
          Hi Martijn,

          don’t we all love disclaimers 🙂

          Still, as the discussion goes on and this blog post draws traffic its a necessity I have to cope with. It simply means that the views are my own, not SAPs.

          See, I’m a development architect coming from one of many departments – SAP Custom Develeopment. As the name suggests, we develop solutions based on customer requirements. As such we are kind of an ISV, well not that independant maybe, but my job is very similar to other architects working for partners or customers.

          If you would familiarize yourself with some of my work (e.g. my book and my recent Loose-coupling and strong bonding @ TechEd 2010) you’d know that you’re ringing the same bell as I do.

          Maybe we have just looking at it from two different standpoints this time around. The questions you listed are the right ones… for architects! It’s like a complex mental decision matrix derived from experiences, reading anddiscussions (etc.)

          Yet, there’s demand for a 1st level pre-filtering concept that allows to dispatch incoming customer requests to the people with the right skillset (as these are limited.) Presales needs guidance, marketing needs guidance. And execs usually don’t want to discuss all that either. That’s really where the development architects fit into the picture!

          What drives me is to come to an understanding how a modern application architcture blueprint may look like that would give me the means to quickly develop applications in a loosely-coupled fashion allowing me to replace any layer regardsless of which communication protocols or domain models etc are used by the services providers. Of course taking into consideration all (!) tools in the toolbox.

          As I said, I’ll continue doing that and currently I’m sketching out my SAP TechEd session resolving around community-centric development.

          So, I already downloaded your ebook – Perfect Integration and eventually do a review. Sure looks like an interesting read at first glance!

          Best regards,
          Matthias

          (0) 
    2. Jonathan Wilson
      Hi Matthias,

      I think it is vital to make a clear distinction between asking what is “best” in the general sense, and what is “best” for a particular customer and business requirement.

      While “best” in the general sense may be an interesting discussion, it is ultimtely likely to reach any unanimous conclusion, as there are too many factors to consider.  I think this perhaps is the essence of your comment.

      However, I believe that when discussing, “best” for a particular customer and business requirement, it is very different.  You need to understand what you’re getting yourself into, and what the potential consequences / limitations might be.  If there are options, you would generally do well to compare them first in order to reach a decision on which (none or many) make sense.

      To extend your going to work example, you wouldn’t want buy the car, and only later discover that there’s nowhere to park it, and that you have to leave it at home and go buy a train ticket.  Understanding the key differences in the options up front should hopefully lead to better decisions.

      With options comes choice, and with choice comes responsbility.  While it might not seem beneficial to all, I believe that the general discussion of the releative advantages / disadvantages of different options is useful to inform the specific cases where you actually have to make choices.

      Cheers,
      Jon

      (0) 

Leave a Reply