Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
The Mule ESB project explains its difference to Spring Integration on its website. However, regarding dcterms.date 2012-07-19T18:43-03:00 of the document, the text might be outdated.
The main points of the quoted paragraph are
"Spring Integration takes [...] an 'application-centric' approach to integration".
"Rather than implement a shared bus, [...] Spring Integration is aimed at providing 'just a little' ESB-style integration to specific applications".
"Spring Integration is best suited to situations where a small number of components must be integrated, usually internally".
"[Spring Integration has a] very small number of supported transports and transformers available".
"[The] scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context".
Are these points still valid? Does any more detailed and, if so, up-to-date comparison exist?
Mule ESB vs. Spring Integration
Recently, a new component called Spring Integration was added to the Spring Portfolio, which allows ESB-like functionalities and EIPs to be created and managed within the Spring Framework. Spring Integration takes what is known as an "application-centric" approach to integration.
Rather than implement a shared bus, which allows all integration and messaging between components and systems to be managed, administered, and configured centrally, Spring Integration is aimed at providing "just a little" ESB-style integration to specific applications by providing frameworks for implementing common EIPs such as a message bus and simple routing.
Due to its limited scope, Spring Integration is best suited to situations where a small number of components must be integrated, usually internally, and the infrastructure in question is made up of a large number of other Spring components. For anything more complicated, the lack of a common bus, coupled with the very small number of supported transports and transformers available for the young project makes Spring Integration unsuited for the task.
The advantage of using Mule ESB to handle integration in a Spring environment is that Mule ESB is not simply an ESB - it is an integration platform. Whereas the scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context, Mule's intentionally modular architecture allows teams to quickly deliver the lightest possible integration solution for any scenario, from simple point to point integration to complicated SOA, cloud and partner ecosystem scenarios.
Full disclosure: I am the current a past Spring Integration project lead and have been a committer for over 10 years.
While it is true that Spring Integration promotes modularity and loose coupling within an application, it is also very well suited for integrating systems together without the need for a central ESB. I am personally aware of a number of very large enterprises that integrate all their business systems together using only Spring Integration, with no central bus server(s) to configure/administer.
Its POJO programming model makes it incredibly easy to customize/extend; if some transport/protocol is not supported out of the box, you can simply wrap it in a POJO and invoke it (or consider writing a more formal adapter and contribute it back to the framework!).
We are particularly excited that it forms the basis of the new and important Spring Cloud Stream.
You may want to take a look at DZone's recent Guide to Enterprise Integration which talks about Spring Integration as well as the competing technologies.
Related
Recently I was asked to create:
a web service that abstracts away two downstream APIs;
But I'm confused by the question as from my understanding of the subject matters turns the question in to kind of a contradiction for me.
As Abstracting is the creation of something that is not dependantent on anything el's and only expose the data that needs to be exposed.
While Down streaming is the usage of other existing software in your own direction or for your own purpose in essence the usage of Open Source to create your own software.
The issue being that in order for me to create a Web Service that consumes 2 Web API I would be making my Web Service Dependent on those API.
I wonder if someone could clarify what is meant by this exactly:?
you are tasked with implementing an OpenAPI (formerly Swagger)
compliant web service that abstracts away two downstream APIs;
My organization is looking to install MuleSoft to support data and process integration. We have 5 ERP's and need to consolidate data quickly for analysis and process improvements. Looking for references or issues you have experience with MuleSoft.
While seeking extra details from this curious person, I have got an interesting research paper putting up light on Enterprise Integration Architecture while leveraging the tools of Middleware like Oracle SOA Fusion Middleware and MuleSoft ESB specifically. There are many other tools that are fairly doing well in the market and yes are available as open source and at fairly high price in terms of yearly licencing cost. Coming back to main point. You get what you ask for!
First, Kindly go through the relevant MuleSoft Documentation to get started. Perform few POC's and observe how user friendly the tool is ! The tool is not too generic to quote and unquote standard inherent issue. It's the developer's ability which makes the tool to be used efficiently.
When you talk about Middleware Integration Services, you should have a background story of all the tools which falls under such category. Have you explored the other options ! such as spring boot micro services, dell boomi, web methods before.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This buzzword is making me pull my hair... I have been asked to create
a microservice using .net core.
Googled a lot, different definitions and samples, but still, I don't know what makes a vs project a microservice / how can I create a microservice in VS. For example, I have asked to create a microservice where a user will input two latitude and longitude values and they will get the distance between them.
Cool, I can do this as a web project in no time. But here I need this as a microservice where the rest of the projects in our firm can use it.
What really makes a VS project into a Microservice or can I convert a project into a micro service? Microservice experts are welcome ...!!! I looking for that step by process in which a microservice is created in .net core.
A microservice is simply a concept. You won't find a "Microservice" template in Visual Studio. Generally, you're going to be implementing a REST API. A microservice doesn't have to be a REST API, but they most normally are.
You also generally won't just be making a microservice, but rather microservices. One of the core tenants of a microservice is that it should deal with just one discrete unit of functionality. Unless your application does just one very boring thing, you'll need multiple microservices. For example, for an ecommerce site, you might have a user service, a cart services, a checkout service, an order service, etc.
To coordinate the efforts of all these microservices, it's also typical to implement an API gateway. The application will work with the gateway only, and the gateway will proxy out the requests to each individual microservice to get the information or do the work that the application requires. In a sense, it acts as a conductor would, coordinating all the individual instruments to create the harmony.
Long and short, most likely what you want is one or likely more ASP.NET Core API project(s). You'll create controllers and actions on those controllers, where the latter of which will effectively become your endpoints, i.e. the functional routes your API exposes to do work. Since a microservice architecture is desired, these API project(s) should remain small and razor-focused, potentially only each working with just one entity class or maybe a very narrow slice of app functionality that involves multiple entities. You should strive to keep them as lightweight as possible, minimizing the amount of middleware and external libraries involved. When it comes to deployment, it's most typical to use containerization - Docker is a popular choice for that.
There's not really a template for creating a microservice in .NET, because any application that is deployable in a standalone way and that is reachable over some form of communication protocol (be it HTTP, message queues, or anything else) to perform some sort of action can be called a microservice.
See also Martin Fowler: Microservices and .NET microservices - Architecture e-book.
So to create your service that will "[accept] two latitude and longitude values and [return] the distance", you can simply create an ASP.NET Core Web API with one action method, and that's your microservice.
Another really good resources aside from what others have mentioned is: https://12factor.net/
It doesn't talk about any implementations (so you wont find references to .NET Core in there) but it does talk about how to design your application so it behaves more like a microservice - including dealing with scaling and processes that are stateless.
And to clarify a point of confusion: there's no special application type for a microservice. If your application behaves like a microservice, it is a microservice!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Could not find an answer on this question, so would like to initiate this:
Tibco EMS vs. MSMQ vs. MQ.
How do these 3 technologies compare?
Which one is better and in which kinds of scenarios?
Specifically, I think to use one of these in SOA environment (.NET + WCF), where the scenario will mature over time.
I have one additional specific interest in the performance, which is important to mention. So, if given a choice, performance is of a critical priority.
I would appreciate to have a comparison table for a clear picture.
Thanks!
EDIT:
I am concentrated on two parameters: performance and scalability.
Scalability - how do these technologies compare in terms of supported concurrent users' count? which can support more users? scenario does not matter, let's choose the scenario which is supported by all them - e.g. simple queues.
Performance - in exactly the same scenarios, which performs faster?
If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.
MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.
Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.
IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.
Edit:
There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.
On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.
For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example,
- Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc
- Will you integrate systems in a point to point manner or you may consider having a Hub / ESB?
- Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc)
Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.
Again it is expensive commercial solution more suitable for enterprise scenarios
where mainframes are involved
Not sure why you mentioned mainframes. Many MQ enterprise customers don't have them.
IBM MQ - IBM technology supporting queues and it also somehow emulates
topics (publish/subscribe)
MQ v7.0.0 (released 2008) and onwards supports pub/sub topics as a native feature, there is no emulation involved.
APIs for both Java and .NET are terrible.
The MQ Classes for Java and JMS have evolved over 10+ years and are used heavily by thousands of enterprises.
.NET API is full of bugs and it doesn't work as expected.
The .Net API has been around for 7+ years over a few major releases of MQ. I would imagine that the obvious bugs would have been shaken out by now.
I am concentrated on two parameters: performance and scalability.
MQ has unlimited scalability. Performance is very good even with no tuning.
MQ is best only if you need to integrate with lots of mainframes. Pub/Sub is implemented poorly and the many APIs are 'strange to use'.
If all your applications are Windows, MSMQ might be a good choice, but it will be difficult to bridge into Unix or Java worlds.
The whole Java community standardized on JMS so TIBCO EMS is a good choice if you ever want to connect non-Windows applications.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
We are thinking on moving our Rest API Server (it is inside the web service, on Symfony PHP) to Scala for several reasons: speed, no overhead, less CPU, less code, scalability, etc. I didn't know Scala until several days ago but I've been enjoying what I've been learning these days with the Scala book and all the blog posts and questions (it's not so ugly!)
I have the following options:
build the Rest API Server from scratch
use a tiny Scala web framework like Scalatra
use Lift
Some things that I will have to use: HTTP requests, JSON output, MySQL (data), OAuth, Memcache (cache), Logs, File uploads, Stats (maybe Redis).
What would you recommend?
In no particular order:
Akka HTTP
Spray
Paypal squbs (Akka/Spray)
DropWizard
REST.li
http4s
Blue Eyes
Finagle - A fault tolerant, protocol-agnostic RPC system
Play! and Play-mini! (article) (tutorial)
Lift / Lift JSON.- makes it simple to provide REST services.
I'm going to recommend Unfiltered. It's an idiomatic Web framework that does things "the Scala way" and is very beautiful.
Take a look at Xitrum (I'm its author), it provides everything you listed. Its doc is quite extensive. From README:
Xitrum is an async and clustered Scala web framework and web server on top of Netty and Hazelcast:
Annotation is used for URL routes, in the spirit of JAX-RS. You don't have to declare all routes in a single place.
Async, in the spirit of Netty.
Sessions can be stored in cookies or clustered Hazelcast.
In-process and clustered cache, you don't need separate cache servers.
In-process and clustered Comet, you don't need a separate Comet server.
I would add two more options: akka with built-in JAX-RS support, and simply using JAX-RS directly (probably the Jersey implementation). While arguably less "Scala-y" than others (relying upon annotations to bind parameters and paths), JAX-RS is a joy to use, cleanly solving all of the problems of web service coding with minimal footprint. I've not used it via akka, I would anticipate it being excellent there, getting impressive scalability via it's continuation-based implementation.
Take a look at Finch, a Scala combinator library for building Finagle HTTP services. Finch allows you to construct complex HTTP endpoints out of the number of predefined basic blocks. Similarly to parser combinators, Finch endpoints are easy to reuse, compose, test, and reason about.
All good answers so far. One point in Lift's favor is its RestHelper, which can make it quite easy to write short, elegant API methods. In addition, all the other things you want to do should be quite straight-forward to implement in Lift. That being said, Memcache might be not be necessary.
A little late on the scene but I would definitely recommend using Bowler framework for creation of REST API's. It small, to the point and automatic case class conversion support!