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