By Jack Vaughan
How does cloud computing change development strategies for integration? The answer to the question is still a work in progress. A guide, however, may be found in Force.com. SalesForce.com was perhaps the earliest cloud player, building-out its whole company as a Software-as-a-Service offering, and launching one of the first Platform-as-a-Service (PaaS) offerings in the form of Force.com.
While SalesForce.com has fairly recently expanded its cloud portfolio to support open source oriented software in the forms of the Java Spring and Ruby-on-Rails frameworks, Force.com, with its proprietary Apex language, represents its flagship offering.
A good window into building cloud application integrations takes the form of a recent book: Development with the Force.com Platform: Second Edition, by Jason Ouellette. SearchSOA.com spoke with Ouellette at the time of the release of the first edition of the book for a podcast entitled ”Developing in the cloud with Force.com PaaS.” The story focuses on Apex as a language for writing business logic in a multitenancy setting.
We spoke with Ouellette again recently on the release of the second edition of his book. As can be expected in high technology, a lot has changed in the two years since the first edition. Ouellette said the Force.com platform has been improved in terms of JSON and REST API support; social media support in the form of Chatter components, feeds and APIs; and Batch Apex support added since the first edition.
SalesForce.com pioneered multitenant cloud computing, and, as such, had to solve some resource issues. SalesForce.com set governor limits to ensure fair treatment of applications from different customers. The number of records that can be queried at one time, the amount of memory used by code, the size of messages sent between Force.com and external hosts – all these matters are ”governed.”
Some individuals have likened aspects of cloud computing architecture to architectures of mainframe days. Certainly the governor limits discussed here recall the golden ears of batch computing. With Batch Apex, Ouellete told us, Force.com allows you to keep long-running data-intensive processing tasks within the Force.com platform.
Related Force.com information
Principle 73 in Alan Davis’ 201 Principles of Software Development discusses the need for loose coupling of software components. This is a ”known unknown” that bears repeating. Services composition remains a bit of a black art, and the key to successful application integration. Continued »
SOA has had at times a tough road to hoe, but it has survived and now with cloud computing architecture looming as the next big paradigm shift, SOA services stand out more than ever as the best path. Continued »
Are OSGi and Jigsaw at odds? The teacup tempest opens a view on a larger issue – that of component coupling. The Java controversy of late pits full OSGi modularity versus Jigsaw’s “simpler” approach. But, what is key perhaps is where the proper level of modularity lies for any given set of components. Continued »
As cloud computing and mobile services grow, the potential cost of poor performance becomes a greater issue. Yet, testing of newly integrated cloud services is just getting off the ground. A recent partnership between cloud computing provider RightScale and European load testing and performance-monitoring house Apica looks to address the issue. Continued »
Long in the forefront of application servers, WebSphere is sometimes a bit overlooked. However the latest version of the IBM application server is worth some consideration, as its new features point out some of the big enterprise trends of the moment. Continued »
In an effort to simplify integration, some teams have tried new languages to deal with data. Has XQuery, a big part of the initial XML and Web services push, gotten lost in the shuffle? Continued »
By Valerie Sarnataro, Editorial Assistant Coop
Although XBRL looms as an SEC mandate, uptake is still slow for the XML-based language that handles business information. To spur more interest, the nonprofit XBRL consortium is staging a contest to find the top open source tools for analyzing financial data. The competition, dubbed the XBRL Challenge, features a $20,000 grand prize to be awarded to the contestant who submits the most useful application using XBRL-formatted data.
Participants may include a company, team or individual developer. Entrants will be granted access to a database of XBRL financial fundamentals from all public companies and documents on how to work with XBRL data. Webinar and in-person meetings will also be offered to aid in working with the XBRL data, including an online XBRL Challenge briefing on August 3, 2011.
Submissions will be accepted up until January 31, 2012, while final judging and awarding of prizes will occur in February 2012. The panel of five judges will include: Alfred Berkeley, chairman of Pipeline Trading Systems; Marc Donner, head of Google Finance; Eric Gillespie, managing partner at Viano Capital; Vijay Khanna, general partner of GIV Venture Partners and Paul Ratnaraj, director of advanced initiatives at Wharton Research Data Services.
Jack Vaughan, Editor
Sometimes it seems application integration and SOA are either mortal enemies or birds of a feather – there seldom seems to be much of a middle ground there. The dichotomy is often on display on such worthy channels as the Service Orientated Architecture discussion forum. Someone there recently posted a job description for a SOA enterprise architect, and estimable forum members quickly chimed in, insisting the posting described an Integration Specialist rather than a SOAist.
SearchSOA.com has generally looked at SOA as how you do things, and application integration as what you mostly do. We found out that ”them’s fighting words,” if you will, back in 2009 when we quoted Gartner’s Yefim Natis saying ”SOA is integration.” This didn’t sit right with some people who thought it was, at best, a return to some naive notions from the early days of EAI.
Gartner actually distinguishes application integration from SOA, in a way. That is, it breaks out market Magic Quadrants separately for “Application Infrastructure for New Systematic SOA Application Projects” and ”Application Infrastructure for Systematic Application Integration Projects.” Late in 2010, contributor Colleen Frye spoke with Gartner’s Massimo Pezzini about some of these distinctions.
Again the dichotomy came up in a story last week on a book on so-called ”Lean Integration.” The story discusses what business-side people see as ‘gold-plating”- the feeling a simple near-term software project is made to meet long-term services criteria. They feel their project is being made to carry the burden of others. Lean Integration’s authors have a humorous metaphor to describe this. It is, ”the first person on the bus pays for the bus.”
Integration and SOA – if it was truly bloody simple to balance the two, well, SOA would be a no-brainer anyone could do. As Yefim Natis told us long ago, “The difficulty in SOA-oriented development is that it must achieve real short-term business goals while setting the stage for far-reaching architectural objectives.” On a bad day that can turn into a dilemma, a quandary or a hairball, take your pick. Let us know what you think.
Some controversies hang on forever. One such is the controversy around simplifying Java, which certainly goes back to the EJB 2.0 days –- and which is sometimes at the base of OSGi arguments today. There are plenty that feel OSGi is just too darn hard –- and it does appear at times that ISVs, who theoretically are well-supplied with the best and brightest programmers, are the ones most likely to carry OSGi forward. They would do this, one would suggest, by embedding OSGI, creating abstractions, providing sand boxes, and thus shielding ordinary mortal developers from OSGi’s true complexity.
SpringSource’s Rod Johnson, whose Spring Framework rose to prominence as a kinder and gentler way to do Java ventured into this battle earlier this year when he admitted to OSGi’s complexity. As SpringSource’s OSGi dm Server is one of the poster children for OSGi success to this point, Johnson found he had to do some clarifying. The server is now part of the Eclipse Foundation portfolio. Here, per TheServerSide.com is Rod Johnson’s take on OSGi:
(a) OSGi is a great solution for complex applications with stringent modularity requirements;
(b) typical business applications (from which we make the bulk of our revenue) don’t have such requirements;
(c) our efforts to reduce the complexity of writing server-side OSGi applications were promising, but the road to simplification was longer and less certain than we’d hoped. Thus continuing down that road at the Eclipse Foundation, in partnership with other companies and individuals, was a natural move.