I want to start developing enterprise grade applications using spring stack.
to increase the productivity and to compete in the market, I would like to use RAD tools. I found spring roo, but for me, it looks like, it is suitable only to build simple crud based applications. Not suitable to build applications with custom UI. Can you please let me know, can we build any enterprise grade application using ROO or it is not suitable for enterprise grade applications.
Related
Not sure how testting process is carried out for .Net based webapplications. Manually and also automation
Preparing for an upcoming interview but no resources available for that
We own a product written in .NET and that uses MS SQL Server. We need to write a new Integration layer that allows integration with a number of third party applications such as Jira, ServiceNow etc. Our endeavor is to use a Microservice based architecture for this integration later and not use an iPaaS or Centralized ESB. Questions are:
Can I embed Mule into a .NET Microservice?
If no, can I embed Mule into a Java Spring Boot application?
In either of the cases above, am I forced to use any other platform/ software from Mulesoft (such as the Mulesoft's Management Plane)?
Does Microservce based embedded Mule provide capabilities for performance/ health monitoring etc.?
Does Mule support writing any custom code in .NET?
Please find the answers below:
Can I embed Mule into a .NET Microservice?
No. Mule 4 is a Java application and currently is not meant to be embedded.
If no, can I embed Mule into a Java Spring Boot application?
No. Mule 4 is not distributed as an embedded Java library.
In either of the cases above, am I forced to use any other platform/ software from Mulesoft (such as the Mulesoft's Management Plane)?
No. You can run Mule as a standalone service or application without using MuleSoft's Control Plane. Be aware that you will lose all management features from the platform.
Does Microservce based embedded Mule provide capabilities for performance/ health monitoring etc.?
Please define to what you refer as "Microservice based embedded Mule". If you mean in the scenarios mentioned in questions 1) or 2) then the answer is no, because those are not valid deployment options for Mule 4.
Does Mule support writing any custom code in .NET?
Yes. There is a .Net Connector to execute .Net code from a Mule application. Look for the last release in the release notes.
I want to understand what are the benefits of using Apigee if i already have Layer7 in place? please let me know if which is better and why.
Apigee is a very 'developer friendly' API management platform.
Layer 7 has also API management functions.
With the newest version of Layer7 (spring 2017) the API management functions have improved drastically.
Older version of Layer7
If you have (an older version) of the Layer7 platform running in order to create your public APIs, and you need a full set of modern API management functions, you can choose to either upgrade Layer7 or add Apigee on-top.
Api management team
Another reason could be "separation of concerns" combined with "Conway's law". One department (or set of product teams) can deliver the APIs, the other teams can manage them. API management requires all kind of governance tooling an processes. If it is a small team that does the API management for your company (e.g. create the proxies, give support to external developers, maintain the developer portal) Apigee might be a fast and less complex alternative to Layer 7.
Connectivity
If the Layer7 platform has no external internet connectivity yet, the addition of a separate API management platform might be the fastest choice in an enterprise environment. You could to go for a separate Layer7 setup (separation of concerns) with the latest version (or go SaaS). This can leverage the Layer7 knowledge in your company. If the API management team has no Layer7 knowledge, Apigee could be a better choice because of its simplicity (Conway's Law).
We're planning to develop a web based Healthcare Practice Management System. Due to HIPAA we're requested to deploy the app in our own premises. Our company is relatively small currently we have only software engineers and no devops engineers but still we want to develop the application to support horizontal scaling(adding more servers).
Planned to use:
Python3 (Django)
PostgreSQL
I'm looking for something like AppScale but with the freedom of choosing our own runtime, database and frameworks.
In other words from the software engineer's perspective:
Should provide an easy way to deploy django application
Should have web based dashboard to monitor and control(like AppScale)
Should make load balancing simple (app and database)
AppScale implements the Google App Engine APIs which, IMHO, make it super easy to develop web apps quickly and efficiently.
On top of that, you get auto-scaling, load balancing, and the ability to deploy on-premises and plug in any third-party library you need.
AppScale already comes with a dashboard and will soon be launching a new management service for your AppScale deployment(s).
If you're not particularly hung up on Python3 and PostgreSQL, all of the above seem to cover your requirements.
It's worth noting that opting for the GAE model means you opt for NoSQL and, so, postgres is probably not the best option.
Disclaimer: I'm part of the AppScale team and we're already helping companies develop and deliver their apps in the HIPAA compliance realm.
I chose Kubernetes which is a container orchestration technology specifically designed for Docker and also found that scaling is not just the responsibility of platform that the app is deployed on but also its depends on how the app is designed and coded. For that The Twelve-Factor App methodology is really helpful.
But I can't deploy database on Kubernetes because its not recommended by Kelsey Hightower(author of Kubernetes Up and Running) in his talk. So, for now I chose to deploy my database on a VM.
I am starting to plan a new platform which needs to integrate various services from various externals platforms. Essentially I'm tying together a bunch of internal, homegrown services and several outside services we license from 3rd parties.
Generally speaking the external services are all web services but they are a mishmash of REST, SOAP and XML-RPC.
Some of our internal services have REST API's but there are many things that aren't so easy: XMPP, Hessian, custom socket protocols, Java RPC, uWSGI, and the list goes on.
From my research it seems like an ESB like Apache ServiceMix might be a good fit for my needs. However it looks REALLY complex. I'm not launching rockets but I do need transactional messaging (mostly for eCommerce and entitlement stuff). I feel like the message queue ServiceMix uses under the hood (ActiveMQ) might be enough on its own.
Can anyone explain what ServiceMix provides above and beyond ActiveMQ? I know there is a lot but it is hard for an ESB n00b like me to really grasp the tangible difference when I'm waste-deep in buzzwords.
Thanks!
ServiceMix is an OSGi based container that allows you to deploy and run applications in a controlled runtime environment (like a J2EE container but less heavy weight and without programming to e.g. J2EE contracts).
Thanks to OSGi you can partition your applications into parts and update/evolve these parts independently from each other. You can upgrade parts of your application without having to take down the entire application. There is far better life cycle management in OSGi then you get with standalone Java processes.
If you think of creating an application that will evolve over time, then OSGi is something you should consider. And ServiceMix provides you a runtime OSGi container to deploy your applications to. I highly recommend the book "OSGi in Action" from Manning.
For tying together different external services that might even use different transport protocols I recommend Apache Camel, which btw also deploys nicely into ServiceMix.
Btw, existing applications can be deployed into an OSGi container with fairly little effort (without requiring code changes).
Torsten Mielke
FuseSource
Web: www.fusesource.com
Blog: http://tmielke.blogspot.com