This project is read-only.

Classes Missing from 5.5.34.0 Build

Feb 27, 2008 at 7:50 PM
After downloading the files and running the set scripts, I noticed that the following files are missing:

ESBComponent.vb
ESBServicedComponent.vb
ESBConstants.vb

When I open ESB.sln the path points to an 'Include' sub-folder under Main. Is there something missing from the deployment folder? What's the relevance of these classes?

Thanks,
KD
Mar 1, 2008 at 1:00 PM
Hi KD,
They should be there in the 6.x builds.
They're used by the ESB.Adaptors.Application project, which is a base assembly for Services you write (so you don't specifically need to reference that code to write Services, just the ESB.Adaptors.Application.dll).
They do very little other than to expose this bit of code to make it easy to get to the ESB.NET Context:

Public Overridable Function GetContext() As ESB.Core.Interfaces.ServerContext.IServerContext
Dim oServerContext As ESB.Core.Interfaces.ServerContext.IServerContext
oServerContext = CType(CType(ESB.Core.Services.ContextManager.getContextManager(True), ESB.Core.Services.ContextManager).GetExistingContext, ESB.Core.Interfaces.ServerContext.IServerContext)
Return oServerContext
End Function

Having the assembly above means you just call GetContext() when you need to & you're set.

FYI - Just in case you missed it in the Releases, you don't get all the code for ESB.NET. There's some core bits that currently need to be purchased. They come along with support, and are intended for serious corporates more than anything, that would like to guarantee their investment by having all of the source code available to them.
View the ESB.NET License for more details.

Cheers
Minas
Mar 4, 2008 at 5:27 PM
MINAS, thanks for the clarification.

So, the ESB.Adaptors.Application assembly has to be referenced in any custom service I write, which is to be managed by the ESB? Is there a way to wire up my service without a direct reference?

Thanks,
KD

Mar 4, 2008 at 8:43 PM
Hi KD.
In this case you can, as the assembly reference is for pure convenience. Using reflector, you'll see there's very little code in it. However there are a number of other assemblies your service will likely be bound to.
Potentially, you will be referencing many of the assemblies below, so I wouldn't really bother trying to remove the reference to ESB.Adaptors.Application.dll.
The intention is that you expand on it's functionality for your organization.
The Visual Studio project template will add them in to your project. You can remove the ones you don't use (by using the Unused References feature in VStudio.).

==COMMON==
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Adaptors.Application.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.Interfaces.Envelope.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.Interfaces.Logging.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.Interfaces.ProcessMsg.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.Services.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.Util.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Core.XMLSchemaClasses.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\ESB.Product.Version.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\Microsoft.ApplicationBlocks.ConfigurationManagement.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\Microsoft.ApplicationBlocks.ConfigurationManagement.Interfaces.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\Microsoft.ApplicationBlocks.Data.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\Microsoft.ApplicationBlocks.ExceptionManagement.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\Microsoft.ApplicationBlocks.ExceptionManagement.Interfaces.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Common\PowerCollections.dll

==Service specific==
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Adaptors\ESB.Adaptors.Application.Workflow.Activities.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Adaptors\ESB.Adaptors.Application.Workflow.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Adaptors\ESB.Core.Interfaces.ServerContext.dll

==Advanced==
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Advanced\ESB.Core.Pipeline.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Advanced\ESB.Core.Services.Server.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Advanced\ESB.Core.XMLSchemaClasses.Management.dll
C:\ESB\Dev\Source\ESB\Base\Solutions\Main\SDK\Bin\Advanced\Mvp.Xml.dll


Cheers
Minas
Mar 6, 2008 at 4:50 PM
Minas,

We are primarily an Oracle database shop. How difficult would it be to subplant SQL Server with Oracle? Would is just be a matter of creating the same table structures, modifying configuration files and adding an Oracle system entry point or is there more to it? From a logging perspective, I suppose we could use MSMQ logging and write services that post updates to an Oracle database.

Thanks,
KD
Mar 6, 2008 at 9:13 PM
Hi KD. That's all correct.
There are a couple of places where SQL is used, and both to the same set of logging tables.
The
\Base\Solutions\Main\Logging\ESB.Core.Loggers\
writes to the ESBLogDetail table.
The
SQL SystemEntryPoint
writes to the ESBLogHeader table.

The ESB.Core.Loggers and SystemEntryPoint are both decoupled, so you can easily roll your own implementation.
Change the
Base\Solutions\Main\Configuration\XMLConfigFiles\ESB.Core.Services.Server.Wcf.config
config file for the SystemEntryPoint.

Change the
Base\Solutions\Main\Configuration\XMLConfigFiles\ESB.Core.Services.Server.Wcf.config
for the Logger.

