”There’s a lot of room for raising awareness of SoaML. It’s not as well-known as it should be,” said long-time IBMer Lee Ackerman, now CTO and vice president of products, The Emphasys Group. Tools would help, he suggested.

And, in fact, Ackerman and his Emphasys colleagues have built a pattern-based add-on tool to IBM Rational Software Architect for WebSphere Software. The IBM modeling tool supports SoaML, but Emphasys looks to ease the implementation and improve SOA development outcomes via its Service-Oriented Architecture Design (SOAD) Model Accelerator add-on.

”With the Accelerator, we provide patterns and model restraints and reports that leverage information from [design] models,” said Ackerman, co-author of Patterns-Based Engineering (Addison-Wesley, 2010). Ackerman said the SOAD Model Accelerator helps a team decide what should be modeled and how. Embedded in the tool is knowledge of practical service identification patterns, which would be useful for what can often be a difficult task.

Modeling may always be disliked by some groups of hard-core coders, but UML verges on ‘mainstream’ in a fair number of enterprises.  The evolving mix of SOA, UML and SoaML is worth watching.

Is SOA itself mainstream? “If it’s not, it’s on the verge,” says Lee Ackerman. He says there are still newbies coming online to learn UML. Tools such as SOAD Model Accelerator, he suggests, can help experienced and new SOA users alike.   But SOA is more than tools.

“SOA is best practices. It is an approach. It is a mindset. Moreover, it is an architecture style. SOA really becomes a problem solver,” said Ackerman.

Is SOA complex? No, says Ackerman, but the problems it is being asked to address in the enterprise these days truly are complex, he said.- Jack Vaughan

More than a few developers took umbrage when SOA first came into play, and that was understandable, as it often appeared as a methodology trying to take away their chance to be creative. That is less the case now that services are more familiar. Thus, the certified ”SOA specialist” is becoming a meaningful job title. This is discussed in recent random notes on ”Services boundaries, SOA certification, and ESBs” on the SOA Talk Blog.

SOA had to adapt to get ahead. One of the big changes from the early days has been the ascent of REST (REpresentational State Transfer). The first days of SOA were very much tied with SOAP and XML. While both are useful, there are very many cases where they represent overkill, as a legion of JSON REST applications attest. Some SOA folks might have fought REST at first – but now most embrace REST as a form of SOA. The JSON and REST forms of SOA have even come into play when mainframes connect to services, as ”Services designer opens up mainframe IDMS for JSON, SOAP, REST” shows.

Young SOA was overhyped and, to many, a disappointment. But the fact that it morphed into something useful is the fact on which to focus. Ahead of us there are more Web-based applications, cloud computing and mobile platform development. When the IT future unfolds, it is a good bet that SOA services will be there, but SOA services and the people that work with them will transform in overt and subtle ways during the course of the journey.

Who can claim they saw all this coming? So many things are seen clearly only a long time after they happen. We wax poetic because it is summer, and because we just read Jason Ouelette’s book on development with the Force.com platform – the book comes with an epigrammatic dedication invoking Kierkegaard (”Life can only be understood backwards; but it must be lived forwards.”) – it proved a perfect ponder!

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

http://www.informit.com/store/product.aspx?isbn=0321767357

By James Denman

There have been some heated debates over on the forums at TheServerSide.com lately about whether full blown OSGi modularity is strictly necessary, or if Jigsaw’s “simpler” approach is good enough. Based on those discussions, the biggest issue in the debate may be where the proper level of modularity lies. The OSGi side maintains that each package should be its own independent module without dependencies on other packages, while the Jigsaw side puts forward the possibility that modules can be defined at a higher level then packages and that packages can be spread across modules.

Either way, the connections between the modules must maintain modularity or the benefits of having a modular architecture will largely be lost. The great thing about building with highly interchangeable parts is that you can pull one part out and replace it with another similar – but somehow better – part without disrupting the rest of the system. But if the parts are all soldered together, you can’t pull one without breaking another.

