Assorted mash-up advances should not obscure this: Microsoft SharePoint portal continues to be a tremendous success. It also continues to attract third-party plug ins, to the list of which you can add the Appian for SharePoint module from Appian.

Appian for SharePoint can extend Microsoft Office SharePoint Server 2007 (MOSS) systems to include Appian Enterprise BPM Suite. The new release features Form Pickers and new packaged Appian Smart Services, as well as updates to the Appian for SharePoint Web Services interface.

“We realized that what the portal was missing was process. I think of BPM and portals coming together,” said Malcom Ross, director of product management, Appian. “The problem with portals was they weren’t ‘actionable.’”

Ross’s take on SharePoint is that “it is a very popular data and collaboration area with great value.” What it was missing, he suggested, was an actionable aspect – the ability to process what was displayed.

Microsoft has been at work for years on improving the BPM story of BizTalk server, and at the same time bringing Windows Workflow Foundation [don’t call it WWF] to the enterprise, but these architectures are still the province of the Microsoft developer. Appian aims its BPM tools at the business analyst or user.

“We approach SOA from the point of view of the user,” said Ross.

Call it the long-tail, the revenge of the nerds or the tortoise and the hare, but the fact is that Microsoft’s SharePoint portal continues to find new adherents eager to quickly integrate apps. Watch for more link-ups between Shareapoint and other enterprise tool vendors going forward.

What can help code generation succeed? Says Skyway’s Jack Kennedy,  code generation tools must offer options for post-generation changes. They must support round tripping, intelligent merging, user editable dependency injections, and more, he says. Check it out.

Also check out the discussion of Kennedy’s Top 10 principles for code generation  on TheServerSide.com. There is good give and take there.

While useful in getting large amounts of work done in a relatively short time, code generation does have its issues. It is sometimes far from popular with the rank-and-file developer corps. Some argue that this practice just reassigns a bulk of the human workload from writing code to configuring. What do you think?

What were the problems with Grid computing? Basically, it was too complicated and of too narrow use. But, let’s be frank and earnest, its biggest problem was that the term ‘Grid’ was too rigid and inflexible. That problem of Grid computing has been easily solved. Its name was changed to ‘cloud computing,’ a light and airy term with flexible connotation. Of course, I am kidding; cloud will not solve all the problems of Grid just by the change of a name.

The same was the case when object technology met SOA. For distributed systems, SOA was supposed to surmount issues objects were unable to overcome. Maybe this could happen, but over how much time? The vendors tended to speak as though this was a revolution, an overnight revolution.

History shows that SOA - like objects, like Grid, like cloud – took time to happen. Technical visionaries can see new tomorrows, but getting the whole world on board takes time. These points were driven home for us recently during conversation with Toufic Boubez, a veteran of the object era and an early leader in both Web services and SOA. He reminded us that humans tend to get excited and ‘forgot the patterns of the past.’ He likens the evolution of SOA to that of objects. It can take 10 to 15 years for a cycle to be established. Remember, objects only became mainstream when they turned into “Java” and “.NET.”

More from Boubez: “Now, lo and behold, we’re ten years into SOA, about the same time frame, where at the beginning everybody thought “Alright, service orientation is going to be the next big thing in a couple years, everyone will be doing service orientation and Web services.” Where, in reality, just because of momentum and all kinds of established procedures and established mechanisms, it takes a while for big corporations and organizations to move. Another 10 to 15 years and here we are. I think we keep forgetting the time it takes for these cycles. That’s one thing I learned from being exposed to these two big waves.”

A lot of present disaffection with SOA is just pure laziness – a wish for instant gratification, an aversion to the real work of IT. Like the story of the silver bullet technology, you have heard the admonition that work is hard before. The savvy technologist will measure the true path of cloud computing by thinking in terms of 10 to 15 years as well. It is a good timeframe for sober SOA analysis too. Don’t give up too soon, just to jump on the next merry-go-round. Be sure to read both our Q&As with Boubez On the road to SOA – Part 1, Early insights and On the road to SOA – Part 2, Governance is fundamental. There’s more to learn from this SOA pioneer.

The new release takes the form of SOA and Java EE management packs. A central part of the release is a Composite Application Monitor and Modeler component. In fact, this represents the first fruition of Oracle’s 2008 purchase of APM suite maker ClearApp.

The Composite Application Monitor and Modeler, or CAMM, automatically goes out and discovers Java components and SOA services and creates models that represent business processes and transactions. The models provide a view into the workings of complex transactions, helping developers to pinpoint performance issues in production, and providing a basis for discussion between the various stakeholders that must ‘have a scrum’ when significant performance problems are encountered.

The Oracle Management Pack Plus for SOA discovers BPEL processes as well as Oracle ESB services.

“When you look at things end-to- end, it is very hard to tell what happened. Unless you have the code and usage profile of a specific user, it is hard for admins to know what to do with a problem,” said Moe Fardoost, director of product marketing for Oracle’s Enterprise Manager line. This causes a lot of thrashing about for causes.

“CAMM has a model-driven engine,” he said. “You turn it on. It looks and discovers all the SOA components. It then constructs a model of your application environment from end-to-end.”

With a transaction map in hand, and a useful console that provides a view into complex systems, problems of performance can be more effectively addressed, Fardoost indicated.

In Oracle hands, the model-driven approach to discovery and management could very well go further in the market than it would have with start-up ClearApp. That, of course, was part of Oracle’s thinking when it bought the distributed application performance management expert.