As you said, you can listen off the MSMQ log (although you'd then have to parse the XML contents again - unless you're writing straight XML into oracle).

It should be a relatively trivial exercise.
Let me know if you have any problems.
If you like, you can also add the fruits of your work to this site :).

Cheers
Minas
Mar 7, 2008 at 8:10 PM
Thanks for your update on swapping out the backend.

I may be missing something in your documentation, but once I get my service wired up to ESB.NET, how does a client application communicate with the ESB to invoke my service? For example, if my client app originally called an ASMX service to request data, would the app simply submit an HTTP request to ESB using the same namespace?

Thanks,
KD
Mar 7, 2008 at 9:25 PM
Edited Mar 7, 2008 at 9:27 PM
KD,

There are 3 types of external facing transports available with ESB.NET at this point. HTTP, WSE3 and WCF.

You can see the endpoints by using the ESB Management Console & flicking between the transports.
# select the "Testing\Functionality\Generic Request Sender" item from the tree
# login as uid="admin" pwd="admin"
# select the URL and Transports TAB
# select the different radio buttons to switch transports (& for WCF, the relevant Profiles WCF Endpoint Configurations etc.)
## Also, the WCF Transport has a number of profiles you can setup.

Being standards based, yes, you can do the following:

  • For the HTTP Transport, yes, you can simply do a HTTP POST of the payload
  • For the WCF Endpoint, you can do a HTTP POST, however it's not recommended as there is the SOAP Envelope, as well as Reliable Messaging, Secured Messages etc. for which WCF is the best way to communicate.

ESB.NET Client

The above methods, though are not the recommended ways for communicating with ESB.NET.
If you look at the code behind the ESB Management Console, you will see a class called the
ESB.NET RequestHandlerProxy
This is the most powerful way to talk to ESB.NET.

All of the ESB Management Console features for sending requests to the ESB.NET server are exposed via this component.
It supports the multiple transports (HTTP, WSE, WCF etc.), and related configuration for default transports etc.
The best place for sample code on how to call it is in the "ESB Management Console's" KD,

There are a 3 of transports at this point. HTTP, WSE3 and WCF.

You can see the endpoints by using the ESB Management Console & flicking between the transports.
## select the "Testing\Functionality\Generic Request Sender" item from the tree
## login as uid="admin" pwd="admin"
## select the URL and Transports TAB
## select the different radio buttons to switch transports (& for WCF, the relevant Profiles WCF Endpoint Configurations etc.)

Being standards based, yes, you can do the following:

  • For the HTTP Transport, yes, you can simply do a HTTP POST of the payload
  • For the WCF Endpoint, you can do a HTTP POST, however it's not recommended as there is the SOAP Envelope, as well as Reliable Messaging, Secured Messages etc. for which WCF is the best way to communicate.

ESB.NET Client

The above methods, though are not the recommended ways for communicating with ESB.NET.
If you look at the code behind the ESB Management Console, you will see a class called the
ESB.NET RequestHandlerProxy
This is the most powerful way to talk to ESB.NET.

All of the ESB Management Console features for sending requests to the ESB.NET server are exposed via this component.
It supports the multiple transports (HTTP, WSE, WCF etc.), and related configuration for default transports etc.
The best place for sample code on how to call it is in the "ESB Management Console's" KD,

There are a 3 of transports at this point. HTTP, WSE3 and WCF.

You can see the endpoints by using the ESB Management Console & flicking between the transports.
## select the "Testing\Functionality\Generic Request Sender" item from the tree
## login as uid="admin" pwd="admin"
## select the URL and Transports TAB
## select the different radio buttons to switch transports (& for WCF, the relevant Profiles WCF Endpoint Configurations etc.)

Being standards based, yes, you can do the following:

  • For the HTTP Transport, yes, you can simply do a HTTP POST of the payload
  • For the WCF Endpoint, you can do a HTTP POST, however it's not recommended as there is the SOAP Envelope, as well as Reliable Messaging, Secured Messages etc. for which WCF is the best way to communicate.

ESB.NET Client

The above methods, though are not the recommended ways for communicating with ESB.NET.
If you look at the code behind the ESB Management Console, you will see a class called the
ESB.NET RequestHandlerProxy
This is the most powerful way to talk to ESB.NET.

All of the ESB Management Console features for sending requests to the ESB.NET server are exposed via this component.
It supports the multiple transports (HTTP, WSE, WCF etc.), and related configuration for default transports etc.
The best place for sample code on how to call it is in the "ESB Management Console's" "Testing\Functionality\Generic Request Sender" page.

HTH
Cheers
Minas