We are doing the migration from WCF to gRPC. IN WCF we used ServiceInstanceContext as percall, persession and Singleton. Based on these we have our business logic. When we explored the similar implementation in gRPC and could not find any.
Is anyone aware of any such implementation in gRPC.
Related
Can I use SOA and three-tier in one application? Using SOAP to connect for external services, using MQ and Spring MVC. I have an application server and server for the database.
Yes, it seems that they are very different things.
There is a vast array of different SOA implementation styles, you can do it in so many ways. One is to have services talking to APIs over http where the APIs in question are written in a 3 tier style.
You can also have an event driven architecture where messages are passed on a message bus or a queue or some sort, the services reading and writing to those queues can be written in a three-tier style.
To sum up yes you can have SOA and three-tier in the same architectural solution, one does not exclude the other.
Does this help your decision on how to structure your service design and how to structure the wider solution architecture?
I had a web service which has been using NServiceBus message handling between controller and domain logic. For a new functionality, I have to implement signalR webRT communication between clients and server. But there are some performance problems. I thought that, the problems occur from my design defect but I couldn't detect reason of the problem, yet.
Before SignalR integration, my web service was responsing in 20-30ms. But when a signalR client (only one client is enough) is connected to my web service, the responce time becomes to around 10000ms. When I remove NServiceBus implementation between my controller and domainlogic (directly operate my logic in controller and return) the responce time again down to reasonable value (around 20-30ms).
My web service is a .net core project. And I'm using long-pool threading mechanism for signalR.
Axon Framework supports Distributing Events which should allow to post events to the external message broken and read events from message broker.
Amazon provides two different messaging services
Amazon Simple Queue Service (SQS)
Amazon MQ
Questions:
What Amazon messaging service might be used (SQS, MQ or may be both) as message queue with Axon Framework?
What is the best practice for implementing distributed Axon message processing in Amazon EC2 cloud?
It looks like that Amazon MQ should work fine with Axon Framework as message queue because it supports AMQP. But I failed to find any references about any practical experience using MQ with Axon.
Any messaging service implementation which supports, AMQP should work just fine with the Axon Framework. More specifically together with the axon-amqp dependency, as you might already have found out.
Without personally having any experience with Amazon SQS or MQ, I did a quick search on both, and it seems Amazon MQ is indeed the go to solution to distributed your events on Amazon EC2.
I do not have or heard any best practices for distributed your Axon Framework events over Amazon EC2 specifically, sadly enough, but I can share this.
All the Axon Framework (when adding the axon-amqp dependency) does, is subscribe to the EventBus and publish any incoming events on a queue; no further specifics.
Hence I'd say any best practices for general use of Amazon MQ should apply on your second question.
Is it advicible to build the MSA based services on Oracle SOA or any other ESB suite for that matter? Is there any advantage or disadvantage?
If I am using Java, Spring and JPA over a message queue - say - RabbitMQ, I can achieve it in a more controlled environment with less recurring expenses. Of course will end up mixing tools like Drools or JBPM or similar to achieve things that may be OOTB (Out of the box) in the SOA Or ESB Suite. But scaling a specific service without paying licence fee for an additional environment should certainly be a good catch right?
Microservices architecture pattern applies to development of backend systems/services, whereas ESB (e.g. Oracle SOA Suite) is intended as an intermediary layer between consumers and backend services. Backend services contain rich application logic, whereas ESB services provide only intermediary functions like routing, transformation, orchestration etc.
ESB is not intended for rich application logic, though it's possible to do that.
Using ESB (e.g. Oracle SOA Suite) to host microservices is achievable, but you will get a big overhead comparing to limited functions and scalability. If you are looking for centralized API management (tracing, security etc.), you can put an API gateway into your architecture instead of full scale ESB.
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.