Bringing this analogy back to SOA, if you’re service components are bound by strictly coupled service contracts, you’re not getting as much value as you could be getting from your potentially reusable services. According to the Art of Software Reuse blog, the trick to maintaining modular services is to employ decoupled service contracts. Specifically, they advocate the Decoupled Contract Pattern from SOApatterns.org.

In a blog by Vijay Narayanan, we learn that the Decoupled Contract Pattern abandons the contract specifications of a WSDL document in favor of a more technology agnostic approach. By creating a contract without references or dependencies to any proprietary technologies, the Decoupled Contract Pattern enables a more modular binding of services.

More on decoupled design issues
Search for more on loose coupling on SearchSOA.com
From the SearchSOA.com Vault: Using atomicity to gain SOA granularity -Apr. 2009

Developers preparing work for operations have always been admonished not to ‘throw it over the wall’ but that has not naturally evolved into a true dialog with system admins that oversee the data center. 

It has been discussed in relationship to cloud computing, but it remains an object of attention for the classic data center as well.

Noted Agilist Scott Ambler has counted effective links between developers and operations as a major goal for many years. At IBM he has worked with others to incorporate such best practices in frameworks and tools.

Tools are important said Ambler, agile development practice leader for IBM, when we caught up with him at  Innovate 2011 event in Orlando, Fla., but he added that collaboration and communication are truly key. Dialog is needed, he said.

The noted Agile evangelist Ambler points out that agility can stall if quickly developed apps conflict with an ops department’s best practices.

“So many project teams run into trouble when they don’t talk with the ops people. A lot of developers don’t understand the needs of ops and their ways of doing things,” he says. “There is a gap, and it runs both ways.”

“Developers find ops won’t support the technologies that the teams have used. They won’t put up the servers. It’s a surprise.” It should not be, he said. “If you had taken the time to [meet] three months earlier, you wouldn’t get that surprise.”

Among projects Ambler has worked on at IBM is a process framework called Disciplined Agile Delivery. Elements influenced by this framework have been appearing in IBM Rational tools.

”We’ve baked in [DevOps] from a  forward perspective and a reverse perspective. From a forward-looking point of view, you need to talk with ops people on a regular basis, so you know about their release windows, for example,” he said. For the reverse point of view, in diagrammatic descriptions, ops’ defect reports can be automatically fed back to development.

“This is such a common sense thing, you’d think it always would be included as a explicit part of the project,” he said. Ambler suggested better developer communications with operations helps ensure that the agile team members are good citizens.

SOA is still going strong. Businesses that already use SOA are expanding their SOA initiatives and new businesses are starting to adopt SOA and to implement SOA technologies. The first-time SOA infrastructure purchase is shifting from ESBs to other technologies.

According to a recent survey from Forrester analytics, SOA “still has strong penetration and high satisfaction rates.” About 75% of enterprise respondents and 80% of small to midsized businesses that responded are planning on expanding their use of SOA. Back in 2009, the Global 200 enterprises had shown a drop in satisfaction. Only 18% responded that SOA was meeting all or most of their expectations. In 2010, this number rose to 33%, which is more in line with earlier years.

The utilities/telecom sector and the financial/insurance sector are still leading other verticals in terms of SOA adoption and satisfaction. Healthcare and public sectors still trail behind the rest of the pack. Geographically, North America and Europe show similar penetration patterns for SOA, but North America shows higher satisfaction rates.

Probably the most interesting finding of the survey is that interest in ESBs – which have been seen as the starting point for SOA architecture – is actually declining. While in 2009, 48% of respondents who had only made a single SOA purchase had an ESB. In 2010, that number dropped to 39%. According to Forrester analyst Randy Hefner, the shift of focus away from ESBs stems from the increasing similarity of SOA specialty products (like SOA management tools and SOA appliances) as well as a desire to make SOA simpler and stronger.

The Eclipse Foundation has announced access to a hosted beta version of its Orion project, an effort to create a Web-based platform for Web development. Eclipse Foundation Executive Director Mike Milinkovich said a new site known as OrionHub.org has as its goal to enable interested developers to provide feedback on Orion.

“Orion uses the browser navigation as the way you navigate your code base,” Milinkovich said.

