We are analyzing different concepts for one of my projects. We decided to use Spring Boot & Microservices architecture.
After further discussions, we came to a query whether we CAN/SHOULD use Spring AOP to resolve cross cutting concerns of various microservices?
If not how can we address common concerns of microservices like logging, transaction mgmt, etc?
I have googled this topic extensively (even went to 5 pages for same search), but no luck. Any help appreciated.
Use Spring interceptors. They have interceptors and factories for just about anything. Lets you add instrumentation and common code to all aspects.
UPDATE: samples interceptors and factories.
ClientHttpRequestInterceptor
FilterRegistrationBean
SimpleClientHttpRequestFactory
ChannelInterceptor
I don't think that there is anything to worry about using AOP. This is how Spring does things usually under the hood.
I'd just be careful with logging method invocations, especially parameters which is the common use (abuse) of AOP.
Ususally the less code you write the better. If you can use standard, proven way of doing things - use it.
Related
Suppose I have some third party library and I want to integrate it with Spring in order to be able to use it as a part of Spring transaction. I didn't find any relevant information on the Internet and looked into the source code of integrations of RabbitMQ and MyBatis libraries. As I understood from their source code I should implement org.springframework.transaction.PlatformTransactionManager and interact with TransactionSynchronizationManager. And there are two questions:
How Spring "know" about and instanciate implementations of PlatformTransactionManager?
Suppose there are two resources been used in transaction through RabbitTemplate and
JdbcTemplate. What will be first committed - changes in database or
messages sent?
Also, I would be really appreciate if somebody point me out to some guide or book about interactions with Spring internals.
You have to instantiate them yourself, like a DataSourceTransactionManager or a HibernateTransactionManager. Spring Boot does that for you under the hood, but with plain Spring you need to do it yourself.
What you want are distributed transactions (XADataSource), which are not possible with RabbitMQ.
For RabbitMQ you should read this here first: https://www.rabbitmq.com/confirms.html . Then make sure you understand transactions on the JDBC side. Then you can reason about how they both work together.
For the Java side, you might enjoy this book entirely about transactions: https://www.marcobehler.com/books/1-java-database-connections-transactions
What the terms added into the AOP, so that we are calling it Cross Cutting Concern.
Difference between Interceptor and AOP.
-This question is for lil bit discussion on AOP and Interceptor but please elobarate.
Interceptors are part of Spring framework which allow you to write logic by intercepting requests/calls in between the route. There are mainly 2 kinds of Interceptors in Spring.
Handler Interceptors, present in Spring MVC framework, are used to include your interceptor logic for web requests, whereas Method Interceptors, within Spring AOP framework, are generic in nature and not just limited to intercept HTTP requests.
When comparing AOP with Interceptors, I can say, in one line, that these Method Interceptors are the base understanding behind writing aspects in AOP.
AOP, aka Aspect Oriented Programing, is a bit complex subject to be explained in a StackOverflow answer. I would suggest you to read for it on internet and make yourself comfortable with the basics & AOP terminology before entering into Aspect Oriented Programing.
Below is one good resource to understand the dynamic proxy in Spring AOP and fundamentals of it.
Understanding Dynamic Proxy: Spring AOP Basics
Update
Wikipedia has a very simple yet effective definition & example for Cross-Cutting Concern.
In Aspect-oriented software development, cross-cutting concerns are
aspects of a program that affect other concerns. These concerns often
cannot be cleanly decomposed from the rest of the system in both the
design and implementation, and can result in either scattering (code
duplication), tangling (significant dependencies between systems), or
both.
For instance, if writing an application for handling medical records,
the indexing of such records is a core concern, while logging a
history of changes to the record database or user database, or an
authentication system, would be cross-cutting concerns since they
touch more parts of the program.
AOP with Spring Framework is described in a very simple manner at this article of TutorialsPoint which would help you get familiar with all the basic terminologies of Spring AOP.
We have a spring boot application that is growing in complexity because of integration needs - like send an email after you do this, or broadcast a jms message after you that etc. In looking for some higher level abstractions, I came across apache camel (haven't used camel ever before). The question that I have is what do I do with the spring boot application? The application has the standard spring controllers, services and uses spring-data for connecting to databases. I didn't find much help online on how to merge camel into a spring-boot restful application. Is that even something that is doable or is camel a completely different beast that the spring boot won't fit?
I did read that Camel tightly integrates with Spring, but still I didn't know if 1) Spring Controllers are still something that can be used along with Camel 2) If I can call the other spring beans from camel routes and whether I can call invoke a camel route from a spring bean (sorry if these sound like camel newbie questions to the experts)
As an example of what we have to do:
After finishing writing anything to the database about an order, we have to send an email out to the order processing department
If someone deletes a particular user address, we have to send to a jms topic so other applications can take action.
Every http request is coming in through the Spring MVC stack today.
Is there a way to "hand-off" the processing to camel after a particular task is complete? (like writing the order to the database successfully via the Spring MVC stack and hand off to camel to send a jms message and do other things)? Or should we completely replace Spring with Camel?
Not sure what the right path is. Can someone please guide us?
This question is slightly old, but though it was worth mentioning here that Apache Camel now includes a Spring Boot component.
Details can be found here
http://camel.apache.org/spring-boot.html
and they document an example here
http://camel.apache.org/spring-boot-example.html
Follow this for the current best practice in camelising a spring boot application!
One option is to
1> define camel routes either in Spring DSL or Java DSL or other means and define it in Spring Application context.
2> And have a class that implements ApplicationContextAware and cache the Spring ApplicationContext in a Static Variable.
3> For #Controller we can get this static variable and get hold of ApplicationContext .
4> With the camel context ID we can do a getBean from ApplicationContext.
5> This is the instance of DefaultCamelContext,with this we can do a createProducer and call camel routes from #Controller.
Like some others mentioned, spring-boot-camel (but use spring-boot-camel-starter as your dependency) works very well and it is really easy to set up. When you annotate your RouteBuilder extensions and your Processor implementations with #Component, they wire up directly into the context and you are good to go. Then, you can #Autowire a CamelContext or a ProducerTemplate into your classes and use them as necessary.
You asked about how Controllers can work with Camel, and if you #Autowire any of the things you need (probably a context or a producer template), then the answer is a definite "yes" that you can use them together quite easily. And when you use spring-web, your context will start and remain running without any additional configuration, etc.
Like Matthew Wells suggested, the links will get you pointed in the right direction. If you, or others on your team, are at all familiar with Camel, then it will be very easy for you to do what you need to do. But, ah, I notice that this question is from 2014, and you're probably well past the point of your question. At least if anyone else stops by this thread, they will have plenty of information to get going. If you come by and re-visit your question, please let us know how it went for you, and what you ended up doing. Cheers!
What is the Difference between Spring IOC and Spring AOP and their Importance ?
Have you searched the web for IoC and AOP? There are a lot of references to both.
In a nutshell, IoC allows an external force to determine what implementation will be used by code rather than the code determining the implementation. The "external force" might be a configuration file, a unit test, other different code, etc.
AOP allows cross-cutting concerns to be implemented outside of the code affected by those concerns.
The "purpose" of Spring includes IoC and AOP, but goes quite a ways beyond that in its scope.
For more details please check.
Inversion of Control Containers and the Dependency Injection pattern and
Aspect-oriented programming
Also check this
What is AOP, Dependency Injection and Inversion Of Control in Simple English
IoC, AOP and more
Spring IOC: In simple answer normally you create object with new operator and set yourself for getter and setter. So, yes we use new operator in Java to create object. There is no any bad in doing this. But, when your project size grows and lots of developers are working, and you want to achieve POJO-based programming, you can use DI. So then maybe your question arises - why I can not code it myself? Of course you can use the power of reflection, annotation, and XML. But, some other had already coded this then why not reuse the third party one? There are lots of options for you to choose; Spring can be the best one. It manages your object life cycle from object creation to its destruction. You use the objects created and set by Spring DI container but you do not create them yourself.
Spring AOP: It is related to cross cutting concern. What it mean is in large system the common functionality is scattered throughout different modules. So AOP provides an easiest way to take out a common implementation in the form of 'aspect'. You can also in this case write own implementation using proxy concept but you can reuse the code of proxy based that is implementation of APO alliance using Spring.
Objective of Spring IOC is to reduce explicit dependencies between components, while purpose of Spring AOP is to wire components together possibly by enforcing certain common behavior (read: NOT Interface)
Since purpose of Spring AOP is to enforce certain behavior across components.So, Spring IOC comes in handy to achieve this purpose
Spring is a popular framework, however I have difficulties to see in which situation the framework would actually help.
Currently I'm using the following:
* Tomcat
* Jersey
* Jackson
* Hibernate
Together this results in a Webservice, created by annotations, automatic JSON (un)marshalling and a comfortable Object/Relational Mapping.
So honestly at the moment I'm not missing anything, but I might just not know what great thing I'm missing... Could you help me out with this?
Thank you
Spring is a big framework providing a lot of functionality. It's hard to talk about advantages without knowing what functionality are you trying to use in the project.
Most probably you talk about Spring as an IoC container. It is very important part of Spring, but there is also AOP, transaction management, JDBC abstraction layer, authentication and authorization, testing and some more.
In a nutshell, Spring offers you uniform way to control dependencies between your objects. This is called inversion of control or dependency injection. Using it you can create pluggable, testable code that is easy to maintain.
In addition it gives you gazillion utility classes that just make life easier. For example, Hibernate is much easier to maintain via Spring facilities. It kind of brings together many different technologies under the same roof.