Implementing Adapters

[gregoryyoung]

Is there any documentation on implementing adapters for MT? I am tasked this or next week with implementing one for event store.

Thanks,

Greg

[phatboyg]

At this point, working towards supporting MassTransit 3 would be the best option. It's nearly out of beta and ready for general release.

When you say an adapter, can you link an existing adapter for other systems to use as a basis? If so, I could give some guidance on how to wire it up.

With MT, it's easy to add send/publish observers, as well as receive/consume observers so that might a good integration point if you're just capturing the events for storage. If you're looking at EventStore being a transport, that another story but equally interesting.

So, give me a little guidance, and I'd be glad to help with direction or contribution/help as needed.

[gregoryyoung]

Yes as a transport.

On Sunday, August 9, 2015, Chris Patterson notifications@github.com wrote:

At this point, working towards supporting MassTransit 3 would be the best
option. It's nearly out of beta and ready for general release.

When you say an adapter, can you link an existing adapter for other
systems to use as a basis? If so, I could give some guidance on how to wire
it up.

With MT, it's easy to add send/publish observers, as well as
receive/consume observers so that might a good integration point if you're
just capturing the events for storage. If you're looking at EventStore
being a transport, that another story but equally interesting.

So, give me a little guidance, and I'd be glad to help with direction or
contribution/help as needed.

—
Reply to this email directly or view it on GitHub
#330 (comment)
.

Studying for the Turing test

[phatboyg]

That should be doable - the transports are cleaner with MT3, and part of the whole configuration syntax so that transport-specific stuff is easy to add into the configuration.

Let me know if I can help in any way.

[gregoryyoung]

Do you guys have a slack chat etc I could join for higher bandwidth
questions etc during the week? Also do you want me to branch mt3 and pr
back to it or keep transport etc in a separate package? I notice thus far
you are going for the former which gives a better overall experience eg
single package however in general I might suggest separating out each
adapter into its own project (this was done with neventstore a while ago
for example as it simplified much of dependency management / testing
stories)

Greg

On Sunday, August 9, 2015, Chris Patterson notifications@github.com wrote:

That should be doable - the transports are cleaner with MT3, and part of
the whole configuration syntax so that transport-specific stuff is easy to
add into the configuration.

Let me know if I can help in any way.

—
Reply to this email directly or view it on GitHub
#330 (comment)
.

Studying for the Turing test

[gregoryyoung]

I spent an hour or so today looking through the interfaces and some of the implementations (rabbitmq) and I have to say I still have no clue what interfaces to implement/which logic goes where. Connection IDuplexTransport Publisher etc

Also many of these interfaces seem very platform specific e.g. in Connection there is an address to connect to. When running a cluster we don't have a single address to connect to. Also there are lots of things like retry strategies etc that we already support at our connection level. Any pointers on which interfaces actually need to be implemented to become an effective transport would help. Also is it reasonable to have the transport accept an eventstoreconnection? Generally with EventStore you don't want one connection per transport instance but want to share a connection between them (its a fully async connection)

[phatboyg]

So, based on your comments, I think you were looking at the v2 semantics, which are dying with v2.

In MassTransit 3, it's an entirely new world. Consider RabbitMQ:

Each host connection is encapsulated in a Host responsible for connection management (or none, if your transport does not use connections).
https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqHost.cs

Receiving and sending are two completely separated concerns. To receive, a receive transport is created that delivers messages to the receive pipe (which ultimately connects to the bus for message delivery).
https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqReceiveTransport.cs

Sending involves resolving an ISendEndpoint that can be used to send directly to an endpoint address. Publishing uses a separate IPublishEndpoint which determines the publishing structure and delivers the published message to subscribers.
https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqSendTransport.cs

Each transport is designed to extend and create its own configuration extensions, since every transport is configured differently. So there is some configuration classes needed to support all of those things.

This is brief, but should get you better down the path for creating support of EventStore.

In practice, you'll have your transport reusing an existing connection from the host. Everything in MT3 is async, so your async connection should slip right into the call path. MT3 also uses middleware extensions everywhere (it's all pipes and filters), and the context passed is the state passed between filters. So you'll see a lot of compositional elements around the way the transports hook up to the bus.

[gregoryyoung]

My problem may be reading MT2 code thanks I will check it out

On Sun, Aug 9, 2015 at 6:14 PM, Chris Patterson notifications@github.com
wrote:

So, based on your comments, I think you were looking at the v2 semantics,
which are dying with v2.

In MassTransit 3, it's an entirely new world. Consider RabbitMQ:

Each host connection is encapsulated in a Host responsible for connection
management (or none, if your transport does not use connections).

https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqHost.cs

Receiving and sending are two completely separated concerns. To receive, a
receive transport is created that delivers messages to the receive pipe
(which ultimately connects to the bus for message delivery).

https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqReceiveTransport.cs

Sending involves resolving an ISendEndpoint that can be used to send
directly to an endpoint address. Publishing uses a separate
IPublishEndpoint which determines the publishing structure and delivers
the published message to subscribers.

https://github.com/MassTransit/MassTransit/blob/mt3/src/MassTransit.RabbitMqTransport/RabbitMqSendTransport.cs

Each transport is designed to extend and create its own configuration
extensions, since every transport is configured differently. So there is
some configuration classes needed to support all of those things.

This is brief, but should get you better down the path for creating
support of EventStore.

In practice, you'll have your transport reusing an existing connection
from the host. Everything in MT3 is async, so your async connection should
slip right into the call path. MT3 also uses middleware extensions
everywhere (it's all pipes and filters), and the context passed is the
state passed between filters. So you'll see a lot of compositional elements
around the way the transports hook up to the bus.

—
Reply to this email directly or view it on GitHub
#330 (comment)
.

Studying for the Turing test

[phatboyg]

The transports for Azure Service Bus and RabbitMQ are pretty stable at this point. Either could be used as a basis for building support for additional message transports.