Today I've found that when BridgeServer works under IIS 6 (on Windows Server 2003), it cannot connect to remote database, even with all changes in machine.config file (as I did for IIS 5 on Windows 2000). I've spent some time to investigate this problem (thanks to Pawel Bojkowski for his persistency and assistance with tests) and I've found the following solution of this problem:

1. Open "Computer Management" tool ("Start/Control Panel/Administrative Tools/Computer Management").
2. Expand "Services and Applications" node.
3. Expand "Internet Information Service (IIS) Manager" node.
4. Right click "Application Pools". 
   • Select "New" menu item.
   • Then select "Application pool..." menu item.
   • Specify Application Pool ID as "BridgeServer".
   • Click "OK".
   • Right click on "BridgeServer" application pool and then select "Properties" menu item.
   • Select "Identity" tab.
   • Change "Application pool identity" to "Configurable".
   • Provide domain user name and password. This user should be member of IIS_WPG group and have enough access rights to the folder where VSS database is stored.
   • Click "OK".
5. Expand "Web Sites" node.
6. Expand "Default Web Site" node.
7. Right click "BridgeServer" web application and then select "Properties" menu item.
   • Change application pool to "BridgeServer".
   • Click "OK".
8. Restart "Default Web Site".

Yesterday I was looking for an information about how to implement impersonation using of ServicedComponents, and accidentally, I've found a very funny and at the same time dramatic story. This is rather realistic story recounts of “cooperation” between two kind of IT specialists: one from mainframe world and another from the world of present-day technologies. Be sure that such type a conversation can take a place in our days. I wish to everybody who works on an edge of technologies (as we do) to escape such lot.

Until May 24, 2004 there were only WSE 2.0 Technology Preview, but from now, the “release version” of WSE 2.0 is accessible. Microsoft eventually has published “release version” of WSE 2.0. The main changes from version 2.0 Technology Preview are:

• The Policy mapping model has changed. There is now a single file that contains both the send and receive mapping. See the documentation for more information.
• Security context tokens can now be issued automatically by a service. The element in the configuration file turns this on. SecurityContextTokens issued by 3rd parties are no longer supported out-of-box and require customized coding.
• Security context tokens can now be issued automatically by a service. The element in the configuration file turns this on.
• The Microsoft.Web.Services2.Security.Signature class has been obsoleted. Use the Microsoft.Web.Services2.Security.MessageSignature class instead.
• The Microsoft.Web.Services.Routing namespace has been removed. The HTTP Router is now supported as Microsoft.Web.Services2.Messaging.SoapHttpRouter
• The interfaces for transports and channels have been reworked.
• Custom transports may be registered in the app.config / web.config files. Existing transports may be removed and/or reconfigured. See the WSE.config file for examples and additional information.
• The Microsoft.Web.Services.Security.SecureConversation namespace has been moved into the Microsoft.Web.Services2.Security namespace.
• The Microsoft.Web.Services.Trust namespace has been moved into the Microsoft.Web.Services2.Security namespace.

• The incorrectly named Microsoft.Web.Services.Security.SaML class has been renamed to Microsoft.Web.Services2.Security.SAML and contains a more complete set of definitions.

Besides they have changed some namespaces, and, as a consequence the fully qualified name of WSE 2.0 assembly also was changed. These changes are very weird for SCCBridge project. Due to this reason the new build of SCCBridge server and SCCBridge client are published today. From now, both server and client sides of SCCBridge project are using of “release version“ of WSE 2.0.

P.S. The best thing in these changes, from my point of view, is an improved documentation that included in “release version” of WSE 2.0.

Sometimes I'm wondering how CLI would looked like, if there wasn't Reflection. I allow that CLI is designed in a way to be dependant on meta information. In the broad sense it's only meta information that assembly contains. It's required for verification process, late compilation, GC, and for other services. But concern of mine is Reflection as part of managed library, which exposes meta information.

Well written application usually avoids using of Reflection classes. In rare cases System.Type class is used, but not more then as a handler that identifies class. This is because of fact that whatever operation or service Reflection classes provide, it can be achieved more easily and in more verifiable and strict fashion at compile time.

