Kevin Conner and the JBoss ESB Team announced  the next project release of ESB 4.7.

There are many updates to the codebase, including a number of major additions.  The most notable of these are:

• the inclusion of a UDDI 3 registry through the Apache jUDDI project,
• implementation of a new, servlet based, HTTP gateway
• support for SAML tokens
• XPath based routing
• regexp based routing
• an eventing mechanism to monitor the server.

you can download the JBoss ESB release here.

If you are using the JBoss ESB for the first time I recommend to have a look at the quickstarts, they are located under samples/quickstarts/ directory in the distribution. You will save a lot of time as these examples are implementations of the well known Enterprise Integration Patterns and it is very easy to build on top of them.

The JBoss Tools folks created some eclipse plugins that will help you create, debug and deploy these services on the ESB. You can access those here.

If you have already been using JBoss ESB and want to experiment with new features and improvements of 4.7 then I recommend David Ward’s blog entry: Proxying SOAP Web Services in JBossESB 4.7

Have Fun!

While watching the excellent Frontline last night I was reminded of a conversation I had once with a security guard in the A&E department of the Mater Hospital. He reckoned if there was a natural disaster in Dublin, a terrorist attack, a plane crash or a disaster like Hillsborough well then they may as well bolt the doors of A&E closed as they haven’t the capacity, or the plans in place, to deal with anything like that. They barely get through a normal week and every Saturday night is a warzone anyway.

The reason I was reminded of that conversation is this. On The Frontline last night it became very clear that there was no semblance of a masterplan to deal with the flooding we’ve seen hit the land in the past week. And no one will take any responsibility for the lack of foresight and the even greater lack of a plan to cope with it once it had happened. The ESB blame someone else. Likewise the Dept of the Environment. As do the IFA. No one has the balls to say we fucked up, let’s deal with it and make sure it doesn’t happen again. And it’s hugely disconcerting because it’s the same for everything that has gone wrong in recent times in Irish society. From the banks to the church but most of all our political leaders. Nobody has a plan. Nobody’s in charge. The country is crumbling and nobody has the strength of character or vision to step up and say I know where we’ve been and I know where we’re going.

Today the new-fangled Lisbon Treaty came into force, redefining the future of the European Union. And it can’t come a day too soon because here in Ireland we’re clearly not capable of governing ourselves. We need a plan. And I can only hope Europe can provide it because under the stewardship of Brian Cowen, Mary Coughlan et al (oh and not forgetting our merry band of unions) we’re sinking fast.

One beneficial aspect of the floods is that there is lots of water for kayakists. Here are some pics taken at Curragour, on the Shannon in Limerick city, on 28 November 2009.

Here are some photos taken along the banks of the Shannon in Limerick at low tide on the morning of Saturday 28 November 2009. They show Sarsfield Lock, the weir, the Custom House moorings, Curraghgour Boat Club, King John’s Castle, St Mary’s Cathedral, the Courthouse, Mathew Bridge, the Abbey River and the entrance to the canal harbour.

Here are photos showing the effects of the flooding in the village of Castleconnell.

Note that, despite what RTE radio and the AA have been saying, you can get to the Castle Oaks House Hotel, and to Stradbally and Stradbally North, along the “back road” from the N7 near Finnegan’s Roundabout. The AA and RTE have been saying that the only way in to Castleconnell is from Daly’s Cross but that is misleading: the road is blocked at the bottom of Chapel Hill, at the Ferry carpark. So you can’t get to Stradbally or the Castle Oaks from Daly’s Cross and you can’t get to the centre of the village from the Stradbally side.

The side-roads from the N7 to the back road near Herbert’s pub and via Belmont hill and road are both flooded.

The R525 from Daly’s Cross to Montpelier and O’Briensbridge is blocked by flooding under the railway bridge. However, the R466 from Birdhill to Montpelier and O’Briensbridge is open.

Please do not drive through flood waters if there are houses or other buildings nearby: your wash drives water against walls and doors that are, in some cases, mere inches above the water level. And it’s even worse if the water is contaminated with sewage, as it may be here.

Here are some photos of the riverside walk from the Castle Oaks House Hotel to the Ferry carpark.

