i am using activiti-5.21.0. i have another application deployed on apache-tomee-plus-1.6.0. let say: user apply for leave from this application.
Then i want to create activiti process for college staff to approve leave.
what approach should i use? can we create activiti process remotely from another application?
Yes you, can: those are two different process definitions.
You got a few options, depending on what you mean with 'i am using activiti=5.21.0'. Let's assume you're using Activiti as an embedded library (you simply included the jar). The main thing you have to keep in mind is that in this setup, there is no 'activiti server', you have an embedded engine that connects to the same datasource. You could
use the same database, but have two different applications. In this case, you need to configure the process engine to use the same database. Simply deploy your second process definition to the engine. Also you have to make sure that users from application A don't have access to the process definitions from application B. That's something you will have to add yourself in your own application logic.
use another database, one per application. This could make your logic easier, but of course you've got now two schema's to 'maintain'.
if you going to have more application to use activiti, you could consider for activiti server. All interaction via rest service and future upgrade will be easy
Related
I created a simple two-player game (Connect 4) with a Java/Spring backend and React.js frontend. I understand it would be simpler to create the entire app in React, but I’m studying Java development and decided to learn React to demonstrate my understanding and create a portfolio website.
I’m struggling to decide how best to deploy the app. I deployed the backend on its own to GC App Engine. After a few false starts it eventually worked. However, if I visit the project url from two separate browsers/devices, both devices are looking at the same instance of the backend, i.e. two individual users are looking at the same ‘game’, which is not what I intended.
What is the best approach to deploy the front & backend so each user is playing their own individual game?
This is literally my first foray into any kind of web development, so I may have bitten off more than I can chew.
Thanks.
I would suggest you use multiple services on your project. You can either use the same deployment command for deploying or updating the services that make up your application.
services in App Engines behave like microservices and therefore you can deploy multiple services to run as a set of microservices.
Here are the requirements for deploying multiple services:
You must initially deploy a version of your application to the default service before you can create and deploy subsequent services.
The ID of each of your services must be specified in their corresponding app.yaml configuration files. To specify the service ID, include the service element definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to the default service.
You can deploy one service as frontend and the other as backend.
You can check this documentation on services for additional information.
I looked at the documentation regarding services but I still don’t understand their use in the context of my problem. I may have misunderstood your explanation, but I don’t think I explained my problem clearly. Having looked at the documentation, my use of the word ‘instance’ is not the same as an app engine instance.
It would make sense to me to have two services in my project; one for the backend and one for the frontend. To solve the problem of each individual player interacting with the same backend API, and so unwittingly interacting with the same single Connect4 game, generating multiple services would not be a solution. Is my understanding correct?
The comment from NoCommandLine on my original post is probably a better description of what I want to achieve.
I have a Spring web application that consists of the following parts:
Web GUI for Users
Background processes
Webservice-like API
It's all in one application. For every update, the whole application has to be stopped and redeployed, which of course means that all users are kicked out and the API is temporarily unavailable.
I am wondering whether there a ways to seperate the application into several applications/services which could be deployed seperately. All applications would need access to the DAOs and to several utility classes/services.
I know there will be no ready-made solution for this. But maybe you can show some 'best practice examples' or show me some direction where I could go.
But if some part of the application is offline while redeployment, the complete application will not work, so this is likely that the split is not the solution.
If the problem is just that the users session is killed, then you should have a look at values stored in the session that are not able to been serialized.
If your probem is that the application is offline for some time, then you need a second server and some switch (loadbalancer) to implement a blue-green-deployment
If I had an application that stored information in its datastore. Is there a way to access that same datastore from a second application?
Yes you can, with the Remote APIs.
For example, you can use Remote API to access a production datastore
from an app running on your local machine. You can also use Remote API
to access the datastore of one App Engine app from a different App
Engine app.
You need to configure the servlet (see documentation for that) and import the appengine-remote-api.jar in your project (You can find it ..\appengine-java-sdk\lib\)
Only remember that Ancestor Queries with Remote APIs are not working (See this)
You didn't mention why you wanted to access the datastore of one application from another, but depending on the nature of your situation, App Engine modules might be a solution. These are structurally similar to separate applications, but they run under the same application "umbrella" and can access a common datastore.
You can not directly access datastore of another application. Your application must actively serve that data in order for another application to be able to access it. The easiest way to achieve this is via Remote API, which needs a piece of code installed in order to serve the data.
If you would like to have two separate code bases (even serving different hostnames/urls), then see the new AppEngine Modules. They give you ability to run totally different code on separate urls and with different runtime settings (instances), while still being on one application sharing all stateful services (datastore, tasks queue, memcache..).
I am working on a desktop Java application that is supposed to connect to an Oracle database via a proxy which can be a Servlet or an EJB or something else that you can suggest.
My question is that what architecture should be used?
Simple Servlets as proxy between client and database, that connects to the database and sends results back to the client.
An enterprise application with EJBs and remote interfaces to access the database
Any other options that I haven't thought of.
Thanks
Depending on how scalable you want the solution to be, you can make a choice.
EJB (3) can make a good choice but then you need a full blown app server.
You can connect directly using jdbc but that will expose url of db (expose as in every client desktop app will make a connection to the DB. you can not pool, and lose lot of flexibilities). I would not recommend going this path unless your app is really a simple one.
You can create a servlet to act as proxy but its tedious and not as scalable. You will have to write lot of code at both ends
What i would recommend is creating a REST based service that performs desired operations on the DB and consume this in your desktop app.
Start off simple. I would begin with a simple servlet/JDBC-based solution and get the system working end-to-end. From that point, consider:
do you want to make use of conenction pooling (most likely). Consider C3P0 / Apache DBCP
do you want to embrace a framework like Spring ? You can migrate to this gradually, and start with using the servlet MVC capabilities, IoC etc. and use more complex solutions as you require
Do you want to use an ORM ? Do you have complex object graphs that you're persisting/querying, and will an ORM simplify your development ?
If you do decide to take this approach, make sure your architecture is well-layered, so you can swap out (say) raw JDBC in favour of an ORM, and that your development is test-driven, such that you have sufficient test cases to confirm that your solution works whilst you're performing the above migrations.
Note that you may never finalise on a solution. As your requirements change, and your application scales, you'll likely want to swap in/out the technology most suitable for your current requirements. Consequently the architecture of your app is more important than the particular toolset that you choose.
Direct usage of JDBC through some ORM (Hibernate for example) ?
If you're developing a stand-alone application, better keep it simple. In order to use ORM or other frameworks you don't need a J2EE App Server (and all the complexity it takes with it).
If you need to exchange huge amounts of data between the DB and the application, just forget about EJBs, Servlets and Web Services, and just go with Hibernate (or directly with plain old JDBC).
A REST based Web Services solution may be good, as long as you don't have complex data, and high numbers (try to profile how long does it takes to actually unmarshal SOAP messages back and to java objects).
I have had a great deal of success with using Spring-remoting and a servlet based approach. This is a great setup for development as well, since you can easily test your code without deploying to an web container.
You start by defining a service interface to retrieve/store your data (POJO's).
Create the implementation, which can use ORM, straight JDBC or some pooling library (container provided or 3rd party). This is irrelevant to the remote deployment.
Develop your application which uses this service directly (no deployment to a server).
When you are satisfied with everything, wrap your implementation in a war and deploy with the Spring DispatcherServlet. If you use maven, it can be done via the war plugin
Configure the desktop to use the service via Spring remoting.
I have found the ability to easily develop the code by running the service as part of the application to be a huge advantage over developing/debugging something running on a server. I have used this approach both with and without an EJB, although the EJB was still accessed via the servlet in our particular case. Only service to service calls used the EJB directly (also using Spring remoting).
I'm working on a Java Web Application with Wicket, Spring and Hibernate. The web application is not particularily large (I have one DAO and one service), but I'd like to offer the users that deploy the application a startup wizard much like the ones found in Wordpress.
When the webpage is accessed for the first time (no database tables are created / no users), I want the user to be able to enter database settings (username, password, database name, database type) and then I want the web application to create all the tables that it will use.
As I'm new to Wicket and Java Web Development I'm not sure how one would go about achieving this. Usually, when interacting with the DAO (such as creating a user) the database table is created on demand (if it didn't already exist) -- at least that's what it looks like to me.
Is there a way to extract the SQL for mye domain objects that my application will use via the service->DAO layer?
Right now I configure database access via filters; src/main/config/application-DEV.properties for example. If I want to use a wizard such as described I guess I would need to move away from using property files?
Any help is greatly appreciated.
I have often contemplated this, as it is standard practice in many PHP / Perl systems, but seems complicated in java / spring etc.
First of all: use wicket-extensions for the wizard functionality
What I would do then is simple, I'd declare all my spring beans as lazy and use system properties to configure them (with a PropertyPlaceHolderConfigurer). I'd use the wizard to get those properties the first time and then write them to a well-known location in the file system (DB would be better, but that's a chicken / egg problem). Then I'd initialize the application context using the system properties.
The problem here is: I don't think there is a portable way to access the file system from a web application, I think every app server may handle file system access differently, so you need to be careful there.