Andy McCright

Author
+ Follow
since Oct 28, 2021
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Andy McCright

That's a good question - and perhaps Emily can provide a more complete answer.

My take is that the vendors involved in the overall project (1) don't want to bloat the overall specification and (2) don't agree that those APIs/sub-specifications are essential enough to be part of the overall specification.  MP Context Propagation probably should be in the overall spec group - but instead it is transitioning to the Jakarta community to be part of Jakarta Concurrency.  I think this makes sense - and ideally, Jakarta Concurrency will be part of the overall MP spec.  So unless things change, I do foresee MP Context Propagation making it into the overall spec - just in a roundabout way.

As for Reactive Messaging (and the Reactive Stream Operators project that it depends on), I don't know why it's not part of the overall spec - but I suspect that the vendors involved see Reactive Messaging as somewhat niche and want to see more adoption before including it.  I think that that may also be the case for MP GraphQL and LRA.

If you'd like to voice your opinion on what should be included in the overall spec - or offer feedback on any of the specs, you can join the mailing list (Google Group) at: https://groups.google.com/g/microprofile
2 years ago

I'm reading the Microprofile 4.1 presentation from the MicroProfile home page. In slide 6 , Quarkus is included in MicroProfile implementation. I thought Quarkus is one of the framework for Microservice , just like Spring Boot ?



Yes, Quarkus is a microservice framework, but it also is an API provider (like Open Liberty, Wildfly, Helidon, etc.).  Quarkus is a little unique in the MicroProfile world - it has super-fast start time (especially when paired with the GraalVM), but (afaik) it doesn't completely implement the CDI specification which is a requirement for MP certification.  I haven't followed the conversation, but there has been a lot of discussion on whether or not Quarkus should be listed as a compatible implementation or not.  From my somewhat-limited understanding, Quarkus's greatest strength (fast startup) is also it's greatest weakness (limited ability for dynamism) since it basically tries to replace all reflection/introspection/etc. at build time.

I'm curious how can it be implemented together with MicroProfile ? Does your book covered that ?



For the most part, everything in the book can be accomplished with Quarkus.  I haven't tested it myself, so there's always the possibility of something not working - or something behaving differently, but the goal of MicroProfile (and the book) is that you should be able to run the same code in any compatible implementation.  Quarkus may document any limitations, but for the most part, I think the book will work for you.

Also one thing, the project links for Microprofile 4.1 presentation in  Eclipse website is broken.



Oops! It looks like somebody removed the "presentations" directory and replaced it with "resources", so I updated that link to point there. Thanks for spotting that!
2 years ago
There's definitely some overlap.  I'm not a Spring expert, so I can't say that all features in one are in the other. I have done some research into things like JAX-RS vs Spring MVC REST: my take is that they can both do effectively the same thing. I personally like JAX-RS better, but I've worked with JAX-RS longer so I know more of the best practices.  Spring is pretty great too.

One thing that I'd mention is that you can mix and match Spring with MicroProfile (and Jakarta EE).  For example, Open Liberty has a guide[1] for deploying a Spring Boot app - that would enable you to pick and choose from all of the APIs to find the one that best suits your needs.

[1] https://openliberty.io/guides/spring-boot.html
3 years ago
Short answer: it's like Java EE's baby brother.

Longer answer: After Java EE 8, it seemed like Oracle had basically given up on Enterprise Java.  Other frameworks (like Spring) were continuing to innovate and build more cloud-native features, while Java EE stagnated. To correct this, a few companies (IBM, RedHat, Tomitribe, Payara, and probably others that I am forgetting...) got together to create a "Micro" profile (Java EE has the concept of "full" profile and "web" profile) - so the idea was that this would be the minimum set of technologies necessary to build modern cloud-native services.  At first it just included EE technologies (JAX-RS, CDI and JSON-B/JSON-P).  But then it started creating its own technologies.  These include: MP Health, JWT Propagation, Metrics, Fault Tolerance, Config, Rest Client, OpenAPI and Open Tracing.  So, much like Java (now Jakarta) EE, when you deploy to a MP-compliant framework (like Open Liberty[1], Wildfly[2], Payara[3], or TomEE[4]) your application can take advantage of these APIs and features.

There are also some standalone MP technologies that are not part of the "profile" but many vendors have chosen to implement - they include: MP GraphQL, LRA (long running actions - basically a cloud-native transaction spec), Context Propagation, Reactive Streams Operators and Reactive Messaging.  

In general, MicroProfile works quite well with other Jakarta EE technologies.  For example, a colleague and I wrote a sample[5] and presentation[6] on using MP GraphQL with JPA.  

If you'd like more information, I'd suggest checking out the MP home page[7] - which has links to presentations about the overall and individual projects, how to use it, what other vendors are involved, how to get involved, etc.

[1] https://openliberty.io/
[2] https://www.wildfly.org/
[3] https://www.payara.fish/solutions/eclipse-microprofile-and-the-payara-platform/
[4] https://tomee.apache.org/
[5] https://github.com/OpenLiberty/sample-graphql-jpa
[6] https://www.youtube.com/watch?v=RzrkjuA3LvU
[7] https://microprofile.io/
3 years ago
Multi-vendor support is definitely a huge benefit for MicroProfile. Like Java EE (now Jakarta EE), you can easily port your application code from one vendor to another with very little changes (I'd like to say that no change necessary, but the reality is that specs are imperfect so there will usually be something that vendor A does a little differently than vendor B - for that matter, those differences might be the reason for choosing one vendor over another...).

Other than that, I'd say that the technologies themselves are beneficial.  I work primarily with the MP Rest Client (a type-safe client similar to Spring's REST template) and MP GraphQL (an annotation-based GraphQL implementation).  The Rest Client addresses some of the gaps in Jakarta's JAX-RS - making it easy and more-domain-friendly to consume remote services.  MP GraphQL takes concepts from JAX-RS (or Spring MVC REST) to build services that address gaps in REST itself.  I'd definitely encourage you to check out these technologies if you are not familiar with them - we also cover them in detail in the book.

Aside from those technologies, MP has a lot of cloud-native technologies that Java/Jakarta EE has needed for some time.  MP Config allows you to customize your application and the server framework from sources like Kubernetes.  MP Metrics enables you to instantly see performance-related details from your services - and it comes with APIs that you can use in your app to track even more details.  MP Health enables plug-points with Kubernetes so that it knows when to route traffic to your VM.  MP Fault Tolerance provides APIs for handling outages of local and remote resources - circuit breakers, bulkheads, etc.  MP OpenAPI is basically a vendor-neutral version of Swagger that allows you to easily document your services' RESTful endpoints. All good stuff!

If you have any questions on anything in specific, please let me know. - thanks!  - Andy
3 years ago
Thanks for having us! I'm looking forward to answering questions - awkward or otherwise!
3 years ago
Hello Code Ranch!

I am one of five co-authors of the recently released book, Practical Cloud-Native Java Development with MicroProfile published by Packt. This book is intended for developers - and it really is practical.  One of our authors is a consultant who has developed a real-world sample application to demonstrate how to build cloud-native microservice architecture using MicroProfile technologies.

If you are not familiar with MicroProfile, it grew out of a widespread need to build truly cloud-ready services - those needs were not being met by Java EE at the time, so many of the EE vendors got together and created MicroProfile.  It has a powerful set of APIs and specifications that build on a core set of Java EE (now Jakarta EE) technologies. If you'd like to know more, please let me know.  I'm hoping my co-authors will also chime in as well.  

If you want to pick up a copy of the book, it is available at https://www.amazon.com/gp/product/1801078807

Thanks!

Andy
3 years ago