DFC, Microsoft developers, .NET and DFC PIA

In early 2002 Microsoft released .NET 1.0, and it was quite clear that .NET would quickly supplant COM as the mainstream runtime for the Microsoft platform.

Fortunately, .NET provided good (bi-directional) interop with COM (e.g. callable wrappers and interop assemblies). Furthermore, software publishers (ISVs) could produce primary interop assemblies (PIAs) to add functional, deployment and administrative value above that produced by simply pointing Visual Studio at a type library.

So, based on customer requirements and demand, the DFC PIA was born and was first released with DFC 5.2.5.

DFC, DJCB and DFC PIA in relationship

Beyond just producing a strong-named assembly using a Documentum private key, DFC PIA included additional performance tuning as well as some convenience features like advertising deprecated APIs, IntelliSense support in Visual Studio via robust XML documentation, and HTML Help content with example usage. By virtue of being a strong-named assembly, subsequent versions of the DFC PIA shipped with a publisher policy file and assembly, allowing customers to redirect their DFC PIA 5.2.5 consumers to a newer version of the PIA.

Both Documentum Desktop and Documentum Application Builder announced end-of-life plans around D5.3; so the internal need for DJCB was coming to a close. This opportunity was leveraged to reconsider current platform support for .NET developers and what would be needed in the future (e.g. web services). Several data points arose that suggested the need to reset interoperability as follows:

  • Java and .NET are both managed language platforms. A key management facility in both is known as garbage collection. A garbage collector (GC) is responsible for reclaiming resources based on object reference state and other criteria. The Java GC and the .NET GC don’t recognize each other; yet both GC’s can be resident in the same process space. Given this situation, the potential for resource exhaustion due to improper object reference coding arises. In .NET, all COM objects including objects implementing COM interfaces must be released using Marshal.ReleaseComObject or Marshal.FinalReleaseComObject; otherwise, the underlying resources cannot be reclaimed by a GC.
    • Marshal.ReleaseComObject/Marshal.FinalReleaseComObject is low-level “plumbing” code, and as such is typically not the primary domain concern of the business developer.
    • Recall that the DFC .NET interface is the projection of a DFC COM interface, which is, in turn, a projection of a DFC Java interface. The implementation of this interface projection is shared amongst a Java archive (JAR file), a Java-COM bridge DLL and an in-process assembly (PIA). All of this, again, is low-level plumbing that the business developer would rather not be burdened with; however, appropriate Marshal.ReleaseComObject/Marshal.FinalReleaseComObject calls have been delegated unto them.
  • DJCB (and therefore DFC PIA) is about core DFC, not about DFC customizations via BOF (i.e. type-based or service-based business objects–TBOs or SBOs). So, to get similar .NET interop for a custom business object, you would have to re-apply Java-COM bridge technology to that API–assuming that it’s well-formed for .NET interop–and then produce a PIA for the custom business object using the bridge’s COM type library–all low-level plumbing.
    • “Java-COM bridge + PIA” doesn’t scale as well as web services in terms of integration cost. DFS supports web services natively and was designed from the very beginning with SOA in mind.
  • COM has a hard limit of no more than 255 methods per interface. Most object-oriented systems may not encounter this constraint; however, DFC does with respect to sysobject-derived interfaces. That is, DFC 5.3 was OK; however, DFC 6.0 and thereafter surpassed this upper limit. So DJCB literally cannot be revised to accommodate the DFC 6.0 interface, again due to COM-based limitations. Since DJCB is so-constrained, DFC PIA is also limited.
    • Arguably, this highlights the value of Aspects in DFC/BOF.
    • This also highlights why DFS is absolutely not a web service projection of the DFC API. Rather DFS is a coarser-grained API that is less chatty and less overwhelming to understand (e.g. where total number of API methods is concerned).
    • In other words, DFC 6.0 was not developed with DJCB/PIA exposure, unlike DFC 5.3 and 5.3 service packs.
  • There are aspects of the DFC Java API that are not interoperable. Perhaps the most requested feature request concerns byte stream support. That is, DFC specifies ByteArrayInputStream, but .NET doesn’t recognize this Java type.
    • DFS supports byte streaming use cases as follows:
      1. The application invokes DFS from the middle tier, gets a byte array–DFS doesn’t write to disk–which is then returned by the application to the end user.
      2. The application invokes DFS from the middle tier, gets a URL which is then which is then passed by the application to the end user. The end user can stream the content using the URL.
      3. The application invokes DFS from the middle tier. UCF client is deployed on the end user box. Content is streamed by UCF from the CS machine directly to the end user.
    • Also ByteArrayInputStream can be impractical even for Java-based solutions, since the type puts all data in memory (e.g. large file transfer concerns).

Next: Data access (ADO.NET)…