ESB.NET in C# ?

Aug 1, 2007 at 4:44 AM
Hi,

I'm very interrested in your ESB project, it's a very good alternative to a biztalk implementation ESB.
But when i've downloaded the source, i was badly suprized that you used VB.

Do you hvae some plan to make a C# version.

Regards,

Alex
Coordinator
Aug 1, 2007 at 10:46 AM
I'm very interrested in your ESB project, it's a very good alternative to a biztalk implementation ESB.
==>Thanks.
But when i've downloaded the source, i was badly suprized that you used VB.
==>Sorry. VB.NET is really not bad though.

Whilst the majority of ESB.NET is VB.NET code, there are a few C# projects in the codebase. This is mainly because the original source was in C#, and there's pretty much no point in converting it to VB.NET.
Do you hvae some plan to make a C# version
==>Similarly, I have no plans to port over the codebase to C#. It's a pointless exercise. Any time spent would be better spent increasing functionality, training material, tutorials and documentation etc.

A little history then...
My background is C++ and a little VB6. Once .NET came out, I looked at C++, C# and VB.NET. I found VB.NET to be the most productive for me at that time, so I went forth with it. I still find it to be more productive for me, so I continue to use it.
If I find this changes, I'll change what I use from that point on. In the mean time, it's VB.NET for me. If anyone builds suitable functionality in C#, then I'd take it on no probz (as long as it works!).

Cheers
Aug 1, 2007 at 4:50 PM
Thanks for the answer. I just wanted to have the same programing language tham in my other project.

I have a little request do you have a graph or a shema to illustrate how ESB.NET Works.
I'm really interested in WF for orchestration and i wanted to know where it's executed.

Well basicly I need a shema to illustrate the place of the new Microsoft technology WCF and WF. I think you should put this in headlines because the other ESB implementation with Biztalk just use a bit WCF and no WF.

Regards,

Alex
Coordinator
Aug 2, 2007 at 4:28 PM
I have a little request do you have a graph or a shema to illustrate how ESB.NET Works.
I'm really interested in WF for orchestration and i wanted to know where it's executed.
==>I have loads of sequence, class and activity diagrams that I need to sanitize before releasing. There's also loads of architectural doco, some half baked...
Some of them are old and don't exactly apply, others are scribbles on paper...
Anyway, there's so much content, that I will cover the basics in the Getting Started Guide.

In the mean time, my blog at
http://keystroke.com.au/MINAsBlog/tabid/59/Default.aspx
is probably another good general ESB.NET resource.

I'll try to get something high level in there for the next build, or the one after that. I understand it's very important (well it is to me, and I'm glad I'm not the only interested party...:) ).
Just to start you off though, the Sequential Workflows are executed via an ESB.NET Plug-in ==> The Sequential Workflow Adaptor.
The Sequential Workflow Adaptor kicks in when it is either configured in the Service Pipeline configuration file, or executed via the Convention Over Configuration Adaptor (another plug-in/filter) when it detects a Service Handler is a Sequential Workflow Type.
In any case, the Sequential Workflow Adaptor is somehow (directly or indirectly) called by the PipelineManager and passed some info as to what Service to invoke. It then invokes that service (sequential workflow - which needs to derive from a related ESB.NET Sequential Workflow Base class - ESB.Adaptors.Application.Workflow.Activities.EsbWorkflowServiceBase in order to setup the ESB.NET Context and get all the logging correlated etc.) passing it the request envelope and returns the response envelope etc...

Similarly, the State Based Workflow Adaptor (currently non-existent other than one from an early beta in about November 2005!) will also be delivered in the same manner.
This illustrates some key features and concepts that are found throughout the ESB.NET application architecture and that are in line with the Lightweight Distributed ESB nature.
1)It illustrates how "pluggable" ESB.NET is. There's still lots of areas I want to make more pluggable, however it's currently a scheduling priority issue for me. Too many things to do, and not enough time!!! Some of those areas are part-way there. They were always designed to be that way, but something held me back - time, technical issues at the time etc.
2)Allows you to provide a "better" implementation if you don't like it.
3)Allows you to "remove" or not deploy components you do not want to ship in particular instances. Granted, this starts to get a little complicated, and I currently don't have anything to help in that respect. For the most part, it's lightweight enough to just
copy & paste the whole directory and run "SetupInstance.cmd" etc. You can then experiment to strip it down all you like. It's not really hard though - I just need to document it more, and provide some examples/scenarios...
This helps to keep it light.


I think you should put this in headlines because the other ESB implementation with Biztalk just use a bit WCF and no WF.
==> Hehe, yeah, maybe I should...

Regards,

Alex
{quote}