Skip to Content
Recently there’s been more and more activities out there regarding why and how to use the LAMP stack connected to enterprise business applications. As I just read two articles (this one and this one) concerning how SAP and its competitors approach this topic, I started thinking about whether today’s state of the art architecture, namely SOA or more precisely how SAP applies it, enterprise SOA is a competitor of LAMP and especially scripting languages and frameworks (Perl, PHP, Python, Ruby and Rails, Groovy and Grails etc.) or they are rather complementary. My conclusion is that both approaches can be valid but the latter one seems to be more viable in the long run.

Why am I telling that?

As it can be seen from the articles mentioned, SAP is supporting LAMP much less than others. And it has a good reason. While for example PHP’s history is full of being used for implementing (mostly small, partly large) websites with some business logic but almost no so-called backend functionality, ERP and other enterprise applications of SAP are run mostly by huge or at least big enough companies. If you consider old versions of ERP systems or smaller customers that don’t want to invest in the Java stack of Netweaver, the only two ways of extensibility are changing ABAP code or use any language that has RFC connector and call BAPIs or whatever. Having this situation, in most of the cases it’s not only feasible but maybe one of the best options is to use Scripting in a Box, choose your favorite scripting language and go ahead.

Nevertheless, if you have to implement something for a bigger company and/or on top of a newer version of MySAP that includes Java stack, probably it’s better to utilize the capabilities that SAP provides. I’m telling this because of two main reasons: number one is that Java as a platform is in my opinion much more designed to be the base for applications having a relatively high architectural complexity; and number two is that SAP delivers various modeling and development tools and runtime environments, the so-called Model-Driven Architecture (for example Enterprise Portal, Composite Application Framework including Guided Procedures, Visual Composer), that make it easier and more cost-efficient to produce custom applications on top of the MySAP suite (or later on, the Enterprise Service Repository).

Last but not least, don’t misunderstand me: as a skilled programmer I like very much scripting languages, mostly Perl, sometimes I don’t even understand why operating systems have other user interface than bash or ksh :), but the trend, that probably none of us can turn back, is to empower more and more people with less and less technology skills to implement or adjust business processes implemented with IT systems quicker and easier.

However, I don’t fear that we as programmers will lose our jobs in the next 300 years or so 🙂

To report this post you need to login first.

5 Comments

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

  1. Anonymous
    You are totally right, that SOA and LAMP are totally different.

    On the one hand this results from the fact, that SOA is an architectural pattern, while LAMP describes a software bundle. But on the other hand using LAMP does not exclude to create software that applies the SOA pattern – for example PHP5 has a nice integrated Web Service Framework.

    In the second part of your blog entry you state that SAP is supporting LAMP (especially PHP) less than others. Maybe it would be a good question, why to compare two competitors (and they are no competitors) with so different target applications?

    If you want to compare SAP Software or only the Java Stack of the SAP Netweaver, please do so with applications, that have the same scope, e.g. JBoss.

    If you want to point out, if Scripting in a Box is feasable for application creation, than you missed it from my point of view. I think, it is clear for everybody, that the creation of a new business application or the extension of an existing ones should not be done using a Scripting Framework. This can have numerous reasons. If you look on transactional functionality in PHP and J2EE you will notice the diffrerence – in PHP has none, the J2EE specification supports different types of transactions.

    Scripting in a Box is more a concept, to create hooks into a software with small turnaround times. Not to change a software completely, but introduce a new aspect in a short time period. Furthermore it is as well an architectural decision to support dynamic scripting, an application once deployed should not be changed (except of bug fixes 🙂 ) but you want to supply the users with valid extension points, that support:

    – a dynamic access possibility
    – a maybe policy based access
    – a secure sandbox

    This can be achieved using scripting concepts directly integrated in the current programming language. Take a look at the coming Java 6 features (that will be once integrated in J2E6 as well), the JSR 223 introduces a scripting concept into the Java Language.

    Regards,
    Martin

    (0) 
    1. Peter Csontos Post author
      Hi Martin,

      I agree with the most of what you have written, however there’s something I probably didn’t phrase clear enough.
      I was talking about enterprise SOA not only in the sense of using web services for connectivity, but also concerning model-driven development approach and tools like Visual Composer and Guided Procedures being the “official” development environment of enterprise SOA. If you consider those, they can be considered as direct competitors of scripting languages. This could even imply that SAP doesn’t support scripting languages AT ALL, but what I tried to explain is that the situation is of course a bit more complex, that’s why these two worlds can live next to each other in a more or less peaceful manner.

      Regards,
      Peter

      (0) 
      1. Anonymous
        Hi Peter,

        I dont want to fight a long marketing buzzword battle concerning terms like SOA or even Enterprise SOA.

        Even if I can imagine, that you want to compare the ease of use between MDA Tools and Scripting Languages, I dont think that you can put both worlds in the same context.

        Furthermore we both know, that SOA (or Enterprise SOA) does not belong to MDA, as well as Scripting Languages can live without SOA. These are three terms from three different worlds that can be drawn together to make better software – as you already stated..

        Regards,
        Martin

        (0) 
        1. Peter Csontos Post author
          Hi Martin,

          In theory I exactly agree from the technology point of view, but as you also wrote, it’s a marketing issue.

          As you probably also know, the business case behind enterprise SOA is to compose new business processes and applications out of existing services in a quick and flexible way. That’s why SAP is investing so much in developling all the MDA stuff and promoting these tools heavily.

          Regards,
          Peter

          (0) 
    2. Anton Wenzelhuemer
      hi,

      …I think, it is clear for everybody, that the creation of a new business application or the extension of an existing ones should not be done using a Scripting Framework…

      This ain’t clear for me in this generality. O

      f course you can develop applications in a scripting environment and if you consider an ultimate SOA implementation it actually doesn’t matter anymore in which programming/scripting environment a service is created.

      Transactionality in a service oriented architecture is a topic for itself, widely debated. At first hand loose coupling and transactionality are mutual exclusive anyway. Transactionality in an advanced SOA IMHO is achieved elswhere, e.g through service orchestration, WS-Transaction or other such mechanisms.

      Of course such mechanisms are agnostic to the actual implementation of (atomic or composed)services, may it be ABAP, J2EE, perl, C# or PHP.

      just my 2 cents,
      anton

      (0) 

Leave a Reply