Note that, despite what RTE radio and the AA have been saying, you can get to the Castle Oaks House Hotel, and to Stradbally and Stradbally North, along the “back road” from the N7 near Finnegan’s Roundabout. The AA and RTE have been saying that the only way in to Castleconnell is from Daly’s Cross but that is misleading: the road is blocked at the bottom of Chapel Hill, at the Ferry carpark. So you can’t get to Stradbally or the Castle Oaks from Daly’s Cross and you can’t get to the centre of the village from the Stradbally side.

The side-roads from the N7 to the back road near Herbert’s pub and via Belmont hill and road are both flooded.

The R525 from Daly’s Cross to Montpelier and O’Briensbridge is blocked by flooding under the railway bridge. However, the R466 from Birdhill to Montpelier and O’Briensbridge is open.

Some pics from Parteen Villa Weir, O’Briensbridge, Montpelier, Castleconnell, Annacotty and Plassey here.

Statement from ESB regarding River Shannon as at 9:20am, Thursday 26th November 2009

Water levels rose again last night in Lough Derg and are at a record high. As a result, discharge levels must be increased today at Parteen Weir. ESB will be increasing the discharge incrementally over the morning by up to 8% on the existing flow. The development is expected to cause increased flood levels downstream of Parteen Weir by an estimated three inches over the current level. A slight fall in water levels was detected downstream this morning in a number of locations. [...]

Some photos here of Dromineer, Garrykennedy, Killaloe, Parteen Villa Weir, O’Briensbridge and Castleconnell.

Here is a page covering the effect of the floods of November 2009 on the old Limerick Navigation from Plassey downstream. (This page complements another about the upper reaches of the navigation.)

This page covers:

• Plassey, including the Black Bridge and the towing-path
• the regulating weir at Corbally
• the upper lock on the Park Canal, the lady’s hole and the 2.4m increase in depth above the lock
• the lower lock and its patented mechanism
• the current in the Abbey River and under Mathew Bridge.

Here is a page about the upper end of the old Limerick Navigation, with photos of the Ardnacrusha headrace, Castleconnell and its weir and quay, O’Briensbridge, Errina bridge and Doonass. There are photos taken over the last few days and older photos, showing normal (post-Ardnacrusha) levels at the same locations. The recent photos do at least give a hint of the levels that the pre-Ardnacrusha waterway coped with.

At time of writing, the ESB says it is going to release more water down the river to O’Briensbridge, Castleconnell and Limerick.

Photos of the lower stretches (Plassey, Corbally, the canal harbour and the Abbey River) will be posted later (floods permitting).

Photos of Killaloe in flood are now up. They were taken on the morning of 22 November 2009.

We recently announced roadmap for BizTalk Server. You can watch the session here:

http://microsoftpdc.com/Sessions/SVR15

There was also a session on ESB Toolkit 2.0. You can watch it here

http://microsoftpdc.com/Sessions/SVR16

Actualmente estamo utilizando un bus de information builders (iway)
Es una herramienta poco explorada por estos lares

En cuanto tenga mas detalles le pasare la memoria técnica

Expongo a continuación las ideas principales obtenidas en la lectura del artículo “Is ESB mandatory for SOBA?” creado por Hariharan Vimala, a senior SOA architect.

Desde la aparición de SOA, muchas organizaciones han realizado serias inversiones para obtener resultados satisfactorios desarrollando y/o aplicando soluciones SOA. Muchas de ellas en cambio, después de despilfarrar grandes cantidades de dinero, no han obtenido ningún valor añadido o el poco logrado no ha sido el esperado.

Many small and medium enterprises started developing web business systems based on Service Oriented Architecture. Since SOA propaganda has created enormous impact across industries many enterprises started evaluating SOA approach.

El uso de un ESB en una solución SOA o SOBA, es un tema bastante discutido.  Una parte apuesta por la %100 inclusión del ESB pero la otra parte no la ve tan clara. En mi caso, soy partidario de utilizar un ESB pero antes se debe estudiar y analizar que puede aportar (para qué se quiere utilizar) este en la aplicación.

Especially enterprise service bus (ESB) architecture tools have excellent appreciation since it helps to build services without much effort. But it has also created a wrong impression in the field that any service requirement can be build using ESB. I personally feel that ESB is not for all service development.

