Service Oriented Enterprise

Tuesday, April 22, 2003

Memory Lane  

Just took a jog down memory lane, see:
The issue was that you shouldn't try to get an opensource community to rally around a crappy specification - just doesn't work.

posted by jeff | 7:20 PM

SOE and Corporate Strategy  

The guys over that the Balanced Scorecard Collaborative produced a way to link the Service Oriented Enterprise back to the Key Performance Indicators of a corporation. They have created an XML Schema for structuring the reporting of on various metrics. This effort is called the, "Balanced Scorecard XML Standard". Although I'm not sure about the longevity of this particular standard, it does represent the thinking that a service network will be able to monitor active processes inside a corporation and send off alterts to a real-time business intelligence (or as I prefer, Process Intelligence) monitoring station.

One can anticipate that the XML Schema will eventually be complemented by some WSDL and may be aligned with pre-canned BPEL abstract processes. The era of strategy focused, process driven, service oriented, platform ready computing is coming. It is great to see the guys at BSCOL working on this problem from the top down...

posted by jeff | 5:57 PM

Gartner Matrix on Business Rules Engines  

Gartner released their matrix for Business Rules Engines for April of 2003:

The full report is here.

The report comments, "There is an emerging concept that service-oriented architecture (SOA) and its associated Web services also should include rules sensitivity. This may occur through 2004; the momentum has yet to be determined."

Although Gartner loves the, "Software as Service" story, they don't seem to be as bullish as one might expect on the exposure of business rules as services. The report does not mention the syndication of business rules for highly regulated industries (HIPAA, Patriot Act, Sarbanes-Oxley, etc.). However it does mention that one must consider the SOA:

"We believe that new agile applications will be composed of flow rules and services that leverage SOAs. Therefore, large vendors such as IBM and Microsoft must buy, build or integrate rule engines. We expect it will take 18 months or more for IBM and Microsoft to deliver the kind of functionality that can compete effectively in this market. Ultimately, there may be too few stand-alone rule vendors to justify a separate market. "

What happened to the DragonFly project from Microsoft???

posted by jeff | 3:03 PM

Web Services Exercise #1  

The marketing department at a Fortune 500 company has realized that 10% of their revenue is being generated from their online Internet presence. The Web group has also determined that almost 50% of all of their traffic is being directed to them by the Google search engine. In an effort to increase web traffic the company has decided to create software to monitor and report their “ranking” on Google. The software has the following requirements:

1. Every Monday at 4AM, a snapshot of the Google rankings should run.
2. The software should read from a set of stored keywords (supplied in advance) that the user would like to query Google.
3. The software should loop through the keywords, send the query to Google and retrieve the results.
4. The results should be turned into an HTML page that can be saved to a web server and rendered later.
5. Every Monday at 9AM, an email should be sent to a distribution list (supplied in advance) notifying them that the report has run. The email should also contain a link to the report.

Design this system using a service oriented approach. Leverage web service interfaces to the SMTP, the job scheduler, the HTML report writer, file persistence, FTP and the search engine. Leverage BPEL to tie it all together.

To do:
1. Create service interfaces, including WSDL & XML Schemas
2. Create any BPEL documents (if needed)

posted by jeff | 2:11 PM

What is wrong with last-gen EAI?  

Customers are tired of having proprietary EAI solutions and want to standardize on the integration mechanism.

The old EAI platforms didn’t do a good job of communicating between each other (Tibco to MQ Series, etc.). Since different businesses picked different vendors, it made it difficult to use these systems to connect independent businesses (or often different business units).

The old EAI platforms were not tuned for ‘long running transactions’

The old EAI platforms didn’t provide ‘compensating transactions’

The old EAI platforms didn’t recognize Web Services / SOAP as a ubiquitous communication device.

The old EAI platforms had proprietary solutions to transformations rather than moving to standards like XSLT.

The old EAI platforms had proprietary solutions for security – they didn’t employ standards like WS-Security for universal security needs.

The old EAI platform all had proprietary solutions for reliability – they didn’t standardize the ‘at-least once, at-most once, in-order, on-time’ delivery functions like is employed in WS-Reliability.

The old EAI platforms had proprietary solutions for node-to-node routing. Thus passing payloads with an itinerary required the vendor solution at each node. Today this may be accomplished by having components that support WS-Routing.

The old EAI platforms focused more on integrating legacy systems than on creating integrated business processes.

The old EAI platforms didn’t have the ability to create abstract versions of a process. Thus the ability to create standardized processes between businesses was nearly impossible. This has been advanced with the BPEL abstract process capabilities.

Customers think that the old EAI price tags are just too expensive.

posted by jeff | 1:59 PM