How to integrate other languages than those from .net world? For example to access messages from the bus in Java or C++? Do I have to listen to the queue in the backend instead? Is there a common Api provided by Rebus?
While Rebus may market itself as a "service bus"(*), it is actually more a kind of a "driver" with a common abstraction that enables .NET programmers to use various queues and persistence technologies without worrying too much about the specifics.
As such, Rebus cannot really be connected to, much as you would not be able to connect to, say, the NpgsqlConnection or the SqlConnection you would use to communicate with your Postgres or SQL Server database.
What you could do, was to interface with Rebus at the transport and/or persistence level, e.g. by using the same wire-level format when exchanging messages.
This would require that the chosen transport (MSMQ, RabbitMQ, SQL Server, etc.) can be interfaced with from the desired platform, and then you would need to be able to supply the correct headers for Rebus to accept the message as valid.
There is no official Rebus implementation for any other platforms besides .NET (.NET 4.5 + .NET Standard 1.3).
To my knowledge, no one has attempted to actually build a Rebus-compatible messaging library on any other platform.
(*) I actually usually use the word "messaging library" to describe it, because I think it carries way less confusion and semantic overload with it.
Yes. I think we need to know a minimal message format that an application for example PHP can compose and send directly to an endpoint queue. That would make life easy in certain cases.
Related
I am new to SignalR and I try to understand the difference between consistent connection and long polling,Is there different use in methods ? is one better than the other? are there any diffrenet functions need to polling and other functions to use consistent connection?, I googled but didn't find a simple answer to this question, can someone help? need an explanation.
SignalR is a framework that allows us to build real-time web applications. Ideally, we would use web sockets for this. However, web sockets is a new protocol and requires support from both the browser and the server. Thus, web sockets are not generally available and SignalR tries to provide an abstract connection similar to web sockets but built upon existing technologies and techniques. This abstraction is called a Persistent Connection.
Persistent connection is the term used to describe SignalR's abstract connections.
Long polling is one of several techniques used to implement SignalR's persistent connections (the others are Forever Frame, Server-Sent Events and Web Sockets).
Hi went through Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.
http://www.eaipatterns.com/toc.html
I also went through Camel and Mule's compliance with these integration patterns -
http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule
http://camel.apache.org/enterprise-integration-patterns.html
I see that both Mule and Camel allow applications to be deployed and accessed via webservices like SOAP or REST, SOAP being more RPC style. They allow massive integration support using opensource utilities like CXF and Jersey. In fact Mule also supports RMI endpoints - which will give remote method invokation capability as well which is a well-accepted form of Integration.
I understands ESBs are built around a Message Bus with additional support for other protocols however ESBs only comply to EIP and EIP is not just ESBs.
Question is why SOAP/REST or their transport protocol not considered as "Integration Styles" and which is Enterprise Integration so "Message Oriented"?
I am a novice compared to the great minds which designed these patterns but trying to understand the lopsided message-y nature of Integration patterns. I admit it isn't quite the QnA format of stack overflow but will request Mods to keep it alive for a while so that people can share their opinions.
As for SOAP, it would put it under the Integration Style "Remote Procedure Invocation", since it's pretty much what SOAP implements in reality (I won't consider the SOAP over JMS hybrids here with a potential to mix RPC with Messaging..).
REST is, interface wise, very different from SOAP in that it's resource driven instead of service driven. I would non the less group it under the "RPC" style since it's just another format of syncrhonous RPC calls.
I would, however, not put too much effort in theory of what EIP integration style a specific message pattern implements.
Look at a specific scenario at hands instead and use the EIP to model your specific integration.
I've seen integrations of file transfers that in realtiy implemented RPC patterns or SOAP services that in reality implemented messaging (although I don't really recommend do this).
A concrete example: consider the usage of a dedicated file upload service, which happends to be built using SOAP technolgy, which uploads a CSV file to a file area on a server, from where it's picked up by some other system. I would call this file based integration on a high level.
Another example is that Messaging systems sometimes are implemented using a shared database. Still the integration style using them is messaging, not "Shared Database".
Think about how your integration should work on a high level, then apply the various protocols to do the grunt work.
I need to implement simple file watcher utility. I have decided to implement this in a simple windows service which will internally use FileSystemWatcher. The purpose is to monitor given directory path (or ftp) and copy the file to some other server wherever new file comes in after checking some predefined logic
As I am using .net 3.5; client suggested me to use WCF. I have very less experience in WCF.
I am not sure how I can create WCF service which will function like WindowsService and can be deployed in services on windows server.
To be a futuristic is it a good idea to create WCF service instead of windows service, or I should insist on window service.
Windows Service != WCF
You can't create a WCF service that acts functions like a windows service. A WCF service waits for messages from third parties and acts on them, a windows service is a process that is always running in the background. WCF tries to solve the problem of separating out the communication mechanism (transport protocols such as Tcp, Http, Named Pipe, etc) from the service interfaces.
File Watcher Utility
While in theory it's possible to create a new Flat-File binding in WCF that "could" have it's address set to a file system location, one does not exist directly in the .NET framework. Looking at the Custom Bindings article on MSDN it's not immediately obvious to me how one would construct a File System binding. These are the defined transport options available:
TCP
HTTP
HTTPS
Named Pipes (IPC)
Peer-to-Peer (P2P)
Message Queueing (MSMQ)
Custom
If communication must be done through file drops, then WCF does not solve your problem.
Where WCF Might Work
What the client might have meant is to create a WCF endpoint that does the copy the file to some other server wherever new file comes in after checking some predefined logic, but you would still want to have a windows service with a FileWatcher monitoring the input directory.
If you have multiple clients that need to be able to perform that same logic and then send the output to that other server then it might make sense to make the WCF service, otherwise it's over-engineered at this point.
You should choose the simplest option until you find a need to change, with the simplest option being a Windows Service.
There is a coding principle call YAGNI (you ain't gonna need it) that applies in this case as simply wrapping something up in a WCF service would do nothing but add unneeded complexity for the majority of cases. Simply put do the minimum viable solution and extend only when you need to.
PS. If you are using the FileSystemWatcher over network shares note that there are documented problems with it and you should use a combination of a poll + FileSystemWatcher. There are lots of explanations on Stack Overflow about it.
In your use case, the Windows Service makes a lot more sense and I think that to be the more appropriate solution. You need something that is always running and monitoring a directory and thats exactly the use case which Windows services are very good at.
I would consider talking to the client and explaining the Windows Services are the more appropriate solution to this kind of use case. Also, windows services are not old hat, they are there to solve exactly these kinds of use cases and WCF / windows services complement each other.
Both features have Service in their names by they have virtually nothing in common.
A Windows service runs constantly on a single machine.
A WCF service is code than can be called remotely by other machines.
It simply depends on what you need to do. A Windows Service and a "WCF service" have little in common.
The question here is whether you need a HTTP endpoint or not. If you do, you could even host a WCF service in your windows service to provide that. Keep in mind that a WCF is only used as a way to communicate between applications.
Reading your description, though, it doesn't seem like you need it.
WCF Service in a Managed Windows Service
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
Both solve completely different problems:
An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
An RPC system provides client and server technologies for performing RPC operations.
NServiceBus and MassTransit are two tools that can be used to implement messaging with MSMQ and other message queues.
I find that once you start using messaging to have applications talk to each other, you don't really want to go back to the old RPC style.
My question is, what other tools are out there? What tools do you use?
Apache ActiveMQ is probably the most popular and powerful open source message broker out there with the most active open source community behind it as well as commercial support, training and tooling if you need it.
One of the more interesting aspects of ActiveMQ is its wide support for a large number of different language bindings and transport protocols
WebSphere Message Broker is IBM's flagship ESB which runs ontop of MQ.
They also produce WebSphere ESB which is a slightly lighter offering which specialises in ESB across web services.
We use WCF services for synchronous message based operations, and nServiceBus for anything asynchronous.
Rogue Wave is very popular [ http://roguewave.com/products/hydra/ ]
So are IBM's Websphere offerings [ http://en.wikipedia.org/wiki/Mqseries ]
WCF is extremely powerful and should be looked into by anyone in the .NET space starting up a message based system.
I would recommend against BizTalk unless you can make a lot of use out of it's adapters (ie. you have a lot of old systems to communicate with).
Nuedesic makes a great WCF based ESB, Neuron, if you are willing to pay a bit.
I use IBM software stack because it has the widest set of features (pub/sub, async, sync) and platform support (60+ combination of platform, languages) and also a great set of free tools provided by IBM
For Operations, I use use the linear log rotation IBM WebSphere MQ supportpac
For development and testing, I like RFHUTIL to generate fake cobol, java, MS objects, other binary and text objects and SOAPUI to invoke HTTP web services. If I need to invoke MQ based web services, I go back to RFHUtil. Of course Websphere MQ Explorer for admin.
We use the old WebSphere Message Broker 6.1 (now IBM Integration Bus) that is fast and reliable once you are acquainted.