So, for service oriented business application requires ESB only if it requires to wrap the existing legacy and packaged applications. Building web application with service components is a good approach until unless you are building with business processes. BPM can play a major role in web architecture if the application scope includes business processes. Using ESB and BPM for simple web application does not add any value or benefit to the enterprise. SOA and BPM will provide enormous support and benefits if deployed at enterprise level.

Recordando el título del post, ¿crees que es necesario el uso de un ESB en un solución SOA o SOBA?

Artículo completo: http://it.toolbox.com/blogs/soa-governance/is-esb-mandatory-for-soba-35303?rss=1

I have uploaded the code samples I used in “ESB Toolkit to MSMQ Post” to

http://cid-029243050862a734.skydrive.live.com/self.aspx/.Public/CodeSamples/ESBToolkitToMSMQ/Microsoft.Practices.ESB.Adapter.MSMQ.zip

Introduction

The BizTalk ESB Toolkit 2.0 is a collection of tools and libraries that extend BizTalk Server 2009 capabilities of supporting a loosely coupled and dynamic messaging architecture. You can learn more about ESB Toolkit 2.0 at http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx. This article will show you how you can use ESB Toolkit to communicate with MSMQ.

ESB Toolkit uses dynamic send ports called Off Ramps to send messages to various BizTalk adapters. It relies on .Net components called Resolvers and Adapter Providers.

Resolvers

For runtime flexibility ESB Services are not hard-coded to specific endpoints or maps. This metadata is determined at runtime. Resolvers can locate and retrieve this metadata. Itineraries define which ESB services execute and in which order. Resolvers define how ESB Services execute. List of Resolvers included in ESB Toolkit 2.0 are shown below.

Adapter Providers

Information retrieved by a Resolver is stored in a .Net based Dictionary object. BizTalk isn’t built to work with Dictionary objects.  Adapter provider act as a bridge between .Net based ESB components and the BizTalk based components. Here is a list of adapter providers that are included in ESB Toolkit 2.0.

As you can see from the above list MSMQ Adapter provider is not included in ESB Toolkit. This is where WCF-Custom adapter provider comes in handy. WCF-Custom adapter is able to invoke any WCF binding. WCF includes netMsmqBinding which can be used to send messages to MSMQ.

Itinerary

Any message that is sent to the BizTalk Server goes through a series of steps before its processing is complete. In messaging only scenarios a BizTalk receive location might pick up a message and send it to the MessageBox. One or more Send Ports might be subscribed to this message so they will get this message and send it to the destination system. In case of an Orchestration the message will be subscribed by an Orchestration where it may be decomposed, transformed and sent to one of more system. All this can be easily accomplished by BizTalk without ESB Toolkit. However Itineraries provide the runtime flexibility that BizTalk does not have by default. They also provide more flexible Service Composition. Itineraries are designed in the Itinerary designer in Visual Studio. The designer allows you do to design time validation of the itinerary. When the design activity is complete the Itinerary is exported to an Itinerary Repository.

Sending messages to non Transactional MSMQ using WCF-Custom Adapter Provider

