All About Interop : Websphere

Geneva supports OASIS WS-Trust, SAML

DotNetInterop — Fri, 07 Nov 2008 19:09:00 GMT

Last week at the PDC 2008, Microsoft released the public beta of “Geneva”.

“Geneva” is three things:

Geneva Server. This is a security token service (STS), as defined in the OASIS WS-Trust specification. This thing issues and transforms claims, manages user access, and enables automated federation.

Geneva Framework. This is a managed (.NET) Framework that helps developers build claims-aware applications and services, that connect to the STS. You can use it to process claims on either side of an authorization transaction (requestor or responder).

Windows CardSpace Geneva. This is just an extension of the CardSpace thing in Windows you know and love today. chances are, you've seen it, but you don't use it. In a nutshell - CardSpace is a set of Windows features and user-interface that lets users navigate access decisions and control how personal information is used. Everyone has multiple claims as part of their identity: you are a student at UW, you are an employee of BigCorp, you are a member in good standing of a particular club, you have received a particular security clearance, You have a bank account with number 4444-444-44 at BigBank, etc. CardSpace lets you decide which of the many claims you can make about your identity, to disclose to a particular service or server. Rather than disclosing "everything" about you to every server or service, you disclose only what you need to disclose for the particular transaction. That is one aspect of the identity model, and CardSpace is the thing in Windows that makes that possible.

CardSpace technology, and actually, the Identity Metasystem concept, is pretty cool. If you haven't looked at it, you should. The problem with CardSpace and more generally, using claims-based access control (CBAC) in an application, has always been that it was impractical. Microsoft delivered a client (CardSpace), but we didn't deliver an STS! And we didn't deliver an easy way for the server to evaluate and verify claims. Therefore developers didn't have an easy way to employ CBAC in their apps. Geneva will change this.

Now, some of you are thinking, "ok, this sounds interesting but I don't know what you are talking about with this WS-Trust thing and 'claims based access control'. And I can understand that. Here's the thing - instead of hand-crafting access-control logic into your application, instead of managing your own user list and access control list, you can "outsource" this job to an STS. The Authorization Manager (sometimes called AzMan) is similar in philosophy, so if you understand the utility of AzMan, then you will get the idea of CBAC. But AzMan is not standards based, not federated, not truly claims-based (it is role based, which is less general than claims-based), and not usable in Web services transactions. Imagine generalizing AzMan and federating it and using only standard protocols, and that's where we're headed with Geneva. You're gonna want to use this.

I said "Geneva is standards based." The key to standards is support by the vendors, in tools, frameworks, servers, and so on. Currently, WCF from Microsoft supports WS-Trust, as does the WSIT from Sun. WebSphere App Server v7.0 announced support for WS-Trust just last month, but I haven't had the time to test it with Geneva. Not sure of other frameworks. The key is, with Geneva, the server is now here, and people can and will start building on this. I think with the release of the Geneva CTP, we'll start to see broader adoption of WS-Trust and standards-based CBAC among frameworks.

One last thing to point out: In the cloud, the Microsoft Services Connector and the .NET Access Control Service, both announced at PDC as well, are built on “Geneva” technology and share the same claims architecture.

More Information:
Kim Cameron’s blog
Vittorio Bertocci’s blog
Get the Geneva beta
Single stop resource on Geneva

A list of “Geneva” sessions recordings at PDC:

code	Title	Presenter(s)	Link
BB11	Identity Roadmap for Software + Services	Kim Cameron and Vittorio Bertocci	http://channel9.msdn.com/pdc2008/BB11/
BB42	Identity: "Geneva" Server and Framework Overview	Stuart Kwan and Caleb Baker	http://channel9.msdn.com/pdc2008/BB42/
BB43	Identity: "Geneva" Deep Dive	Jan Alexander	http://channel9.msdn.com/pdc2008/BB43/
BB44	Identity: Windows CardSpace "Geneva" Under the Hood	Rich Randall	http://channel9.msdn.com/pdc2008/BB44/

Connect WebSphere and Java applications to SQL Server

DotNetInterop — Thu, 06 Nov 2008 00:55:00 GMT

FYI: The MS JDBC Driver is completely tested by IBM for use with WebSphere App Server v6.1 and v7.0.

From the IBM Announcement for WebSphere Application Server v7.0:

WebSphere Application Server V7.0 does not include the WebSphere Connect JDBC driver that had been provided in WebSphere Application Server V6.1. To replace the functionality provided by the WebSphere Connect JDBC driver, WebSphere Application Server V7.0 is tested with the DataDirect Connect for JDBC driver and the Microsoft SQL Server JDBC Driver, which may be obtained from DataDirect Technologies or Microsoft.

