As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am new to Spring Integration .There a few questions I have regarding spring integration
What are some real time scenarios in
which spring integration can be
implemented ?
What is the advantage of creating an
extra spring integratio layer ?
If a mailing system is not
implemented in spring , can spring
integration still be used for
integration ?
Is it something like spring integration can connect two systems developed in two different languages?
What are some real time scenarios in which spring integration can be implemented ?
I would say its best for building an
application using the pipes and
filters architecture, primarily for
intra-application architecture and
design. By intra-application, i mean
'within an application'. It is suited
for intra-application because of the
light-weight pipes(channels) based on
the util.concurrent classes. For
example the DirectChannel is a simple
and logical way to separate two
processing nodes in a workflow without
an overhead of a queue (not the jms
queue).
It does support interaction between
applications through gateways that
adapt to various messaging mechanisms
(like WebServices, JMS etc). So the
application doesn't have to turn to
some other framework for
inter-application interaction either.
What is the advantage of creating an extra spring integratio layer ?
Its useful if you want separation of
concerns, loose coupling and
flexibility.
If a mailing system is not implemented in spring , can spring integration still be used for integration ?
I don't understand the question, sorry.
Is it something like spring integration can connect two systems developed in two different languages?
You mean, interact with another system that's based on a non-java platform? That can be achieved too, but not primarily because of Spring Integration but by using Spring Integration with existing mechanisms for exchanging messages like WebServices, JMS etc. If the requirement is just a point-to-point messaging between 2 applications, Spring Integration is not going to be of much use (unless there is an interesting workflow of sorts in such a dialogue).
And, also, you might check out https://spring.io/blog/2011/02/24/green-beans-getting-started-with-spring-integration which introduces Spring Integration as well as the basic paradigms. It'll get you started and then you can start to make sense of the samples and so on.
The real scenarios are to many to mention. Spring Integration is a framework that allows you to architect message-driven systems based on Enterprise Integration Patterns.
Note, when I say Messaging I am not implying remote messaging such as JMS or anything like that. Messaging first and foremost is an is an architectural paradigm (pattern) which allows you to build loosely coupled and scalable systems such as the one described here: http://blog.springsource.com/2010/03/18/eip-loan-broker-reference-implementation-part-1/
Spring Integration also provides remote adapters (TCP, HTTP, MAIL etc.) to integrate with remote systems. We have many samples that you can go through to get more details http://blog.springsource.com/2010/09/29/new-spring-integration-samples/
I think by going through the articles you'll get the sense of "what is the advantage". ALl I want to state now is that IMO the advantage is the framework itself. By using it you'll spare yourself from writing integration code.
"If a mailing system is not implemented in spring , can spring integration still be used for integration ?" - I am not sure I understand the question. Spring Integration is using JavaMail API to communicate with emails servers (both send and receive). Could you please elaborate?
Related
I am evaluating options for a new messaging system. I have been looking at spring integration, mulesoft and camel. Key to any framework is it's industry footprint and support. I haven't been able to find any good indication of the spring integration module being used widely and searches return blogs and the like from the early 2010s not more recent.
Does spring integration have a significant industry footprint?
Thanks
This survey is a few years old. The framework is still very actively developed and used. One gauge of that would be to look at the question history here. We get several tens of questions per month.
It now has a popular Java DSL and no longer requires XML configuration (although that is still supported for those who prefer it).
Disclaimer: I am a previous project lead and still a committer, but the DZone survey was independent.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am trying to evaluate different web service frameworks for API development in .Net. So far the frameworks I've been looking at are:
ServiceStack
MVC
Web API
NancyFx
I'm trying to find some common talking-points between the frameworks so I know what to look for when picking a framework. The talking points I've got so far are:
The Framework beliefs and principles
The Architecture of the framework (Client and Service side)
The Stack the framework provides you with
The Ease of development within the stack (plugins etc)
End-to-end performance benchmarks
Scalability benchmarks
Framework documentation availability
Framework Support (Cross platform etc)
Pricing
Overall Conclusion
Can anyone think of anything else I should think about? By the end of the research I'm hoping to write about each framework in detail and to make comparisons as to which framework to chose for a given purpose. Any help would be greatly appreciated.
End to End Productivity - The core essence for a Service is to provide a Service that ultimately delivers some value to its consumers. Therefore the end-to-end productivity of consuming services should also be strongly considered as the ease of which Services can be consumed from clients and least effort to consume them, ultimately provides more value to clients which is often more valuable than the productivity of developing Services themselves since the value is multiplied across its multiple consumers. As many services constantly evolve, the development workflow of updating Services and how easy it is to determine what's changed (i.e. if they have a static API) also impacts productivity on the client.
Interoperability - Another goal of a Service is interoperability and how well Services can be consumed from heterogeneous environments, most Web Service Frameworks just do HTTP however in many cases in Intranet environments sending API requests via a MQ is more appropriate as it provides greater resilience than HTTP, time-decoupling, natural load-balancing, decoupled endpoints, improved messaging workflows and error recovery, etc. There are also many Enterprises (and Enterprise products) that still only support or mandate SOAP so having SOAP endpoints and supporting XSD/WSDL metadata can also be valuable.
Versionability - Some API designs are naturally better suited to versioning where evolving Services can be enhanced defensively without breaking existing Service Consumers.
Testability and Mockability - You'll also want to compare the ease of which Services can be tested and mocked to determine how easy it is to create integration tests and whether it requires new knowledge and infrastructure as well as how easy it supports parallel client development which is important when front and backend teams develop solutions in parallel where the API contracts of a Service can be designed and agreed upon prior to development to ensure it meets the necessary requirements before implementation, then the front and backend teams can implement them independently of each other. If the Services haven't been implemented the clients would need to "mock" the Service responses until they have, then later switch to use the real services once they've been implemented.
Learnability how intuitive it is to develop Services, the amount of cognitive and conceptual overhead required also affects productivity and the ability to reason about how a Service Framework works and what it does has an impact on your Solutions overall complexity and your teams ability to make informed implementation decisions that affect performance and scalability and the effort it takes to ramp up new developers to learn your solution.
Spring integration is used to make the communication between two systems easier.
So does that mean the if two systems are talking using JMS queus, then we can remove queues and integrate two systems using Spring Integration Framework?
Looks like you should study more on the matter. I mean EIP-book, Spring Integration in Action or, at least the Reference Manual from Spring IO site.
The main Spring Integration goal is integration and JMS is only one way to do that.
If your two system can get deal with JMS, there is no stops to integrate them using Spring Integration: just provide JMS adapters for boht of them.
As per my understanding,
Spring Integration solution a framework level solutions to Design Patterns listed in http://eaipatterns.com/
I might be an alternate to ESB which is like one big tunnel & everything passes through that.
Spring Integration provides end to end message between different de-coupled, disparate connecting points.
On the other hand JMS is an API in the Java EE spec which can be used in conjunction with Spring-Integration.
You might as well want to read about AMQP which is a messaging protocol.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've been trying to do some research on REST and SOAP web service supporting frameworks for CentOS/Redhat that would also be able to reasonably support a management Web application along side the services themselves.
We haven't determined if REST or SOAP will be the way to go for service communication. The communication requirements are pretty straight forward, so a heavier SOAP interface may not be required. (but wouldn't be complex either)
I've done work with Ruby on Rails in the past (on the side currently) but the technology isn't as familiar to the rest of my group as J2EE would be.
ServiceStack is also interesting (I'm looking into it now) but I've worked on .Net/Mono projects in the past and have run into all kinds of Mono implementation and runtime issues. (I'm sure it's come a long way in the last 2 years, but I'd like to see if there's a better alternative)
Basically I need a stack/framework which supports REST or SOAP, (both would be amazing) and can support a MVC style Web app. The idea is the Web service and Web app would have access to the same database. The Web app would be an end-user/admin management interface, and the Web service would be for remote system/automated access to controlled data.
Finally, about 80% of the application database schema will be predefined and won't follow any MVC style modelling. So a framework which is intended to tightly model the schema data for MVC only use, like Ruby on Rails, wouldn't be preferable as we'd end up having to re-create the Models or write an entirely separate database query handling library which both the Web service and Web app would have to use. It would be great if existing data could be modelled more flexibly. (in case the existing schema changes at a later date)
Sorry if I'm being too generic. (or specific) I'm just interested in opinions. Thanks!
ServiceStack services can be consumed by REST, SOAP or MQ clients
REST and SOAP are different methodologies although ServiceStack's message-based DTO-first approach is the only .NET framework that allows your same service to be called by both REST and SOAP endpoints. Since your ServiceStack web services are pure C# services the same service can also be hosted in an InMemory or Redis MQ Host. (There's also a RCON non-http context host option).
Inherent limitations in SOAP
Although as SOAP routes everything through HTTP Post you need to define your services around this limitation with a new class for every service you want available in your SOAP endpoint. Here's an example of how you would create a REST service that was also available via SOAP.
REST and SOAP are very different in many ways.
REST is an architectural style, SOAP is a protocol. SOAP defines how things communicate, REST defines how the're described statelessly.
I do prefer REST with HATEOAS (Hypermedia As The Engine Of Application State). An application with that architecture exposes resources with specific URIs (like http://example.com/users) and representations (in JSON, XML, HTML, etc) for these resources using content-negotiation (Accept headers on HTTP).
The HATEOS part is the linking between resources, like <a href= on HTML or <link href= on ATOM or JSON Schema for linking in JSON.
A good reference implementation is the Netflix API http://api.netflix.com/. They're awesome.
Frameworks for RESTful implementations are available for several languages. On Ruby, Sinatra is probably the best choice. Flask would be the guy for Python. On node.js, expressjs is getting very popular.
I'm a PHP guy. Of all frameworks I know (including Zend, Symfony, Slim, Code Igniter and many others), the best REST implementation is this http://documentup.com/Respect/Rest. It's the single one that implements content-negotiation in a sane manner. (Disclaimer: I've coded it, my opinion may be biased. Get your own opinion using something like the Litmus Test for RESTful Frameworks http://code.google.com/p/implementing-rest/wiki/LitmusTestForFrameworks).
There is a single case in which I do prefer SOAP communications: when the client consuming my service already uses SOAP for anything else. Consistency wins on this case. Java guys would probably prefer SOAP as well, I believe.
we are building a distributed Java system (should be scalable ;-) ) that is connected only with JMS (ActiveMQ). I studied Spring Integration and I am not sure what the advantage would be if we use it. I think we are better off with using the JMS-Templeate from the Spring Core Project as we send only messages from a JavaService to another JavaService and so on.
Use Spring Integration (or any other framework) if you think the extra abstraction that it buys you is worth the cost. It should give you a more solid foundation on which to build your application. Software written by Spring is better than anything you or I would write from scratch.
All frameworks have a cost. There are additional dependencies. Sometimes greater abstraction can obscure too much.
You should prototype with and without Spring Integration to see if it's worth the cost.
If you're not a Spring user already, I'd recommend that you learn Spring before jumping into a big enterprise project.
SpringIntegration will give your Enterprise Integration Pattens ready to use.
Are you going to need splitters, routers, filters, gateways, aggregators, transformers, etc?
If the answer is no, go for plain Java+ActiveMQ.
If you need a really powerful system integration tier, then you should use Spring Integration - it's an additional level of abstraction which may help when your system will grow. With SI it's a matter of seconds to add new integration processing rule between two systems.
From the other hand, I've worked on some SpringIntegration+ActiveMQ project, and it was almost impossible to configure this broker to work with SI in the reliable way. So if you decide to use SI I'd recommend HornetQ as a JMS broker - this one works fine.