1. Create a private MSMQ queue called test
2. Start Visual Studio 2008 and create a new project of type Class Library.
3. Add a new Itinerary to this project.
4. Set the name of the Itinerary to wcfmsmq
5. Select the Model Exporter to have a value “Database Itinerary Export”. This will enable export of the itinerary to database.
6. Set the Itinerary Status to “Deployed”. This is similar to a business rules engine policy deployment where a policy can be in published or deployed status.
7. Set the Export Mode to “Strict”. This mode captures more details about the itinerary and should be used for any new itinerary. The other mode is called “default” and it is there for backward compatibility with ESB Guidance 1.0 Itineraries.
8. Set the Encryption Certificate Property if you want to encrypt your itinerary. If you want to disable encryption you can see the instructions here (http://blogs.msdn.com/pkelcey/archive/2009/06/08/disabling-itinerary-encryption-in-the-esb-toolkit-2-0.aspx).
9. Other values in the properties windows can be left unchanged.
10. Drag On-Ramp to the design surface.
    1. Update the name property of the OnRamp.
    2. Select “On-Ramp ESB Extender” as the value of Extender
    3. Set the value of BizTalk Application to “Microsoft.Practices.ESB”. This value should be set to the application where OnRamp exists. In this example we are going to use an OnRamp that exists in “Microsoft.Practices.ESB” application.
    4. Select “OnRamp.Itinerary” receive port as the value of Receive Port. This port is a one way receive port.

1. Drag Itinerary Service to the design surface.
   1. Set the name of this service to “RoutingService”
   2. Set the value of Itinerary Service Extender to “Messaging Extender”. This instructs ESB Toolkit to execute this setup in a pipeline.
   3. Set the value of Service Name to be “Microsoft.Practices.ESB.Services.Routing”. This service is a part of the ESB Toolkit. You can create your own messaging services and register them in ESB.Config and they will become available to you in Visual Studio Itinerary Designer.
   4. Set the Container to “OnRamp1->ReceivePort”. This instructs ESB Toolkit to execute the routing service in  the pipeline for the Receive Port.
   5. Tracking Enabled property determine if steps of the itinerary will be tracked in BAM.
   6. Right click on the service and add a new Resolver.

1. Set the name of the resolver to “MsmqTest”
2. Set the value of Resolver Implementation to “STATIC”. This implies that we will hard code the settings in the itinerary
3. Set the Transport Name to “WCF-Custom”
4. Set the Transport Location to “net.msmq://localhost/private/test”. This tells the WCF Custom adapter to use netMsmqBinding of WCF to send message to MSMQ
5. Set the value of Action to any string. This value is not used in case but its value still needs to be set.
6. Press the … button for Endpoint Configuration to bring up the configuration dialog box.

                                                               i.      Set the BindingType to be “netMsmqBinding”

                                                             ii.      Set the BindingConfiguration to <binding durable=”false” exactlyOnce=”false”><security mode=”None” /></binding>

This setting implies that MSMQ message will be not be transactional or recoverable.  

1. Right click on the design surface and select “Validate”
2. If there are no errors you should right click and select “Export” Model
3. If there are no errors you can use test application C:ProjectsMicrosoft.Practices.ESBSourceSamplesItinerarySourceESB.Itinerary.TestbinDebugESB.Itinerary.Test.exe
   1. Set the Itinerary Name to be “wcfmsmq”
   2. Set the Version to 1.0
   3. Select the appropriate file in the Load Message section
   4. Press the “Submit Request”
   5. Verify that MSMQ message was written to the Test Queue.

Sending messages to Transactional MSMQ using WCF-Custom Adapter Provider

Most of the steps required to accomplish this task are similar to the steps in the previous section.

The only differences are:

1. Create a new private Transaction MSMQ Queue called “trantest”
2. When you create a  new resolver it should be named “MsmqTranTest”
3. Transport Location should be “net.msmq://localhost/private/trantest”
4. Binding Configuration should be set to

<binding durable=”true” exactlyOnce=”true”><security mode=”None” /></binding>

Creating Custom Adapter Provider for MSMQ

We can easily extend ESB Toolkit to create a Custom Adapter Provider for MSMQ. The only requirement for this is that the adapter which you are invoking has to support dynamic behavior.

1. Create a new Class Library project in Visual Studio called “Microsoft.Practices.ESB.Adapter.MSMQ”
2. Set a reference to C:Program FilesMicrosoft BizTalk ESB Toolkit 2.0BinMicrosoft.Practices.ESB.Adapter.dll
3. Add a strong name key to this project.
4. Add a new class called “AdapterProvider”

5.  Add a statement using Microsoft.Practices.ESB.Adapter;

1. Inherit the AdapterProvider class from BaseAdapterProvider class.
2. Override the properties AdapterName andAdapterContextPropertyNamespace as shown below.

1. Add a new XML file to the project called MSMQPropertyManifest.xml. This file has to be named in AdapterNamePropertyManifest.xml format. This file contains all the MSMQ Adapter schema properties(http://technet.microsoft.com/en-us/library/aa577593(BTS.10).aspx ). These are the properties that are used by BizTalk to send a message to MSMQ. Partial list of these properties is shown below.
2. Build the class library and add it to Global Assembly Cache.
3. Copy the file MSMQPropertyManifest.xml to C:Program FilesMicrosoft BizTalk ESB Toolkit 2.0ToolsItinerary Designer
4. Register the adapter provider in esb.config file by adding the line to the section where other adapter providers have been registered.

     <adapterProvider moniker=”MSMQ” adapterAssembly=”Microsoft.BizTalk.Adapter.MSMQ.MsmqAdapterProperties, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

Here the name is the name of the adapter, Type is the .Net type of custom adapter provider you just created, moniker is Transport Name in the Resolver configuration and adapter assembly is the BizTalk assembly that contains all the context properties related to the MSMQ Adapter.

Testing MSMQ Adapter Provider

Most of the steps required to accomplish this task are similar to the steps in the previous sectiosn.

Non Transactional Queue

The only differences are:

1. Name of the Itinerary should be ExpressMsmq.
2. After creating Itinerary Service called RoutingService, you need to add a new Resolver.
3. Resolver Implementation is still STATIC.
4. If your MSMQ Adapter provider registered correctly you should be able to select “MSMQ” as the Transport Name.
5. Set Transport Location to FORMATNAME:DIRECT=OS:ESBWIN2008PRIVATE$TEST
6. You can once again use C:ProjectsMicrosoft.Practices.ESBSourceSamplesItinerarySourceESB.Itinerary.TestbinDebugESB.Itinerary.Test.exe to test this itinerary.

Transactional Queue

The only differences are:

1. Name of the Itinerary should be TranMsmq.
2. After creating Itinerary Service called RoutingService, you need to add a new Resolver.
3. Resolver Implementation is still STATIC.
4. If your MSMQ Adapter provider registered correctly you should be able to select “MSMQ” as the Transport Name.
5. Set Transport Location to FORMATNAME:DIRECT=OS:ESBWIN2008PRIVATE$TRANTEST
6. Press the … button for Endpoint Configuration to bring up the configuration dialog box and change the value of Transactional Property to True.
7. You can once again use C:ProjectsMicrosoft.Practices.ESBSourceSamplesItinerarySourceESB.Itinerary.TestbinDebugESB.Itinerary.Test.exe to test this itinerary.

Conclusion

ESB Toolkit provides Adapter Providers to allow you to communicate with various BizTalk adapters. WCF-Custom adapter offers a lot of flexibility because it can use any WCF binding. For example WCF-Custom can be used to communicate with any of the WCF based adapters that are included in BizTalk Adapter Pack 2.0. When the existing Adapter Providers don’t meet your need you can easily extend ESB Toolkit to create new Adapter Providers. You can download code samples used in this article from my blog at http://rajsinghblog.wordpress.com

Sending Messages from ESB Toolkit to MSMQ

Introduction

The BizTalk ESB Toolkit 2.0 is a collection of tools and libraries that extend BizTalk Server 2009 capabilities of supporting a loosely coupled and dynamic messaging architecture. You can learn more about ESB Toolkit 2.0 at http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx. This article will show you how you can use ESB Toolkit to communicate with MSMQ.

ESB Toolkit uses dynamic send ports called Off Ramps to send messages to various BizTalk adapters. It relies on .Net components called Resolvers and Adapter Providers.

Resolvers

For runtime flexibility ESB Services are not hard-coded to specific endpoints or maps. This metadata is determined at runtime. Resolvers can locate and retrieve this metadata. Itineraries define which ESB services execute and in which order. Resolvers define how ESB Services execute. List of Resolvers included in ESB Toolkit 2.0 are shown below.

Adapter Providers

Information retrieved by a Resolver is stored in a .Net based Dictionary object. BizTalk isn’t built to work with Dictionary objects. Adapter provider act as a bridge between .Net based ESB components and the BizTalk based components. Here is a list of adapter providers that are included in ESB Toolkit 2.0.

As you can see from the above list MSMQ Adapter provider is not included in ESB Toolkit. This is where WCF-Custom adapter provider comes in handy. WCF-Custom adapter is able to invoke any WCF binding. WCF includes netMsmqBinding which can be used to send messages to MSMQ.

Itinerary

Any message that is sent to the BizTalk Server goes through a series of steps before its processing is complete. In messaging only scenarios a BizTalk receive location might pick up a message and send it to the MessageBox. One or more Send Ports might be subscribed to this message so they will get this message and send it to the destination system. In case of an Orchestration the message will be subscribed by an Orchestration where it may be decomposed, transformed and sent to one of more system. All this can be easily accomplished by BizTalk without ESB Toolkit. However Itineraries provide the runtime flexibility that BizTalk does not have by default. They also provide more flexible Service Composition. Itineraries are designed in the Itinerary designer in Visual Studio. The designer allows you do to design time validation of the itinerary. When the design activity is complete the Itinerary is exported to an Itinerary Repository.

Sending messages to non Transactional MSMQ using WCF-Custom Adapter Provider

1. Create a private MSMQ queue called test
2. Start Visual Studio 2008 and create a new project of type Class Library.
3. Add a new Itinerary to this project.
4. Set the name of the Itinerary to wcfmsmq
5. Select the Model Exporter to have a value “Database Itinerary Export”. This will enable export of the itinerary to database.
6. Set the Itinerary Status to “Deployed”. This is similar to a business rules engine policy deployment where a policy can be in published or deployed status.
7. Set the Export Mode to “Strict”. This mode captures more details about the itinerary and should be used for any new itinerary. The other mode is called “default” and it is there for backward compatibility with ESB Guidance 1.0 Itineraries.
8. Set the Encryption Certificate Property if you want to encrypt your itinerary. If you want to disable encryption you can see the instructions here (http://blogs.msdn.com/pkelcey/archive/2009/06/08/disabling-itinerary-encryption-in-the-esb-toolkit-2-0.aspx).
9. Other values in the properties windows can be left unchanged.
10. Drag On-Ramp to the design surface.
    1. Update the name property of the OnRamp.
    2. Select “On-Ramp ESB Extender” as the value of Extender
    3. Set the value of BizTalk Application to “Microsoft.Practices.ESB”. This value should be set to the application where OnRamp exists. In this example we are going to use an OnRamp that exists in “Microsoft.Practices.ESB” application.
    4. Select “OnRamp.Itinerary” receive port as the value of Receive Port. This port is a one way receive port.

1. Drag Itinerary Service to the design surface.
   1. Set the name of this service to “RoutingService”
   2. Set the value of Itinerary Service Extender to “Messaging Extender”. This instructs ESB Toolkit to execute this setup in a pipeline.
   3. Set the value of Service Name to be “Microsoft.Practices.ESB.Services.Routing”. This service is a part of the ESB Toolkit. You can create your own messaging services and register them in ESB.Config and they will become available to you in Visual Studio Itinerary Designer.
   4. Set the Container to “OnRamp1->ReceivePort”. This instructs ESB Toolkit to execute the routing service in the pipeline for the Receive Port.
   5. Tracking Enabled property determine if steps of the itinerary will be tracked in BAM.
   6. Right click on the service and add a new Resolver.

1. Set the name of the resolver to “MsmqTest”
2. Set the value of Resolver Implementation to “STATIC”. This implies that we will hard code the settings in the itinerary
3. Set the Transport Name to “WCF-Custom”
4. Set the Transport Location to “net.msmq://localhost/private/test”. This tells the WCF Custom adapter to use netMsmqBinding of WCF to send message to MSMQ
5. Set the value of Action to any string. This value is not used in case but its value still needs to be set.
6. Press the … button for Endpoint Configuration to bring up the configuration dialog box.
   1. Set the BindingType to be “netMsmqBinding”
   2. Set the BindingConfiguration to <binding name=”netMsmqBinding” durable=”false” exactlyOnce=”false”><security mode=”None” /></binding>

      This setting implies that MSMQ message will be not be transactional or recoverable.
      

1. Right click on the design surface and select “Validate”
2. If there are no errors you should right click and select “Export” Model
3. If there are no errors you can use test application C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Source\ESB.Itinerary.Test\bin\Debug\ESB.Itinerary.Test.exe
   1. Set the Itinerary Name to be “wcfmsmq”
   2. Set the Version to 1.0
   3. Select the appropriate file in the Load Message section
   4. Press the “Submit Request”
4. Verify that MSMQ message was written to the Test Queue.

Sending messages to Transactional MSMQ using WCF-Custom Adapter Provider

Most of the steps required to accomplish this task are similar to the steps in the previous section.

The only differences are:

1. Create a new private Transaction MSMQ Queue called “trantest”
2. When you create a new resolver it should be named “MsmqTranTest”
3. Transport Location should be “net.msmq://localhost/private/trantest”
4. Binding Configuration should be set to

<binding name=”netMsmqBinding” durable=”true” exactlyOnce=”true”><security mode=”None” /></binding>

Creating Custom Adapter Provider for MSMQ

We can easily extend ESB Toolkit to create a Custom Adapter Provider for MSMQ. The only requirement for this is that the adapter which you are invoking has to support dynamic behavior.

1. Create a new Class Library project in Visual Studio called “Microsoft.Practices.ESB.Adapter.MSMQ”
2. Set a reference to C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bin\Microsoft.Practices.ESB.Adapter.dll
3. Add a strong name key to this project.
4. Add a new class called “AdapterProvider”
5. Add a statement using Microsoft.Practices.ESB.Adapter;
   
6. Inherit the AdapterProvider class from BaseAdapterProvider class.
7. Override the properties AdapterName andAdapterContextPropertyNamespace as shown below.

1. Add a new XML file to the project called MSMQPropertyManifest.xml. This file has to be named in AdapterNamePropertyManifest.xml format. This file contains all the MSMQ Adapter schema properties(http://technet.microsoft.com/en-us/library/aa577593(BTS.10).aspx ). These are the properties that are used by BizTalk to send a message to MSMQ. Partial list of these properties is shown below.
2. Build the class library and add it to Global Assembly Cache.
3. Copy the file MSMQPropertyManifest.xml to C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Tools\Itinerary Designer
4. Register the adapter provider in esb.config file by adding the line to the section where other adapter providers have been registered.

<adapterProvider name=”MSMQ” type=”Microsoft.Practices.ESB.Adapter.MSMQ.AdapterProvider, Microsoft.Practices.ESB.Adapter.MSMQ, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d3afc588de1b9f91″ moniker=”MSMQ” adapterAssembly=”Microsoft.BizTalk.Adapter.MSMQ.MsmqAdapterProperties, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

Here the name is the name of the adapter, Type is the .Net type of custom adapter provider you just created, moniker is Transport Name in the Resolver configuration and adapter assembly is the BizTalk assembly that contains all the context properties related to the MSMQ Adapter.

Testing MSMQ Adapter Provider

Most of the steps required to accomplish this task are similar to the steps in the previous sectiosn.

Non Transactional Queue

The only differences are:

1. Name of the Itinerary should be ExpressMsmq.
2. After creating Itinerary Service called RoutingService, you need to add a new Resolver.
3. Resolver Implementation is still STATIC.
4. If your MSMQ Adapter provider registered correctly you should be able to select “MSMQ” as the Transport Name.
5. Set Transport Location to FORMATNAME:DIRECT=OS:ESBWIN2008\PRIVATE$\TEST
6. You can once again use C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Source\ESB.Itinerary.Test\bin\Debug\ESB.Itinerary.Test.exe to test this itinerary.

Transactional Queue

The only differences are:

1. Name of the Itinerary should be TranMsmq.
2. After creating Itinerary Service called RoutingService, you need to add a new Resolver.
3. Resolver Implementation is still STATIC.
4. If your MSMQ Adapter provider registered correctly you should be able to select “MSMQ” as the Transport Name.
5. Set Transport Location to FORMATNAME:DIRECT=OS:ESBWIN2008\PRIVATE$\TRANTEST
6. Press the … button for Endpoint Configuration to bring up the configuration dialog box and change the value of Transactional Property to True.
7. You can once again use C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Source\ESB.Itinerary.Test\bin\Debug\ESB.Itinerary.Test.exe to test this itinerary.

Conclusion

ESB Toolkit provides Adapter Providers to allow you to communicate with various BizTalk adapters. WCF-Custom adapter offers a lot of flexibility because it can use any WCF binding. For example WCF-Custom can be used to communicate with any of the WCF based adapters that are included in BizTalk Adapter Pack 2.0. When the existing Adapter Providers don’t meet your need you can easily extend ESB Toolkit to create new Adapter Providers. You can download code samples used in this article from my blog at http://rajsinghblog.wordpress.com

Brewery Name and Location: Red Hook of Seattle, Washington, USA

Name of Brew: Red Hook ESB

Style of Brew: Bitter

Purchase Info: $5.99 for 6 * 12oz bottles.

ABV: 5.77%

Ingredient Info: Pale, Caramel and Carapils malts. Alchemy, Willamette, Centennial and Crystal hops.

Nutritional Info: 183.3 calories per 12oz.

Vessel Used for Tasting: Pint Glass.

Aroma/Olfactory: Malty, caramel aroma. Very faint.

Visuals/Appearance: Clear copper with dispersive off-white head and minimal lacing.

Taste/Flavor: The pale malts are the most prevalent flavor with a minimal hop bitterness. Balanced but bland.

Palate/Tactile: Watery, light bodied and slightly sticky.

Tasting Backstory: This is a good transition beer. I used to drink this a lot when I first started moving towards craft beers, back when good IPAs and porters were too much. Nowadays it just seems bland and uninspired. Good price point. On par with Bud American Ale.

Rating: 5/10

Value Rating: 6/10

Seems there’s a whole “7” theme going on around here lately… Barcamp London 7, WebSphere Connectivity v7…

I’m very excited that WebSphere Message Broker version 7 has shipped today. I have a huge amount of respect for my colleagues in IBM Hursley and the other labs that made this possible.

How did I find out that the eGA (electronic GA i.e. downloadable media) was available? Guess what, it was via Twitter.

I mentioned the highlights of the release in my recent post about the general WebSphere Connectivity v7 family:

further simplification of components and prerequisites, a much enhanced administration interface, a multitude of new nodes, better integration with WMQ v7 (pubsub and HA), slicker integration with the BPM suite through SCA support… this product just keeps getting more streamlined, refined, and functional.

It also includes support for the new Service Federation Management features that were announced as part of WebSphere Service Registry and Repository version 7 which is due later this year. There are more details about the cool new features in v7 in the What’s New in WebSphere Message Broker v7 page in the Infocenter.

Of late, I’ve been doing quite a bit of research and work on enterprise type applications specifically speaking, Enterprise Application Integration (EAI). An EAI system allows applications to “talk” to one another via a messaging model even though the two applications are completely different. An example would be a cobol legacy app needing to exchange financial information with a java web application.

My EAI research led me to two real world models: SWIFT and HL7. From the SWIFT about page:

SWIFT is the Society for Worldwide Interbank Financial Telecommunication, a member-owned cooperative through which the financial world conducts its business operations with speed, certainty and confidence. Over 8,300 banking organisations, securities institutions and corporate customers in more than 208 countries trust us every day to exchange millions of standardised financial messages.

From the HL7 about page:

Founded in 1987, Health Level Seven (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s 2,300+ members include approximately 500 corporate members who represent more than 90% of the information systems vendors serving healthcare.

As I read more about these two models I wondered if a secure messaging model could be used within the real estate industry. The first use case I came up with was a global referral network for professionals needing to find other professionals for real estate referrals. Currently, there isn’t a global network which allows this particular model (and facebook doesn’t count). Obviously, Metcalfe’s Law factors in:

the value of a telecommunications network is proportional to the square of the number of connected users of the system (n2).

So for Real7 to of value to its users, a number of users would need to have access and use the model, but this is always the rub for any online service. But I believe this type of service would not only solve the referral challenge, but also create a greater efficiency regarding time savings in searching for other real estate professionals to refer a buyer or seller client. I’m certain more use cases will be applied to a messaging model as others join in on the discussion, but for now I’m just concentrating on one use case to begin.

I created a google group called Real7 to begin discussions on security, grid computing, and other related technologies needed for a global real estate messaging infrastructure. If this topic is of any interest, please join the google group for posting and receiving discussions on real7.

–Corey

Even after you delete ESB services from ESBControl, ESB cache will not be deleted automatically. To delete ESB cache manually you can follow the steps below:

1. Open windows explorer and click on  Add a network place and create network place for http://yoursoaserver:port/esb/slide/ESB_Projects
2. Remove the cache folder for required ESB project