We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Does PaaS Inherit the Same Integration Challenges Seen in SOA, Such as .NET vs. Java?

Vote 0 Votes
Joe McKendrick: Platform as a Service (PaaS) may be dependent on adoption of vendor's middleware and protocols. Does PaaS inherit the same integration challenges seen in SOA, such as .NET vs. Java?

7 Replies

| Add a Reply
  • As with a 'standards based' SOA implementation, a 'standards based' PaaS implementation using SOAP or REST will bypass any of the integration challenges I have seen. Making data or business logic available from a PaaS implementation using SOAP or REST will mean that using the same services, applications written in .NET, JAVA, PHP, Ruby, various ESBs and other technologies can reuse those services over and over again. In my experience this is simply not possible with 'traditional' middleware stacks which insist on the installation of stubs everywhere and tie you into their particular protocol.

  • PaaS isn't a technology, just a concept

    I define like this : a PaaS application respect all conditions defined by the PaaS provider. For example google app engine is very restrictive and don't use the standard java stack.

    but I think the PaaS world is under construction

  • To quote Lori MacVittie:

    "There is almost no way to avoid cloud “lock-in� when an organization commits to integrating with the proprietary services of a PaaS (Platform as a Service) solution.


    "Such platform services are proprietary. Closed. Non-portable. They are services that, once your application is dependant upon, you are “locked in.�

    "If you use Force.com’s “Chatter collaboration� your application is now dependent upon that service and is locked into that platform. If you tie yourself to any of Google App image Engine’s proprietary services (data store, e-mail services), you are locked into that platform. You can’t move the application else unless you extract the integration with those services and replace it with something else."


  • I think some level of lock-in cannot be avoided. Even with standards in Web Services, B2B and integration. And these lock-ins are not only due to the technological stacks or even proprietary middleware. But every vendors or even technology comes with it's own nuisances of how certain things work and the way certain operations need to be performed.

    For instance, the way a particular technology or middleware allows exceptions to be handled could vary from another. And when you consider the transaction level or business level exception, the variations are even higher... it's not just technology but approach also matters.

  • The problem with SOA is that it really only takes into account the data. Great! We need to unify our data sources.

    But where PaaS is most effective is at the application level, and specifically putting application design (processes and workflow) into the hands of business users and only calling on developer resources when integration or custom logic is required.

  • As far as I can see, at the moment, the setup causing the integration problem mentioned (JAVA vs .NET), is hybrid usage of Web-technology:

    According to my understanding, Web-technology applies to the stratum of Social automation. However, if you have just technology in mind, you may apply Web-technology to the stratum of Functional automation (Logistics), as well, even to the stratum of Machine automation (Robotics) - as long as you are willing to pay the prize for intermixing different strata of automation.

    What is the prize? That you have to build your proprietary small Web, in terms of an Application-Server-controlled Intranet, alongside the single-one, open, global Web, accessed via Internet. You may have as many Intranets as you like, but responsibility for inter-operability is always yours.

    Which does not mean that you cannot achieve inter-operability between different application-server platforms, such as Java, .NET, and all the others. But you have to pay for this extra effort, which – in fact - you are incurring in case of EAI, BPM, SOA, SaaS, PaaS, IaaS, etc.

    As to the difference between hybrid and proper usage of Web-technology:
    -  If Web-technology is used in the Social stratum of the Web, the primary application    thread is starting always at Browser-side, never at server-side.
    -  If Web-technology is applied to the Functional stratum of Logistics, the primary    application thread is always starting at (Application-) Server-side, Browsers    degenerating to good old Mainframe-Terminals.

  • There shouldnt be any issues...If you adopt good web services (be them written in .NET or Java), implementing RESTful or SOAP for communication, then all should be fine, there is no challenge there at all....

    The same can be said of PaaS. I see the issue all down to the software you use. PaaS is a concept not a technology. So its down to the software you use on how best it can work, or not work on different PaaS providers...Platform independent software? Perhaps, but I have no problem with some lock in on some levels, without it, there comes a point where things are just too "abstract" that the benefits are outweighed by the issues (cost being one of them)...

Add a Reply

Recently Commented On

Monthly Archives