 |
If you aren’t heavily involved in the continuing standardization of web services and Service Oriented Architecture (SOA), it’s easy to miss how it is evolving. Just before Christmas, David Chappell provided a nutshell update on his blog:
Last month’s announcement of Service Component Architecture (SCA) suggests that, in the not too distant future, choosing between Microsoft’s Windows Communication Foundation (WCF) and SCA will displace significant parts of today’s .NET vs. J2EE decision.
and linked to an article in his newsletter which explains at length – Foundations for Service-Oriented Applications: Comparing WCF and SCA:
When Microsoft went public with Windows Communication Foundation (WCF) in 2003, I wondered what the Java world’s response would be. We now know the answer: it’s Service Component Architecture (SCA), defined in a recently-published group of specs created by IBM, BEA, Oracle, SAP, IONA, and others.
Originally code-named “Indigo”, WCF was expressly designed to support the creation of service-oriented applications. SCA, according to its creators, focuses on “building applications and systems using a Service Oriented Architecture”, which at least in this case amounts to pretty much the same thing. In the .NET world, WCF is certain to become the dominant foundation for building service-oriented applications. If the vendors behind SCA can breathe life into this still-incomplete specification, SCA has the potential to play the same role in the Java world and beyond.
Much more by following the link including an explanation of the similarities and differences and what it means for the two platforms. For Microsoft, Indigo was always the least glamorous of the three original Longhorn “pillars” (Avalon, WinFS, Indigo) because it provides improved plumbing for distributed applications and thereby is hard to demonstrate to an end user. Of course, that didn’t change with the revamped menu for Windows Vista and the decision to backport Indigo and Avalon to Windows XP and Windows Server 2003, but the implications for enterprise applications are such that it should and will get more attention.
Paul Krill at InfoWorld:
Microsoft, IBM, and SAP are discontinuing the UDDI Business Registry (UBR) project for Web services on January 12, according to Web-based bulletins from the three companies.
There’s more by following the link, but Universal Description, Discovery and Integration (UDDI) is a XML-based standard for describing, publishing, and finding Web services within a distributed directory structure. The UBR was an attempt to create a public “White Pages” of conforming web services offered by various companies via linked registries at the three partners. It was hoped that public directories would lead to automated web service interactions among enterprises. While the technology was good, the UBR business model was not for a variety of reasons as explained at Microsoft’s All About Interop weblog. Quoting liberally:
Microsoft, along with IBM and SAP, announced they will close down their respective nodes in the public UDDI Business Registry, also known in our AHI as the UBR. [AHI = acronym-happy industry] Microsoft’s UBR is here, IBM’s, etc). The companies published a collective FAQ on the move.
In short, seems to me this is a tragedy of the commons type of story. All of the various implementations of UDDI worked together within the UBR, so interop was clearly demonstrated. (At this point, interop between UDDI registries is a real yawner, but 4 years ago, it was still a concept, a vision. Things change quickly. ) But, there was no quality enforcement or governance on the UBR, because there was no direct funding. Anyone could publish. No one was checking quality or doing garbage collection. So there was lots of, um, low-quality data in the UBR. But, that phenomenon doesn’t mean UDDI itself is low value, or is being discontinued.
The vendors will continue support of UDDI, the protocol, in products and services.
…
Companies will continue to use UDDI for internal registries. I expect that there will be public UDDI registries, also, but probably not a “commons” arrangement. Instead third parties will host for-fee service and will guarantee quality of the listings. Just a guess.
There is also a pointer to the CBDI Forum which has a worthwhile commentary including:
As a consequence of the lack of governance over the process of publishing entries to UBR, it was rumoured that 3/4 of the entries were invalid. Consequently most organizations steered clear of a public registry. In fact, very few saw any need for Services to be publicly advertised at all, as usage was either internal, or between close business partners who could be advised of available Services by other mechanisms.
However, that is not to say that the world doesn’t need some form of “public” service registry. Although the federated UBR that replicated entries between the IBM, Microsoft and SAP nodes will close down in January, SAP in fact will continue to host their public node.
But what it needs is governance and management over the contents, not the free for all that UBR is.
We mentioned the Microsoft and SAP joint development project, Mendocino, last week and today Microsoft issued a press Q&A. Excerpt:
Chris Caren, general manager of Microsoft’s Office Business Applications group, sat down with PressPass to discuss the “Mendocino” project, the December technology preview milestone, and how “Mendocino” relates to Microsoft’s Office business and strategy.
PressPass: Can you give us a progress report on “Mendocino”?
Caren: The development of “Mendocino” is on schedule. On Dec. 23 we’ll deliver a technology preview to 40 customers and 10 partners. So we’re making good progress towards a broader beta release in the spring and final availability in the late-summer 2006 timeframe.
More at the link, but as I mentioned last time, Mendocino seems to be the exception among “alliances” in the tech industry – something meaningful is actually going on. Gavin Clarke at The Register reminds us that in 2004 Microsoft and SAP were talking merger and provides an analysis of Mendocino. Punchline:
Mendocino represents an intersection of mutual self interest for both companies. It delivers all the benefits of Office as an enterprise information portal to Microsoft while unlocking a developer and partner ecosystem coveted by SAP without the strategic, tactical and legal mess associated with a big merger.
Renee Boucher Ferguson at eWeek:
As SAP AG and Microsoft Corp. hammer out the 1.0 version of Mendocino, their combined development project to offer mySAP process functionality in Microsoft Office for a seamless working environment between the two platforms, they’re also pounding out the second iteration.
Mendocino 1.0, expected in July of next year, will hone in on four scenarios—budget monitoring, time management, leave management, and organizational management—that expose process logic and workflow from mySAP applications to Office. That means users can, for example, use the cost center management scenario to access employee files, see pay information and issue pay raises, using SAP workflow that is exposed in Office.
Version 1.0 will ship this month to 40 customers and 10 partners for an aggressive ramp-up program. An additional 50 customers will be added in April.
The joint development teams from Microsoft and SAP will look to those users to help define new joint scenarios and delineate a development platform for version 2.0.
Expected on the market about a year after the release of Version 1.0—so around July, 2007—2.0 will continue to add scenarios around time management and employee self service. But it will also look to add a line of business scenarios, like CRM (Customer Relationship Management) and SRM (Supplier Relationship Management).
More by following the link. Unlike so many tech industry alliances, this one seems to be productive.
