The documentation of Service Fabric recommends service remoting, ICommunicationClient or WcfCommunicationClient to realize the communication between the micro services.
The ServiceBus, which I always used for inter-service communication, is not even mentioned. Why?
I think you misinterpreted the docs. It does not recommend any protocol or service (the word is not even present on the page). What it does do is list the built-in communication options and appropriate situations of when to use them.
There is nothing that prevent you from using service bus for inter service communications. In fact, if you google around you will find some projects like this one
The ability to plug in any desired service or protocol is one of the great things about SF, but they leave the implementation to you.
There are many approaches to do service to service communication, if they had to document all of then, they would spend more time writing the possible approaches than doing the actual communication.
They probably decided for the one with closest relation to the platform, but they could write about any possible, it is just a matter o preference.
I could name a few from many just to have an idea:
Http
Remoting
WCF
Service Bus
Event Hub
AMQP
MQTT
gRPC + protobuf
TCP
UDP
Pipes
And many more, Imagine if they had to document all of then.
The communication is flexible enough to let you implement using any communication mechanism.
Regarding the ones you mentioned,
I always opt for HTTP for being platform agnostic and widely implemented on most platforms, does not matter if is .Net, Java, NodeJs, Windows or Linux, they all talk the same language, the others are very tight to the .Net and Windows platform and force every other solution to be also tighten or adapted to then. And also there is the fact of some being synchronous and other asynchronous like Service bus.
Then, when performance is an issue, I evaluate the other options.
Related
I'm new to microservices. I envision them as a set of processes running in two or more machines (I suppose for a given process two instances must be run in separate machines for reliability). In that setup, depending on the kind of clients I have there may be one process working as a TCP server serving on a specific high port and speaking a non-HTTP protocol.
However, for my low-bandwidth, testing purposes, I haven't found a free cloud service which provides that kind of environment (machines to run processes on – say, Java on Linux – while keeping a high port open).
Maybe the facilities I'm expecting are only available to paying customers, or maybe implementing a microservice architecture in the cloud goes beyond simply running processes in machines and sharing a database? Could someone clarify? (and if possible direct me to one such free service)
Yes, you are right when you say Microservices are more about independent service (processes) that can be deployed in one or more cloud machines. Each service can communicate to other using non-http protocol like Message brokers, Thrift, Remote Procedure call (RPC) etc.
As the architecture point of view, services should mostly be decoupled enough to handle complexity of distributed computing. see the image on Microservices Architecture link
There's a concept of API Gateway which could be used for authentication and service registration and discovery purpose.
Coming back to your question, you can test microservices on single cloud (by running each service on different port) and use API Gateway to discover the service path for references here are the links which are worth to look at these.
For concept see links: Microservices.io and stackoverflow question
For Implementation: zookeeper and Auth0 (this is what i'm using)
If you are java lover great to look at infoQ article
Some of the free source that might can help in building and testing microservices are: Google App Engine, hook.io
I have a service that exposes a JSON-over-HTTP API (that uses ServiceStack) and now I am writing a .NET client (dll) that abstracts away this API to basically provide a domain-specific object abstraction on top of it. This client will be used by apps that need to hit the service a lot so striving for high-throughput and low-latency is important. I've done quite a bit of optimization work on the service to get it to acceptable levels of throughput and latency (measured those using JMeter). Naturally I would like to make the client as fast as possible.
I would like to use ServiceStack's ServiceClient library to handle the communication with the service and have a couple of questions:
Is the JsonServiceClient thread safe?
Does the JsonServiceClient (or any of the *ServiceClientBase children) do some sort of connection pooling when they talk to HTTP v1.1 servers? Or do they open a separate connection for each request they are asked to perform?
I would also appreciate any suggestions on how to use ServiceClient or perhaps maybe another library in order to make the communication with the service optimal (client-side caching is part of my plan so that's already in the works).
I'm not too familiar with ESB or Biztalk and am trying to get my head around what makes the most sense from an EAI perspective if you already own Biztalk. As I understand Biztalk is a message broker(hub and spoke) and the ESB pattern is an anti-broker where the conceptual "bus" is made of individual distributed components that talk to each other somehow.
Message brokers inherently represent a single point of failure as opposed to an ESB where one component failing does not bring down the "bus" as a whole. Also my understanding is that Biztalk is monolithic in the sense that messaging, orchestrations are tightly coupled and scaling is problematic.
If the scenario at hand is:
Biztalk is already being used primarily for running different orchestrations based on different files received from outside parties.
A bunch of inhouse custom appications which are currently tightly coupled to system such as CRM and payroll need to be refactored to abstract out these dependencies.
Would it make sense to use Biztalk directly or Biztalk ESB toolkit for achieving ESB functionality or would it make sense to use a proper ESB implementation such as NServiceBus or Service Bus for Windows which is based on Azure Service Bus.
What are the pros and cons of using Biztalk directly to achieve EAI vs. using a proper ESB.
Would each application take a hard dependency on Biztalk and whether this is desirable?
I will leave this as an open ended discussion since there is no right or wrong answer.
#StuartLC:
Thanks for your response. I've read several of the links you posted but still did not get a clear sense of whether Biztalk would make sense as an ESB solution vs. using something like NServiceBus. Both seem to implement the "ESB" pattern in one way or another. Question being which one has a cleaner implementation, better development experience and low ramp up time. My assessment so far(from pure research only) is that yes Biztalk can be used but it is painful and requires very specialized dev. skill sets. Latency and scaling being problematic and the fact that Biztalk will
eventually be assimilated into the (Azure?) Service Bus and the Biztalk SKU will cease to exist.
On the other hand, a framework like NService bus has relatively low ramp up time, can be easily picked up by a dev. having good .NET programming skills in general and can interface easily with Biztalk.
Given the above, would it still make sense to go the Biztalk route even though you currently have Biztalk in house or to future proof yourself go with a proper ESB such as NService Bus ?
I believe many components of your open-ended question have already been covered on SO:
Pros/Cons of using BizTalk instead of NServiceBus or MassTransit
What ESB systems work best for the .Net stack?
Microsoft BizTalk Server vs Azure AppFabric Service Bus...?
BizTalk 2009 ESB Confusion
Is BizTalk an ESB?
However, IMO it is just a flawed / short-sighted implementation which which would result in tight coupling between apps and endpoints. Loose coupling is easily achieved : (even without the ESB toolkit):
By using multipart messages and canonical internal schemas for decoupling dependencies.
Orchestrations and ports should be decoupled by publishing via the message box
Single point-of-failure is also avoidable:
Configuring Retries and Alternative / backup transports on communication adapters
Redundancy achieved e.g. via Server Groups and Clustering
And fall back using compensation for failed delivery
IMO the Achilles heel when using BizTalk as an ESB is the lack of guaranteed latency e.g. here which is exarcebated if BTS gets into a throttling state.
Update
IMO the choice boils down to a matter of whether you have control over all systems in your environment.
If you are integrating an internal enterprise consisting only of homogeneous, contemporary (and mostly SOA and EDA) applications over which you have direct control, MassTransit or NServiceBus would likely more than do the job give and you better productivity and ramp up time.
I have a few applications that I have built that leverage MSMQ on a Windows Server. I would like to port these to Azure-based Web Applications which helps me with some of the security and trust-barrier challenges I have faced in the past.
My question is, can I expect that the Message Queue aspects of Windows Azure storage will behave the same as MSMQ?
In general, not really. While both are queueing solutions, you will find that Windows Azure queues don't have the same guarantees that MSMQ will have (for good reason). For instance, WAQ supports a delivery model of 'at least once' versus 'exactly once'. It also uses a 2PC model where you must pop and then delete a message. It is also not involved in transactions like MSMQ can handle. However, for cloud queuing scenarios, some of these considerations matter less. There are other nuances as well (message TTL, invisibility, renewals, storage time, etc.) that differ.
It might be easier to answer more completely if you explain what features your queueing needs must have. Also, keep in mind that AppFabric has a queueing service that also might be appropriate depending on what you really need.
I am new to WCF services. I have been working with WCF for over two months now and love its capabilities. I am using a self hosted WCF in a Windows Service. The binding is netTCP because the client and service are on the same machine. My communication is duplex and I am using a WCF session. With these features, one of the design needs for my application is that UI should always be connected to the service - I am using a separate thread in my UI to always poll the connection status and re-create and open the channel in case it goes to faulted state. Since I have async call backs from the service, the client should always be connected. Here are a couple of questions:
Is it OK to use self host technique knowing that the client and service on the same machine? I used WCF for ease of inter process communication.
Does it make sense to keep this keep alive thread from the client or should I be using some other technique?
I want to get better in using and configuring WCF. is there a good book or online reading material on self hosted WCF services?
Please advice.
Thanks,
Subbu
I think it's absolutely fine to use self-hosting with WCF. I've implemented many services that are hosted in a Windows Service for example.
I'm assuming that you're talking about client and server being hosted in different processes on the same machine? If so, then ideally you should use binary over named pipes in your bindings.
If client and server and physically in the same process, then you might consider using something like Roman Kiss's Null Transport to reduce the serialization overhead. His CodeProject article can be found here: http://www.codeproject.com/KB/WCF/NullTransportForWCF.aspx
To answer point 2, I've suggested an alternative approach in my answer to another Stackover question: WCF net.tcp server disconnects - how to handle properly on client side?
Hope this helps.