Today we had spent some time looking for samples of web-services in RPC/encoded style, and we have found a great site http://www.xmethods.com/. This site contains a lot of web-services samples in Document/literal and RPC/encoded styles. We think this link will be useful for both developers and testers.

Actually this build is used WSE 2.0 SP3 and contains minor bug fixes. All the sources published on GotDotNet site (SCCBridge workspace). Pay attention that for now the sources include SCCProvider project that is MSSCCI implementation. I've decided to publish this project since Microsoft freely publish their interface and documentation for all VSIP.

As I wrote early in our blog, the latest version SCCBridge allows accessing to SCCBridge server via proxy. Here is some explanation what you should do in order to establish such connection:

1) open RepositoryExplorer;
2) click “Settings” button;
3) set “Default service URL” property to “http://proxy:1234/BridgeServer/Repository.asmx” ;
4) set “Endpoint URL” to “http://serverhost/BridgeServer/Repository.asmx”;
5) click “OK”.

Now you can do login.

P.S. Pay attention that “serverhost” is a host name used by proxy to route requests to.

Yesterday we had ran into following problem: how to retrieve session object from within Java web-service? The crucial point of the problem was that we are generating automatically our web-service from Java bean and this web-service works under WebSphere v5.1.1.

After some time we had spent to find acceptable solution, we have found that it's possible either to implement “session substitution” using EJB SessionBean or somehow to retrieve HttpSession instance.

The first approach has a lot of advantages before the second one, but it requires to implement bunch of EJB objects (session bean itself, home object etc.). The second approach just solve our problem for web-service via HTTP, and no more, but... it requires only few lines to be changed in Java bean code. This second approach is based on implementation of javax.xml.rpc.server.ServiceLifecyle interface for our Java bean. For details take a look at the following article: “Web services programming tips and tricks: Build stateful sessions in JAX-RPC applications“.

Actually, only two additional methods init() and destroy() were implemented. The init() method retrieves (during initialization) an ServletEndpointContext instance that is stored somewhere in private filed of the bean. Further the ServletEndpointContext.getHttpSession() is called in order to get HttpSession. So easy, so quickly - we just was pleased.

In the class definition you often read:

Thread Safety

Any public static (Shared in Visual Basic) members of this type are safe for multithreaded operations. Any instance members are not guaranteed to be thread safe.

But do not be very susceptible for these assurances. Sometimes you read this, because of help template had this text.

Let's look at Encoding::GetEncoding static method:

public static Encoding GetEncoding(string name)
{
  return Encoding.GetEncoding(EncodingTable.GetCodePageFromName(name));
}

and

You see now, in the least successful case, when our encoding isn't still cached, we shall cache it in the EncodingTable.hashByName.

I just want to point out that hashtable write operation isn't thread safe.

Eventually the SCCBridge project became really open source project. From now its sources (version 1.1.0.0) are accessible from GotDotNet site. Releases, documentation and some interesting things about the project you still can find here. Welcome to all developers who want to participate in advancing of this project.

Today the next version of SCCBridge server and client were published. Feel free to download them from our download page.

What's new in this version:

• The access to Source Safe database is implemented using COM+ object. This approach allows to avoid problems with access to VSS database on the LAN and simplify configuration.
• The more intelligent List command is implemented. It can retrieve list of files/folders without checking whether files are pinned. This accelerates the list retrieving up to 2-3 times. 
• The folders tree caching in Repository Explorer is implemented.
• The caching of files/folders info in source code control provider for Visual Studio .NET 2003 IDE is improved.
• Source code control provider for IDE now doesn't require user's credentials for each project in the solution.
• Source code control provider can open now solutions created with Source Safe.
• Fix: checkout during file editing in Repository Explorer.
• History dialog allows to determine either a specified or whole history period to get history data.
• Repository Explorer and source code control provider support the same configuration file now.
• FileSystemBridge is removed from the installation.
• Some security improvement is implemented:
  • From now the SCCBridge client supports Windows Integrated and Basic authentication.
  • The ability to use IE non-dynamic proxy settings is implemented.
  • The endpoint URL is now implemented. This allows to use web service behind the routers and/or firewalls.
  • The SCCBridge client encrypts VSS user name, password and database before send them to the web service.
  • The user doesn't see projects when he doesn't have any right on it. The users' rights on projects can be determined by VSS Admin utility.

P.S. Comments and suggestions are welcome.

Yesterday I've came across an interesting article that compares different version control systems like CVS, SourceSafe and several others. Some information in this article is not correct, but anyway it's close to true. So, it will be very useful to study this comparison, if you are going to select a version control system to work with it.

Also, some time ago, I've found page, which describes third party products for Visual SourceSafe. This is an interesting collection of links to third party SourceSafe managers, GUI, scripts, remote control systems, add-ins and so on. Take a look at this collection...

We just have seen the BizTalk competition results. We are out of the game. :(
Our congratulations to the BTS 2004 Developer Competition winners:

1. Paul Somers of London, England; BizTalk Server Management Tool entry
2. Jesus Rodriguez; BizTalk Server UDDI Publishing Wizard
3. Scott Colestock of Champlin, Minnesota; BizTalk Server 2004 Nant deployment
4. Pallavi Narayanaswamy of Bangalore, India; BizTalk TIBCO adapter
5. Darrin Weber of Allentown, Pennsylvania; Scheduled Orchestration execution

For more details about winners and participants see Scott Woodgate's blog...

Anyway, in course this competition we have created the first freeware MQSeries adapter for BizTalk Server 2004 and have designed a way to integrate legacy applications into BizTalk orchestrations without HIS 2000.

Recently we have sent our entry to BizTalk Server 2004 Developer Competition.
Let's see how it will go.

The entry integrates mainframe's COBOL applications with BizTalk Server 2004. It includes following elements:

• MQ adapter, which supports both MQSeries server and client, and implements receive, send, solicit-response and request-response communication patterns.
• Pipeline components that do run-time data transformations and support CICS DPL conversation protocol.
• Design-time tools to generate annotated XML schemas and C# sources from COBOL copybooks. The assemblies generated from these sources are used by CICS DPL pipeline components at run-time to transform XML to and from CICS DPL raw data messages.

The entry provides pure .NET solution for consuming legacy applications from BizTalk Server 2004 without using of Host Integration Server 2000 at run-time. It includes documentation, executable files and sources of the adapter, pipeline components, and examples that demonstrate their capabilities. Feel free to download it from GotDotNet web site: http://workspaces.gotdotnet.com/MulticonnBizTalkExtensibility

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.