Connect your WebSphere/Java apps to SQL Server with this driver. Actually, you can connect *any* Java application to SQL this way - it doesn't have to be running in WebSphere. If you develop in Jetty or Tomcat or JBoss or Geronimo, the MS JDBC Driver will work fine for you.

If you have .NET applications, or Office apps, of course you can connect them to SQL Server also. In this way, SQL Server can serve as a nice interop point between Java and .NET applications, or between Java and MS Office (Let's say... an Excel spreadsheet).

Some notes:

the MS JDBC Driver is a free download.
It is a full type-4 (100% Java) JDBC 3.0 driver, fully tested and compliant with Sun's verification suite.
It connects to SQL Server 2000, 2005 or 2008
It works from any JVM on any OS platform, including Linux
It works with the Express version of SQL Server (which is also a free download) and it works with the Standard and Enterprise versions, too.
There is forum support available for the driver
There's a tech preview of a JDBC 4.0 compliant driver, here.

If this is the sort of thing that interests you, be sure to check the team blog for the JDBC driver.

Open Source and Interoperability

DotNetInterop — Wed, 18 Jun 2008 17:42:00 GMT

Open. Source. Is. Not. Interoperability.

Ted Neward is an entertaining and talented writer, not to mention a stand-up guy, and a first-rate technogeek.

But that doesn't mean he is always right. I was just reading and old post of his which I missed during my unscheduled sabbatical, in which he writes:

They [Microsoft] need to have an interoperability story that developers can believe in, which means some kind of open-source-friendly play,

I still, still totally do not get why Interop and Open Source are used so interchangeably, by so many people. Often by people whose viewpoints I respect, such as the esteemed Mr Neward. Or if not used interchangeably, why they are viewed as so closely related by so many people. I do not see these two things as mutually dependent. They are completely independent factors.

Interop is not open source. Open source does not guarantee interop. Period.

I am not making quality judgments on either open source or interop. I am not saying that one of them is good and one is bad. I am saying they are two different things. They are "silicon based computers" and "big endian bit ordering". They are related, they are neighbors, they are acquaintances, but they are not interchangeable. Nor does one imply the other.

Repeat after me:

Interop is not open source.
Interop does not require open source implementations
Open source does not guarantee Interop

People will disagree with this; I expect to hear some feedback saying "With open source I can see the code and therefore it is easier to build something that interconnects with it." I'm not buying that. That is lazy thinking or bad engineering or both. I can imagine that open source would imply interop, if you limit the definition of interoperability to mean "connect with previously written code in the same executable image." In other words, merging distinct code bases. This is a case where just linking up to a shared library can work, but sometimes seeing the code allows some better opportunity.

But this limited definition of interoperability is definitely not the mainstream one that companies and organizations are dealing with today. They want to connect large lego blocks together: Connect System A and System B together in a business process flow that makes sense, and which may evolve over time. Large-grained interop. This is not merging two distinct code bases together. Oftentimes the "code base" is not available - it is a pre-packed app. Maybe it is Oracle, or maybe it is a Salesforce.com app. Maybe the other end is a Sharepoint Portal, or a Medical Records management system from Lawson. These might be called system-to-system interop or app-to-app interop if you like, where network protocols are the thing, not compile-time-constants. Data interfaces, not code classes or interfaces.

In that situation, which I am arguing is THE mainstream challenge that architects and devs confront when they use the word "interop", looking at source code is not helpful, and I won't hesitate to argue, I think it would be counterproductive. Yeah, you read me right - it actually is harmful to look at the code if you want to connect two big apps together.

What is necessary to enable interop in these cases is PROTOCOLS, people. Standard protocols would be nice to have, but don't misunderstand - standardized protocols are not a requirement for interop. The requirement is for PUBLISHED protocols, not necessarily standard ones. PUBLISHED NETWORK PROTOCOLS ALLOW INTEROP. This is why a Java or .NET app can connect to an IBM transaction processing system, even though the on-the-wire protocols are completely closed and proprietary to IBM. The protocols are documented. They are closed yet published. And because IBM's DTP protocols are published (not publicly per se, but published to those who license the protocols), anyone can implement the client-side of the exchange.

The same goes true for, say, Microsoft SQL Server. There is an on-the-wire protocol known as TDS, also known as tabular data stream. Microsoft publishes TDS under license to partners, but I believe some have reverse-engineered it. The fact that the protocol is constant and published means that, for example, DataDirect can build an OLEDB driver or a type-4 JDBC driver for SQL Server.

It's the Protocols, Silly!

Standardized protocols are nice to have because the standard, if it is based on freely-available IP (or at the very least, IP available under RAND terms), encourages wider adoption and thus the virtuous cycle inherent in Metcalfe's Law. Standardized protocols are essential if you want broad interoperability, which of course is really important, and is what most of us are after anyway. Above I said that standards are not required, and I stand by that statement. But practically speaking, standards are almost a sine-qua-non of meaningful interop.

Web Services and XML are just common protocols, and their widespread adoption (owing in large part to the fact that they are standards) is the true source of their value to companies and organizations (again see Metcalfe's Law). It is not required that web service endpoints, either client or server, be implemented with an open-source web services stack, in order to get good interoperability. Instead it is essential that the endpoints conform to the standard protocol definitions. And the corollary is, the protocol definitions must be sufficiently clear, complete, relatively simple to implement, and relatively simple to test, such that faithful implementations of the protocols can eb validated easily and will interconnect transparently.

This is why .NET WCF clients can easily interconnect with Web Services enpoints running under IBM WebSphere App Server, though neither the .NET Framework nor the WebSphere web services libraries are open source.

Open Source Is Not Interoperability.

Java/XML Binding Options? WebSphere prefers JAXB 2.0...

DotNetInterop — Mon, 24 Mar 2008 17:54:00 GMT

I'm looking to put together more Java and .NET interop samples. If any of you have any particular requests, let me know. One of the key areas for interop I'm looking at is XML serialization.

Today I was scanning the web looking for insight into the leading Java-to-XML binding frameworks. For those of you who are .NET literate but not Java literate, "XML data binding" is the term Java people (and maybe programmers for other platforms too) use for what we .NET-heads call "XML Serialization". According to my unofficial count, there are, let's see... ah...roughly..... a zillion different options. XStream, XMLBeans, JAXB, JiBX, Castor, Zeus, Quick, etc. Then there are the vendor options, like Electric XML (from The Mind Electric, which was bought by Webmethods, which was bought by SoftwareAG, which ... ?? who knows what they are doing with Glue now? when I visited the webmethods.com website, it was down?). At one point, Oracle had its own option, IBM had its own option, BEA's was what became XMLBeans (via the "Beehive" gambit), and there were many others, I'm sure.

Let a thousand flowers bloom indeed. The problem with this "1000 flowers" approach is it presents a challenge to any developer who wants to just solve a problem. Where's the critical mass? Every developer has to go and evaluate this decision, and who knows which is the right choice for any given set of circumstances? Choice is great but too many choices can lead to higher decisions costs, and too much redundancy can stifle progress. One set of devs learns techniques and tools for JiBX and the next set learns the same for XMLBeans and ne'er the twain shall meet.

As I was looking, I learned that IBM's WebSphere Feature Pack for Web Services, released in June 2007, provides JAXB 2.0 support as the preferred Java-XML binding mechanism.

Seeing that JAXB is also the JCP-blessed option, it seems like the question "Which Java-XML binding framework is the mainstream one?" has been answered. Maybe this discussion has been over for a long time and I just missed the memo?

I am sure there will be numerous little frameworks that continue to explore the boundaries of XML-to-Java data binding, but JAXB seems like the mainstream winner approach for now. It is the Honda Accord or Toyota Camry of Java-to-XML binding - a safe, reliable, well-supported, well-known choice. Other options may have nifty features or cooler styling, but parts, service and maintenance on the Accord is going to be cheap and easy in the long term. You can't go wrong wiith that.

I've produced numerous examples of how to interoperate between Java and .NET using XML, and I chose other frameworks for the Java side, including XMLBeans and most recently, XStream, but at this point I think JAXB is going to be my mainstream preference for an Java XML data binding framework going forward.

If anyone has any guidance that disagrees with this, please advise!

SOA Story featuring WebSphere and WCF Interop, and wow! Look at those prices!

DotNetInterop — Thu, 13 Sep 2007 17:16:00 GMT

This is an older story, but you may have missed it. (I did!) Insurance provider Safeco initiated a SOA effort and within that, built a new application using WebSphere Process Server, ASP.NET, and WCF Services written in C#. The story was written up on infoq back in May, but it is still very current. The business process flow was designed and run within the Websphere piece, the web front-end was ASP.NET, and many of the backend services were implemented in WCF.

Interesting question - WHY would anyone do this? The customer felt developing WCF Services was truly productive, and the ASP.NET web UI Framework was rich and high performance. On the other hand the customer liked the business process design tools available with Websphere Process Server.

Interesting - last I checked Websphere Process Server was $90,000/cpu (that's list price, mind you!), while running WCF Services on a Windows server will set you back around $4000/server. Yow! On a 2-way server (pretty typical), you're looking at $180,000 list price for software licenses. Ah but wait! There's more! Don't forget the software maintenance - you do want support don't you? That will set you back an additional 25% which is, oh, $45,000, per year! (The first year of maintenance is included in the $90k) The contrast in costs for infrastructure software is striking.

Zowie! you pay 10x more every year, just in Websphere maintenance, than you do for the one-time fee for a single Windows Server license necessary to run the WCF Services. Surely Websphere Process Server has a great deal of features that WCF lacks (such as a business process engine and a companion (extra cost) tool with a graphical designer for processes), but wow, that price differential is astounding. The closest comparable to Websphere Process Server in the Microsoft portfolio is BizTalk Server of course. BTS2006 includes a business process engine and a graphical designer for processes, much like Websphere Process Server. (and of course, unlike WCF) It includes a set of adapters to enable you to connect your business process to the other assets in your enterprise. It integrates nicely with WCF. The license cost for BTS2006 will run you about 1/4 the cost of the $90,000/cpu WebSphere license.

$omething to think about. . .

IBM WebSphere Registry/Repository and Interop with .NET, part 3

DotNetInterop — Thu, 30 Aug 2007 08:04:00 GMT

Back in May, IBM had posted an article describing how to connect to its WebSphere Service Registry and Repository (WSRR) from .NET applications. A surprise to me. Not long ago I was huffing about lack interop on WSRR. I later amended my comments in a followup post, saying that IBM had documented a SOAP interface to WSRR. But apparently back in May IBM had addressed the question more directly with a nice developer article!

Basic Interop is not the only issue of course. As Anne Thomas Manes pointed out in a comment to the original post, there is a difference between basic interop and integration. WSRR defines its own data model for the artifacts stored in the registry, so basic connection is not good enough. The connecting application needs to have some understanding of the data model, the semantics of what is retrieved from the registry.

Is UDDI sufficient for this? Apparently IBM thinks not.

StockTrader on Channel9

DotNetInterop — Tue, 21 Aug 2007 00:47:00 GMT

Greg Leake does a review of StockTrader on Channel9. Check it out.

Improving WCF interop with Websphere/RAD by controlling WSDL Generation

DotNetInterop — Mon, 20 Aug 2007 21:56:00 GMT

I wrote about Christian's foray into this area a while back. Now comes news that other people are confronting the same issue, but with Websphere or Rational App Developer.

Here's the problem: WCF emits WSDL that is modular - the base WSDL file references other WSDLs and XSDs which are external. Christian found out that not all non-.NET tools (such as some PHP libraries he tried) can digest that modular WSDL, and a "flattened" WSDL works better in many cases. This apparently is also true with Rational Application Developer. If you are a WSDL hacker, you can, in 10-20 minutes, take a compound WSDL document and flatten it. But most people are not WSDL hackers and if they are, they don't want to be WSDL hackers. (Trust me on this)

Ideally, generating flattened WSDL out of WCF would be something you could just "turn on" - so that flat WSDL is automatically generated. In fact, this is exactly what Christian did. Modifying the WCF host so that the auto-generated WSDL is automatically flattened, is pretty simple, and general. This should improve interop with Rational Application Developer significantly.

By the way, Christian does his flattening trick by using a custom ServiceHost in WCF - the same extensibility point I used to improve interop with ASMX services, which I described in a prior post.

Feature Pack for Websphere improves interop with .NET

DotNetInterop — Mon, 20 Aug 2007 21:38:00 GMT

Back in June, IBM Announced the Feature Pack for Web Services for WebSphere Application Server V6.1, which adds new support for WS-* protocols into Websphere App Server. Find the announcement here.

In the announcement IBM stated that the feature pack

...extends the capabilities of Application Server V6.1 to enable Web Services messages to be sent asynchronously, reliably, and securely, focusing on interoperability with other vendors.

(The emphasis above is mine). The list of WS-* protocols supported includes

WS-RM
WS-Addressing
MTOM
WS-SecureConversation

I haven't tested the feature pack for interop with the .NET Framework 3.0 and WCF, but that testing is now on my list.

anyone have any experiences that they'd like to report? Issues they've uncovered or solved?

Fact Check – IBM’s Steve Mills claims on MS and SOA

DotNetInterop — Fri, 10 Aug 2007 03:13:00 GMT

We saw an article on CNET that included quotes from Steve Mills of IBM directly related to Interop, SOA and Microsoft. Since Interop is one of our passions, we thought it would be worthwhile to respond. Given that we are approaching an election here in the US, we are employing a CNN technique. Let's check the facts.

Claim: Steve Mills is Senior VP of IBM Software.

Microsoft Fact Check: TRUE. Mr. Mills runs IBM Software, which is about a USD $18B business for IBM. By the way, IBM Software Group contributes about 40% of IBM's pre-tax profit, according to a recent ComputerWorld article.

Claim: Microsoft's approach to SOA [is] stymied by its emphasis on linking Microsoft-compatible processes. "We're doing all platforms; all applications," IBM Software Group executive Steven Mills told ZDNet.co.uk. "We're integrating everything. Microsoft is trying to provide connectivity capabilities for those that are running on Windows platforms. That's a profound difference."

Microsoft Fact Check: Mr. Mills seems to be commenting on Microsoft SOA infrastructure software, including the .NET Framework (and WCF, and WF, and all the constituent technologies), BizTalk Server, Host Integration technologies, and so on. If the claim is that this Microsoft software runs only on Windows, then this is TRUE. This is not a particularly novel, interesting or relevant observation. Incidentally, it applies to Mr. Mills' portfolio as well: CICS and IMS for example. Or consider DB2: it runs on many systems, but the capabilities in the mainframe version differ from those versions for other platforms.

Mr. Mills seems to be saying something different: he seems to be implying, because BizTalk Server (as one example) runs only on Windows, then it can connect only to other Windows-based systems or applications. That is FALSE. The facts are: the vast majority of the over 7,000 BizTalk Server customers use the technology to connect with assets on UNIX, Linux and mainframe based systems: 92% perform heterogeneous platform integration. In fact, Microsoft has long offered a technology that does nothing but integrate with IBM's iSeries and zSeries technologies. (it accomplishes this via IBM's proprietary protocols, which Microsoft must license).

Claim: "Their perspective is how to make Windows environments connect, as long as you're using Microsoft technology. Our view is: how do you make every environment connect whether you are using Microsoft or anyone else's technology," Mills said.

Microsoft Fact Check: This is the continuation of Mr. Mills' previous thought. In virtually every enterprise above a certain size or age, the rule is heterogeneity in IT. Whether you're an international bank, a specialty manufacturer, or a chain of sushi restaurants, there's a myriad of information systems and applications you need to deal with, and better connections among those systems allows you to run your business better. That's what SOA is about, and that's what Microsoft's SOA platform infrastructure is designed to help with. Thus, FALSE.

Claim: Mills claimed there is a big difference between IBM and Microsoft's approaches, saying that, in contrast to Microsoft, IBM uses open standards for XML and web services.

Microsoft Fact Check: FALSE. Implying that Microsoft does not support standards like XML and WS-* is odd. This denies the reality of the past 7 years, during which Microsoft has repeatedly been recognized by independent analysts as leading the industry drive toward defining and implementing open protocol standards such as XML, and WS-*. It is also an attempt to revise history as Microsoft and IBM partnered on Web Services Standards in 1999 which led to the original specifications. Mr. Mills himself stood up with Bill Gates to talk about the two companies' collaboration on these standards. Moreover, Microsoft and IBM have continuously defined additional Web service specifications and publicly tested interoperability. Examples include WSDL, WS-Security, WS-ReliableMessaging, etc.

But let's talk specifics. Take one example: XML Serialization. XML Serialization has been part of the .NET Framework since v1.0. XML Serialization allows a developer to map between instances of objects in a program, and instances of XML documents, very simply. This is a key interop-enabling capability; it means, in part, that a .NET application running on Windows can very simply emit an XML instance document that can then be consumed by any other XML-capable application, running on any other platform. Or vice versa. And it's a foundation for other, higher-level interop capabilities: start with XML Serialization and add in message transport and tools, and you then can get Web services.

This XML support has continued through the versions of .NET across the years, and has been expanded significantly. WCF, shipped in .NET 3.0 in December 2006, added some new capabilities and more mature models – dealing with XML in .NET apps is now both easier and more flexible. The list of open standard protocols supported in WCF includes: HTTP1.1, XML, SOAP1.1, SOAP1.2, WS-Addressing, XOP, MTOM, WS-Security (including x.509, Kerberos, and SAML 1.1 token profiles), WS-Policy, WS-Trust, WS-Coordination, WS-AtomicTransaction, WS-SecureConversation, WSDL 1.1, WS-MetadataExchange, WS-Transfer. Looking forward, in the .NET Framework v3.5 (currently at beta 2), we've included support for REST-style web services, as well as internet syndication protocols like ATOM and RSS, and other protocols like JSON.

Microsoft does support optimized protocols and formats in WCF for Windows-to-Windows communication. IBM provides similar optimizations for their products, as do all SOA platforms.

Claim: Microsoft and IBM have tussled over XML standards.

Microsoft Fact Check: TRUE. But, like the observation that Windows is the OS that underlies Microsoft SOA infrastructure, this is not an interesting part of the story. The picture that is painted by the article would lead one to suspect that a tussle over standards is exclusionary or at least stalling productivity. Coexistence of multiple standards and encouraging market participation in standards evolution is paramount. The OOXML / ODF point in the article is like saying you won't be able to send digital pictures to your mom because there isn't a single standard for graphic presentation. Clearly there are multiple standards for digital images, gif, jpeg, png and so on - which has arguably helped drive utilization. The far more important point is implementation of multiple standards which Microsoft technology does.

OOXML and ODF are about documents. Discussion of documents needs to include all standards, many of which Microsoft supports and has lead. Examples include HTML, CSS, etc.

Claim: "The [Microsoft] MSDN mechanism is a lightweight messaging infrastructure in a message-based environment, whereas IBM delivers a fully functioning infrastructure," [Mr. Mills] said.

Microsoft Fact Check: FALSE, judging from the wide variety of customer case studies that describe how customers utilize .NET and the rest of the Microsoft platform to broadly exploit the benefits of SOA. Microsoft customers use the Microsoft SOA infrastructure to run the core information systems that power their businesses. IBM's Web sites discusses the "entry points" to SOA. Microsoft has equivalent products in Microsoft Office Sharepoint, IIS/ASP.NET, BizTalk Server, WCF, Visual Studio and adaptors for existing applications.

As a side note, MSDN is a developer-outreach program, including a website, a software subscription and licensing offering, a magazine, and more. It's not directly related to SOA infrastructure. IBM has developerWorks, which is similar in intent.

In Closing

Do you want to know just how serious we are about Interop and Performance? Take a look at our .NET Stock Trader application which we modeled after IBM's Trade 6.1 performance application. We've demonstrated our ability to interoperate with applications that run on other platforms including IBM WebSphere applications running on Windows, Linux, or Unix™ . Don't miss this part: the .NET application duplicates the function of the Websphere app, but with far better performance.

[This article was drafted by Dino Chiesa and Steven Martin. It is being posted on both of our respective blogs.]

StockTrader - now with source code

DotNetInterop — Fri, 27 Jul 2007 22:03:00 GMT

Last month I wrote about the .NET StockTrader app, an app that shows Interop between .NET/WCF services and services running under IBM WebSphere.

The .NET source code is now available. Download it here. The main stocktrader page on MSDN will be updated with this link soon.

Cheers!

Update, 27 july 2007 245pm US Pacific time: The stocktrader page has now been updated with the links to source code. Also, there's a link to a new forum that has been started to support discussion of the sample app. Enjoy!

IBM WebSphere Registry/Repository and Interop with .NET, part 2

DotNetInterop — Mon, 23 Jul 2007 15:51:00 GMT

In a prior post, I said that there was no good interop story between .NET and the IBM WebSphere Registry and Repository (WSRR). I said this based on an examination of the WSRR documentation. IBM's product doc is available online and keeping to the IBM standard, is usually very thorough and clear. I looked all through the doc and did not find any reference to a SOAP API, or any other option which would allow interop between .NET apps (or tools) and the IBM WSRR.

But I apparently missed it. Mea culpa! A colleague pointed out the doc reference to me today.

In fact there is a SOAP interface for the WSRR, IBM calls it a SOAP API.

It's a bit funny though; IBM has a big disclaimer on the doc page:

Deprecation of this API
IBM is working to define a standard API for a service registry such as WSRR. The current SOAP API will be deprecated when such a standard API is defined.

A quick look through the doc, it's pretty clear that it's a temporary measure. The usability of the thing looks iffy. I don't mean to cast stones. It just looks half-baked is all.

Anne Thomas Manes suggested that IBM could have supported UDDI as at least one of the network protocols to access this registry, and thereby support a number of tools that already speak UDDI. IBM could have done that but they didn't.

In a related note, today I heard about a customer who is implementing a custom Visual Studio plug-in that will access the IBM WSRR, via that SOAP API. It will be interesting to see how the exercise goes.

There ya have it.

Custom WCF Channel for IBM MQ

DotNetInterop — Mon, 16 Jul 2007 21:06:00 GMT

IBM have shipped an early version of a Custom WCF Channel for MQ. The dev team in Hursley contacted me to solicit feedback. It's apparently pretty simple now, supporting only SOAP one-way messaging, but they say if there is sufficient interest and feedback, they will consider developing it further and perhaps adding it to the MQ product (as they did with the MQ Classes for .NET, and other stuff).

Out of the box, WCF includes support for queued transport, over MSMQ, which is the Microsoft Message Queue, built-into Windows. This is available in the NetMsmqBinding. You can read more about it here.

What our friends at IBM are doing is similar, but different in a very important way: In the IBM channel, messages are encoded and sent via the message queue, just as with the NetMsmqBinding. However, with the IBM channel, of course, the queue is WebSphere MQ v6.0, and not the built-in MSMQ. There is one other important difference though: Messages are encoded using the SOAP over JMS (Java™ Message Service) message format described in WebSphere MQ 6.0. Why is this important? This enables interoperability with services and clients hosted by other environments that can also read or generate SOAP-over-JMS. Examples are such as CICS (Customer Information Control System) and WebSphere Application Server.

So this channel has the possibility of opening up some new interop capabilities between .NET / WCF applications and apps that run in non-.NET environments, including Java applications running in WebSphere Application Server.

Please do have a look:
http://www.alphaworks.ibm.com/tech/mqwcf/

What about this SCA thing?

DotNetInterop — Wed, 27 Jun 2007 18:07:00 GMT

Ever heard of SCA? Service Component Architecture? (Leave it to the English-speaking people to glom together 3 nouns and expect people to understand what that jumble of words is supposed to mean. In the glass-houses dept: shades of "Windows Communication Foundation." But I digress!). I've certainly heard of it. From time to time, people ask me, or those around me, what about this SCA thing? People ask, what does Microsoft think about SCA? Will Microsoft support SCA? How?

Well, at this point, it's hard to say. Before I get into why, let me give my take on what SCA is. SCA is another multivendor integration spec to come out of the Java community, along the lines of OSGi, ebXML, JBI (JSR-208), and JCA (JSR-16, JSR-112). Yes, I understand that SCA is more heavily service oriented than JBI or JCA for example. But still, SCA is about integration in Javaland, and it falls in that line.

Why is it hard to say whether or how Microsoft would support SCA? There are a couple reasons.

First, the jury is still out. No one - not Microsoft, and not even the spec authors - no one is sure of the real value here. The various prior efforts from the Java gang (ebXML, JBI, JCA, and others) have exhibited different degrees of success in delivering value for customers. It’s not clear at this time how SCA will turn out. Sure, the specs are finished, to the extent that they are v1.0. But we've not seen a huge wave of products supporting the specs. We haven't heard customers saying - yes, "SCA is making the business benefits of SOA so much more attainable." Will SCA follow the model of ebXML? JBI? JCA? If SCA duplicates the success of the most successful of those prior specs, it will at best be a niche thing. But it could also be significant. We don't know.
Another thing: SCA is primarily about Java. Sure, sure, the OASIS page says "SCA is about SOA". That naturally leads me, and probably lots of other people, to think "Interop". But come on, have you read the specs? There are placeholder-y things for C++ and PHP, but really these specs are mostly about Java. (Yes, specs, plural. SCA is a family of specs. ) SCA looks and feels to me like EJB++, in the same way that J2EE was CORBA++. SCA specifies a model for a services composite, and most of the context around that composite smells strongly of a cup of Java.

Before you all get all huffy on me on this point, just stop and consider it. The Java focus of the SCA family of specs should not be surprising. Just follow the money. These specs are primarily being designed and driven by vendors - IBM, BEA, Oracle, Iona, SAP, TIBCO - who make money selling server-side Java infrastructure – J2EE and extensions to it.

A big part of SCA deals with current complexity in Java and J2EE, particularly around connecting distributed components. Today, Java has myriad programming models for communicating among disparate pieces of a distributed application: RMI and RMI/IIOP; web-services via JAX-RPC or JAX-WS; asynchronous invocation with JMS; JCA for packaged apps or for proprietary systems like IBM CICS, and so on. This is not a knock on Java. It's a consequence of evolution of the platform. SCA's Java annotations spec and Java component model spec attempt to unify those communications models in a single programming framework. And hey, that's a good goal. There's nothing wrong with doing this. In fact this is a page right out of Microsoft's book - we've already done this for .NET with WCF. But let's be clear, this part of SCA is all about JAVA. (Great question: why isn't this piece being specified in the JSR process? That would seem to be the natural home for it???) In addition to that subset of SCA, there is the SCA spec for the Java client for Spring, the EJB Binding, the JMS binding. Java Java Java Java. A large portion of SCA is about Java.
Another reason it is hard to succintly answer the "will Microsoft support SCA, and if so how?" question - SCA freely mixes the language-specific (aka Java) stuff in with the language generic stuff. When I saw this, I could only wonder, Why? This makes it pretty clear that the spec authors aren't interested in specifying a clean interop standard - something that cleanly and succintly describes how to interconnect apps. Instead SCA amounts to a portability and migration spec. How to map Java logic to services, and how to bring existing Java/J2EE apps into the brave new world of Services.

When will we know more? When might I have a better answer to the question, "will Microsoft support SCA, and if so how?"

That's hard to say, too. I know that answer may sound evasive (maybe it is part of my DNA). But look: I'd expect delivery of commercial-ready implementations of the SCA specs, from vendors like IBM and BEA, in late 2007, possibly later. But those would be small scale roll-outs - small in terms of number of installations. And of course small is a relative term. Alfred Chuang of BEA used to talk on his earnings calls of growing his customer base from 13,000 customers to 14,000 customers. This is great, but Microsoft counts its .NET developers in millions. Given that, if a hundred customers begin using SCA to good effect, is that enough to incent Microsoft to action on SCA? Probably not! What numbers would reach the threshold of interesting? I don't know.

To wrap up, SCA is primarily NOT about Interop. SCA is primarily about Java, and describing a new service-oriented metaphor for Java-based application logic. Something to succeed J2EE, which offered a metaphor grounded in components - Enterprise JavaBeans(tm).

We think Interop is important. Customers get good value when obstacles to interconnections fall away. We started working on XML and Web services standards, along with other industry leaders, back in 1999. We're committed to supporting Interop over open standard protocols, to deliver that customer value (case in point: WCF). (**We also so our best to support non-standard protocols, via adapters that connect to proprietary systems like SAP ERP, or IBM transaction systems and MQSeries. ) We're pretty sure SCA doesn't raise the bar in the interop arena.

.NET StockTrader shows Interop between WCF and WebSphere

DotNetInterop — Mon, 18 Jun 2007 15:47:00 GMT

Customers looking to build distributed applications according to the principles of Service Oriented Architecture (SOA) can use the new .NET StockTrader as a blueprint. This new sample/performance kit download includes full source code and a technical whitepaper that provides best-practices guidance for developers seeking to create high-performance, scalable, and interoperable financial services solutions on Microsoft’s Application Platform, including Windows Server, the .NET Framework 3.0, and the Windows Communication Foundation (WCF). Some key highlights of the sample:

Performance: Since performance is often a key concern when building mission-critical applications, the StockTrader download includes instructions for how to conduct performance testing across distributed environments. This is particularly useful when combined with iterative configuration changes - for example, changing the WCF protocols used, or changing a service to use asynchronous delivery. You can assess the performance impact of a change to the service implementation, relatively quickly.
Interop: The StockTrader application also illustrates full interoperability with the Trade 6.1 sample/benchmark application for WebSphere from IBM. The service interfaces in the .NET StockTrader mirror those used in the Trade 6.1 application. The .NET services can transparently interconnect with the WebSphere-based services in Trade 6.1, with a simple URL change in a configuration file.
Scale out: The StockTrader application illustrates an architectural pattern for load-balancing across multiple instances of a WCF Service. This simple and easy scale-out mechanism requires no special, extra-cost software, or obscure techniques. And you don't need to configure Windows Load Balancing to do it.
Configuration: StockTrader also illustrates a pattern for managing the configuration of all the various distributed WCF services in the network. As a services network expands, managing the configuration of all the various independent services becomes challenging. All StockTrader services implement a common administrative (web services) interface, which allows secure, remote configuration changes, without mucking with WCF config files.

An excellent sample and illustration of interop, StockTrader can also be used a comparative benchmark. The full benchmark results show that the .NET Web services in StockTrader deliver twice the performance of the equivalent Web services running in WebSphere, at less than ¼ the software license cost of the IBM solution.

http://msdn.microsoft.com/stocktrader

(Update, 27 July 2007: the source code is now available, download it here.)