Blechar writes that ”… ensuring that the architecture and analysis efforts of BPM, SOA and MDM projects are coordinated in a collaborative manner should be of extreme importance to business and IT management.”

Some of this should happen as part of an organization’s separate MDM effort to address the governance of data services. But collaboration is key as there is much to be learned from the data structures, workflows, and services coming out of  SOA and BPM projects. Look out application architects, here comes MDM!

Related MDM information
Master data enables BPM and SOA – Michael Blechar Gartner Blog

Writes Ford:

UML is a failure. It failed for several reasons. Mainly, it failed because it falls into the cracks between technical people (developers, architects) and non-technical people (business analysts, project managers, etc). UML is too technical for non-technical people, and not technical enough for technical people. By this, I mean that it isn’t really technical enough to do serious work on design by techies. At the same time, it’s obscure enough to be mostly incomprehensible to non-techies.

Maybe the fact that Microsoft finally came around to UML was the signal for a pile on. Fact is, UML’s major failing is that it exists, flaws and all. Things in the imagination tend to work way better, you know.

Related software modeling information
Arbitrary Markup Language - Meme Agora

The new system can handle more than 8 million pounds of fish - Cod, Pollock, Flounder, and other - per day. As the fish come off the decks and into the auction they must be sorted and handled somewhat as in the past, but the new system eliminates traditional manual data entry and use of pen and paper on the piers.

“As the boats unloaded, it’s pretty much the same,” said Bert Jongerden, General Manager of the Portland Fish Exchange. “But now, when it comes to weighing, there are barcodes [applied] for species, lot, and vessel.”

For Progress, applications like this show how its advanced technology portfolio can work with its well established Progress ISV partners’ program. Under the covers of the fish exchange trading system is a JMS server, originally out of Progress’ Sonic operations.

“What typically happens is that a technology is created with the enterprise market in mind – large shops. That is the first step,” said Colleen Smith, director of partner marketing, Progress.

“Now something like a messaging system is seen as part of an inventory management system. After it’s been out there, in the Sonic case some four years, you see a huge market opportunity for small companies to take advantage,” she said, referring to the Sonic MQ JMS messaging capabilities embedded in the exchange.

The fish exchange system is used by employees working on the docks to enter inventory data, then buyers in an auction room or online can bid on the catch.

Fish exchange processes have very unique semantics.

As Bert Jongerden describes it: “A Pollack catch (e.g.,) will get culled into market sizes (large, medium and small). It moves to the back field where containers are stacked on pallets. One person stacks while another one tallies. After a lot is completed, it’s tagged on a tote or collection of totes.”

Many BPM experts emphasize that BPM includes human actors, not just computers. This application is just such an example. Here the actors also include our finny friends the fishes.

REST has many uses, particularly with Greenfield projects that share data without high throughput requirements. There are means to speed up REST apps – cloud computing over time may be one such means. But you can’t enter the REST world with blinders on.

Just as the industry may have gone too far in embracing stateful binary communications in the early Web services days, it may go too far in embracing REST in every instance. In the real world, things will vary.

IBM Rational has a significant in-house REST project underway. It’s called Jazz, and it is a collaborative platform for exchanging application lifecycle management (ALM) data and artifacts. IBM did not really set out to do Jazz as a REST app. They re-architected the original Jazz platform, announcing a related Open Services Life-Cycle Collaboration (OSLC) initiative, about a year ago. It’s not an either/or proposition - a variety of means are available to connect via Jazz. Think of OSLC, still in germination, as ASCII for the developer of the future. In order for it to be loosely-coupled and widely supported it may not be able to actually do too much.

REST still seemed like a new thing a year ago when IBM told us they were using it in Jazz. At the time, I asked them - and their competitors - if REST would really work in this context. All said, ‘yes’ – some said ‘yes, probably.’

I pressed a noted XML scientist, asking, “Will this really work fast enough?”

“Sure,” he said, ‘just buy an XML accelerator.” I thought that was kind of droll - and I think the scientist may then have winked. 

“Not everyone has the money for those things,” I said.

“Sometimes you have to spend money to make money,” he replied. Then, surely, he winked. Soon, we discovered that both of our spouses could justify large shopping mall expenditures based on this principle of spending a buck to make a buck. This made sense, and neither of us would argue with the boss. But there did seem to be a slight hole in the RESTful balloon.

With Jazz and OSLC, IBM was pursuing a new notion of collaborative ALM, said Danny Sabbah, general manager, IBM Rational, in an interview at the IBM Rational user conference last week. 

In time, possibly, IBM may introduce Jazz in an open-source form that may resemble OSLC. For now, the company is merely surfacing aspects of OSLC so people can get a handle on what it is about.

Said Sabbah: “When you are trying to do a open-source normalization, you need to have community buy in. Loose coupling is encouraged.”

As a result, OSLC was surfaced not as a set of Java-based frameworks, but instead as a set of RESTful APIs. “It encourages participation from many angles,” said Sabbah. “All you need is an XML stream that you can query and get and parse and flow.”

There are drawbacks – and there are upsides. “At the core, it’s extremely inefficient,” admitted Sabbah. “On the other hand, it [serves as] the least common denominator for anyone who wants to take part.”

IBM, he said, will build-out OSCL collaboratively based on who wants to communicate. A Change Management profile of OSCL has just reached v.1.0.

“If you used XML and mashups for everything, the performance would not be acceptable. We have a hardened version optimized for running on J2EE, but we also have the set of RESTful APIs. That keeps it open.”

That is the essence of SOA, said Sabbah. “You have services definitions and you have services deliverables. What is behind it can vary.”