CLI extensively exploits technique of attributed programming in very diverse it's parts: VM, and JIT recognize special attributres, managed (and not only) languages often support their attributes, and finally managed libraries define immense number of custom attributes. Attributed programming brings power technique of the "meta programming" into the CLI. In order to expose attributes to managed libraries Reflection is used. Architects of CLI implicitly say that in order to use attributed programming you need to inspect types at runtime, extract all required attributes, and you can do whatever you want with these data. This idea, as if proves that Reflection is just required. The disgraceful climax of this technology in my opinion is achieved in xml serialization library (fx), where a C# code is generated from attributes that describe xml serialization of type, and then this code is compiled and loaded, and all of these occur at runtime! This is in the worst traditions of script languages, indeed.

Well, then how to benefit from attributed programming, but without using Reflection at runtime? Let's inspect how attributes are used either by VM, JIT, or managed library. Usually some data is collected, or some verifications are run, or some code is injected or generated. I'd try to move as most of processing as possible out of scope of runtime. And what is the better place then compilation to do such a work; either early compilation when sources are compiled or late compilation (JIT, which in my opinion works to late now anyway ) when IL instructions are converted in to machine code. What I would add to compilation is ability to generate additional data as a post compilation process. In this way when you would declare new attribute type, you may specify that post compilation operation is to be performed (naturally this means that some method is invoked by the post compilation process for each application of the attribute). This would allow to prepare data, generate or inject code inplace or in satellite assembly. This effectively moves using of meta information out of runtime.

Some time ago I've downloaded the add-in for VSIP 2003 SDK and was surprised. Microsoft eventually has published its MSSCCI interface. Here is a quotation from documentation that I had installed:

The Source Code Control (SCC) SDK provides resources that enable you to add source code version control capability to the Visual Studio .NET 2003 Integrated Development Environment (IDE). It allows you to plug in any SCC DLL that complies with the SCC API outlined in this documentation. The IDE handles the UI for common SCC operations and defers to the SCC plug-in for some advanced source code control features. An SCC plug-in implements functions to perform SCC operations. The SCC SDK documentation includes installation guidelines, a detailed specification of the SCC API, a skeleton sample of an SCC plug-in, and a test guide to verify integration and operation of the SCC DLL.

So, from now, everyone can download VSIP 2003 SDK Extras, read “Source Code Control SDK” topic and then implement this interface (I mean MSSCCI). Hope this will simplify lives a lot of developers.

I've released eventually the next version of SCCBridge project. I've fixed there several bugs and improved a bit the integration module to Visual Studio .NET 2003.

The latest changes are:

