Open sourcing SOA

Open sourcing SOA

Summary: ZDNet's David Berlind points to the competitive threat open-source software poses to leading commercial suppliers, namely Microsoft. We're increasingly seeing adoption of open-source software in the Web services/SOA space as well.

TOPICS: Open Source

ZDNet's David Berlind points to the competitive threat open-source software poses to leading commercial suppliers, namely Microsoft. We're increasingly seeing adoption of open-source software in the Web services/SOA space as well. 

Open-source software from the LAMP (Linux-Apache-MySQL-PHP/Perl/Python) and LAMJ (Linux-Apache-MySQL-J2EE) stacks are the choice of a  significant segment of Web services developers.

The Web services/SOA survey released earlier this week by Evans Data reveals that at about a third of Web services developers now embrace open-source application servers. A total of 33% use, as their first choice of platform, Apache/Tomcat, the open-source J2EE/Java application server. Apache has just about caught up with Microsoft’s .NET-based application server platform (includes IIS), which still leads with 37%.

Microsoft continues to dominate many phases of the process. Three out of four Web services developers build their applications on Windows workstations, and deploy at least some of them within a .NET Framework.


Topic: Open Source

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


Log in or register to join the discussion
  • Interesting

    SOA is one technology that doesn't require that you use open source! A completely proprietary SOA solution would work - as long as the INTERFACES are standard. Would a customer care whether his billing application is running on Windoze or LAMP?
    Roger Ramjet
  • Breaking it Down

    As Roger Ramjet so rightly points out - SOA does not require OS. He could have added: or vice versa.

    My read on the Blogs at the other ends of your links is: David Berlind discusses the apparent monolithic approach being taken by Microsoft - which he criticises (in the nicest possible way), suggesting that a modular approach to marketing software functions might serve the company better.

    In addition, he discusses BEA (at the next level 'down' his Blog stack), and there strategic direction - also from the featureset vs. LAMP perspective.

    As we are in a SOA Blog, let's stick to that angle. SOAs come close to not requiring any technology at all. It is perfectly possible to describe an SOA (and I have done so in off-the-cuff whiteboard presentations) in terms of a 1950s paper-based office (memoranda, letters, tyewriters, secretaries, post rooms, Board meetings, invoices, card indecies, bills of lading, specifications, projects, filing cabinets, etc. etc.). SOAs are about business processes and, although the supporting technology does mean we can do some things 100 times faster, and a 1,000 times more accurately, the people in those processes have changed surprisingly little.

    Roger mentioned standards. There are 4 types of standard in SOAs:
    - Customers
    - Legal / Regulatory
    - External (Suppliers & Partners) and
    - Internal (Unique business processes)

    The software in SOAs reflects this by having a mix of standards; for base customer services and general suppliers (Net & Web Services); for specific industry participation (Schema, specific Net and WS implementations, etc.); for internal (mostly a proprietary arena - standard set by single supplier: Oracle, Microsoft, and er... ); and Legal / Regulatory (currently a Black Hole, in most industries). SOAs add to this a mix of tools that allow organisations to tailor their implementations to specific customer, supplier, partnership, and goverment/regulator needs. Not forgetting: Every organisation is unique - they have to have tools to handle that too.

    I can see where your coming from - LAMP, Open Office, and so on, could begin to produce 'standard' installations, or implementations, based as much on commonly used software as they are based on Web Services and industry-specific standards such as Schema. It is a sermon I am not above preaching, from time to time, myself.

    However, and this is possibly where David Berlind also needs to take a second look, there is another scenario. What if I (Software Company EIN, say) had the energy, customer contacts, standards contacts, ICT Service Company partners, and development staff to pull all of this together in a industry-by-industry way? EIN could corale all the services partners and industry-specific activists and say: "Guys, would you like to have an off-the shelf solution for your next generation of ICT infrastructure?" "Yes." they say. "Well then, let's sit down together and we'll write the software and test it with you as you write the specifications."

    For EIN this has the added attraction that, as an old software-as-product company, I need to address the growing poularity of OS - and my release of Version 1, monolithic architechture for industry X, will leave them a step behind - and with a fortress of installed base to overcome. The only fly in the ointment is all those old-programmer managers in my Key Customer base who will not stop fiddling with OS patch solutions, test implementations, and so on...

    In such a scenario a modular approach will not look nearly so attractive to either side - but particularly to EIN. Of course, there is a measure of speculation in this scenario. Or is there?
    Stephen Wheeler