The Eclipse IDE and development backplane, which is coming up on its 10th  birthday, has become a mainstay in server-side development. But its use, admitted Milinkovich, has been much more limited in front-end Web development. Orion is a wholly new effort and a wholly new code base, not an “Eclipse in a browser,” he said. The software appeared earlier this year in the form of an editor for JavaScript, CSS and HTML.

In terms of AJAX frameworks, Orion “uses Dojo and some pieces of JQuery,” according Milinkovich, who added, “we are trying to stay as framework-agnostic as possible.”

Developers from IBM’s Ottawa Canada operations came up with the idea for Orion. In a presentation at this week’s EclipseCon 2011 in Santa Clara, CA, they said that they anticipate a growing number of what they call ”online IDEs.” Orion joins Palm Aries, Cloud9 IDE and others in this new development software category.

For Orion, IBM is contributing a seed, according to IBM developer Simon Kaegi. “What we’ve contributed is akin to an integration platform,” he said.

Developers of all sorts are already doing much of their work in the browser, IBM developer Boris Bokowski noted. Popular Web browser tools include bug trackers, build trackers, indexers and – of course – documentation software. “All these things happen in the browser,” he said.

Running up to the Internet boom of 2000, Java developers were a much sought-after lot – they garnered high pay, and perks such as onsite playrooms and unlimited quantity of quality coffee. These days Java is the likely choice in mid-size and larger organizations.

But there is discontent brewing. In a recent webcast Forrester Senior Analyst Mike Gualtieri outlined ways in which Java is over the hill. Java could be a dead end for business application development, he contends, because it does not reduce application development complexity and is difficult to learn.

The surfeit of Java Web application frameworks has only made things more difficult, according to Gualtieri. Hearty soul that he is, Gualtieri ventured some posts on our sister site TheServerSide.com, to draw out developer comments on his thesis. As you might expect, many Java people rejected this notion.

We have heard some of Gualtieri’s arguments across the industry before. People always seem to think, if tools were easier,  more programming could be done by end users, usually business analysts. Business rules are a special case where breakthroughs always seem near – yet, even here, the business rule engines still require plenty of infrastructure that is programmed by Java or, in some cases, C# developers. The Java community has worked in recent years to expand Java’ usability by supporting Domain Specific Languages atop the Java Virtual Machine, but it is fair to say that progress has been sparse and slow.

We have heard the Java death knell before on our very own Web site. Historically, one of SearchSOA.com most popular stories has been a 2006 interview (”Analysts see Java EE dying in an SOA world”) with then-Burton Analyst Richard Monson-Haefel.  The premise was that the Java EE platform had grown too complex to be workable for enterprise developers. Monson-Haefel was on to something, for sure. Assorted lightweight frameworks (Spring and Seam, for example) have eased the pain and modernized Java. But Forrester’s Gualtieri is right – these ‘lightweight’ frameworks also conspire to keep Java development a slow and error prone experience. Stay tuned for our upcoming interview with Mike Gualtieri.

Let us know what you think. Use the “Comment” tab below.

An area of special interest here for us is the architecture track. In several ways it reflects the fact that messaging middleware is growing as an influence in Java design. At the event, the aforementioned Jeff Genender will discuss “ActiveMQ in the Trenches,” with a focus on tips on architectures and implementations. VMWare Engineer Mark Fisher will look at developing a message-driven architecture using the increasingly popular Spring framework. And, independent Consultant Heath Kesler will cover ways to communicate across Camel OSGI bundles in ServiceMix.

Whether you are diving into cloud architecture or not, you are no doubt working with REST and caching stratagems these days. That makes it a good time to learn from experts at the symposium who can discuss these stratagems in an enterprise computing context. To that end, RedHat’s Bill Burke will look at the relationship between RESTful applications and traditional middleware services. For his part, Reza Rahman will discuss leveraging caching across enterprise application tiers to achieve better scalability as applied in enterprise development tools such as Java EE and Spring.

The symposium is scheduled for March 16-18 at Caesar’s Palace. It is always a good time when the best and brightest of Java descend on Las Vegas just as St Patrick’s Day happens and the NCAA March Madness basketball tournament is getting underway. It is always fun when worlds collide.