• Fix the bug with adding to repository bunch of projects (reported by Tim at 4/12/2004 7:04:41 PM).
• The client-side cache for integration module to VS.NET is implemented. This allows to improve a bit productivity of this module (reported by Mark Rose at 3/26/2004 3:29:10 AM).
• The “Select Project Dialog“ in integration module was fixed.
• From now the integration module supports MSSCCPRJ.SCC files.
• I've implemented some functionality of MSSCCI ver1.2 that also quicken up integration module. 
• I've changed a bit Test() method of web service. From now it requires user name and password and tries to connect using of them. In case of error it shows stack trace that simplifies configuration of the service.
• From now there is an ability to turn off support of RSA encrypting during login.
• There are also some minor changes in web service (e.g. I've implemented IsControlled() web method that allows to quicken up the integration module to VS.NET).

I've investigated also how to access from web service to SourceSafe database placed on LAN. Take a look at my recommendation in “read me.txt“ file in /BridgeServer web folder. I've included also these recommendations to my documentation.

I've separated binary files from sources. You can download the SCCBridge server, SCCBridge client separately. The sources as solution for Visual Studio .NET 2003 are available by e-mail request. From now, three additional sub projects (SCCDiff, SCCGUI and SCCPSwitcher) are including to sources. Also I've included sources of SharpZipLib for consistency.

I'm keep working on improvement of SCCBridge project and will be thankful for any feedback.

Some time ago we have started to study BizTalk Server 2004. It's rather amazing and useful thing for join of business processes especially when rules by which they are joined are changed sometime. But the feature that do the BizTalk Server something peculiar is supporting of long running processes.

We have studied documentation and examples from SDK, have investigated several problems that were discussed in newsgroups,  and visited a conference concerning use of BizTalk Server 2004 sponsored by Microsoft. But we miss a real-life BizTalk project. This situation eventually can be changed.

Today we have found official announce of BizTalk Server 2004 Developer Competition. The rules of this competition you can find here. The cash prizes for winners are worthy tribute.

So, good luck for all pretendents!

From time to time I like to tell, to express (or even to brag about) what keeps our minds busy. Sometimes it's even useful, and you unexpectedly discover, you are on the edge of community interests, other time you are outsider.

So, what are we doing now? Well, already several years we are working in Multiconn. One of goals of our company is to help to expose mainframe functionality. Many different solutions of this task are available, and even Multiconn provides several different approaches. Now go right to our business - web service as delegate of mainframe.

To be honest, I think mainframes are legacy monsters, dinosaurs. I realize, it's only a bad perspective, but the first experience is often very strong. For us as developers mainframe is a source of data in different formats (sure formats are legacy also): COBOL records, terminal messages, and so on. Our idea is to allow to mainframe to rest in peace and to gracefully consume its data. Combining consumed data in xml form and operation bindings that describe mainframe's application flow, we arrive to a view of mainframe application as a web service.

To achieve this goal we have worked up extension to xml schema that allows mapping schema elements to a data. It should be pointed, it's perfectly legal to extend xml schema. One way to extend it, is to use elements in custom namespace in appInfo element.

The following was to create importer of schema with our extensions. It's somehow similar to xsd.exe tool. Our tool generates classes with annotations XmlXxxAttribute for xml serialization and LayoutXxxAttribute (this is our custom attributes) for instance serializing and deserializing to and from a mainframe data.

The next stage was to create data serializer. This is a counterpart to XmlSerializer. It inspects class meta-data and creates plan for serialization and deserialization.

On the next stage we have worked up wsdl schema bindings for our technology.

After that we have created tool to import wsdl (similar to wsdl.exe) that generates web service which passes input messages to communication layer that serializes and forwards data to mainframe, accepts and deserializes response and returns it to the web service, which in its turn returns result to a client.

The next was communication layer that interacts with mainframe. This layer consists of abstract (general) sublayer and specializations which support different patterns of communications.

As result we have web service implemented in .NET. This web service represents some mainframe's application.

There are plans to generate similar web services in the Java.

A half year ago I had started a new project that allows accessing to SourceSafe repository remotely. Than I've changed my mind and I've decided to implement more common interface for version control systems (not only for SourceSafe). The main reason for creating of such kind project was that we had need in access to remote version control system, but all ports was closed by our ISP. There were several opened ports (25, 110 and 80). So, we even couldn't use the CVS. At that time an idea about some bridge that allows accessing to version control system (actually at that moment we have need in SourceSafe) as a web service (via HTTP) was born.

Before creating own system I've investigated the market and have found several more or less acceptable solutions:

• SourceOffsite - of course the best existing at that moment solution, but it also used some specified TCP/IP port, so we were not be able to use it due to the same reason as we were not be able to use CVS. More over, their prices were the highest for such kind of products.
• Than I had found VssConnect - also not a worst solution, but lack of documentation and they did not support (at that moment) some useful SourceSafe functionality. And that is more important they also used some TCP/IP port. :-( By the way, their prices are more reasonable.
• After that I had started to look for a product, which is implemented as web service. And I've found one: VSS.Net. But they also do not provide some SourceSafe functionality: sharing and branching files, retrieving of history, pinning/unpinning files and etc.  And they do not implement integration in VS IDE. The price of their product a bit higher then the previous one, but still acceptable.

When I had studied these solutions, I've decided to create my own solution. And, since for me this was not a main job, but just an opportunity to study something new in practice, so, I've decided to create this solution as a freeware .NET product.

At the 24 November 2003 I've published the first fully functional version that can be integrated into Visual Studio .NET 2003 IDE. So, my task was done, but right now I see a lot of places where I can improve performance of my product, but I have a doubt: do somebody need in this project at all?

Eventually the fashion on the web logs has rolled to us. This is an amazing thing that allows expressing thoughts about something. The thoughts that could be interesting for many people, but for any reason yet not enough to take shape of an article. We think that such modern feature will do our site more interesting and more useful for our visitors.

Sincerely,
Arthur & Vladimir Nesterovsky