I'm going to develop a map server with my own logic and entities. It will have postgres database, user management, specific layers with certain types, WFS, WMS, etc.
I'm going to use springframework and GeoServer as the GeoServer is an open source project. My question is whether I develop it or use it as a separated server? How about the user management problem? How can I integrate my own project security with the geoserver?
Typically you develop a front end that's completely separate and have GeoServer offer the OGC services to it and other clients. In case you need to customize it, GeoServer has a fully pluggable architecture, e.g., you can build a version of it that has more or less modules than the standard one, your own security subsystem, your own custom data sources, and so on, a lot can be either configured or replaced, so I'd suggest you look into those options.
Mind one detail, GeoServer is GPL'd, so any code you develop that depends on GeoServer API will similarly be GPL'd. If instead you develop something that's only based on GeoTools (e.g., a custom data store) that part can be closed source.
Related
I made a GAE-Project with JPA2 for db access. I store some Strings which are more than 500 Characters, so I use com.google.appengine.api.datastore.Text.
I got an interface Script.java which defines the value as String, and an ScriptImpl.java which has internally a Text member, and converts for getting and setting.
Because one requirement of the project is, that it is still able tu run on an simple tomcat with a database behind. So it must be possible to run inside and outside the google environment.
Is there some realistic way to implement my application so I can switch to a normal tomcat environment (e.g. via a spring configuration to use different beans...).
What else do I have to pay attention to to make this work in both environments and how do I take care of the parts that are seamed thight to GAE?
Update: So far I found the following critic issues: Google User Service & Login Process, Text Class in Domain Models, Wicket-GAE-Initializer (since I use Wicket)
GAE has it's own proprietary API. If you wrote application using this API then if you want to move off of the GAE you have two options:
Rewrite your code, obviously.
Use a API wrapper that implements GAE API but runs on other platforms. An example of such wrappers are AppScale and CapeDwarf. AppScale is older and probably more mature and supports both Java and Python. Also it supports more platforms (private servers + clouds). OTOH, CapeDwarf is targeted at JBossAS7, so it's probably better fit if you use that server (or OpenShift cloud). Also I guess you can expect better support from a mature open-source leader such as RedHat.
While in theory it might be possible to wrap GAE functionality and then delegate it to either app engine or your "normal" environment it's probably a lot of effort.
Possibly another approach would be easier. Are you aware of CapeDwarf?
JBoss CapeDwarf
Deploy and run your Java App Engine applications on your own private
JBoss Application Server (AS7) cluster or on RedHat’s OpenShift cloud.
JBoss CapeDwarf is an implementation of the Google App Engine API,
which allows applications to be deployed on JBoss Application Servers
without modification. Behind the scenes, CapeDwarf uses existing JBoss
APIs such as Infinispan, JGroups, PicketLink, HornetQ and others.
If it really needs to be "simple tomcat with a database" then more information or constraints will be helpful to know.
I am looking at the Java Portlet API for the first time and trying to decide on whether or not to consider using it.
From the look of things, it looks like a technology that might be considered old school because i seem not to see very current references of its usages.
My question is, would you consider using the Java Portlet API, more so when you are planning to develop an integrated web application consisting of modules that may themselves be separate applications of their own.
Yes
Normally we go for a Portal application (using Portal API) in scenarios like this:
Multiple application(Portlets) in same page.
Multiple applications in separate pages but uses same Login(or User credentials).
Multiple applications which communicate to each other in same page or in different page.
These are just highlevel thoughts. Based on the application and available server stack, the Portal server can be chosen IBM Websphere Portal / Liferay / Weblogic Portal.
Portals are good at providing a common set of services, such as security and UI, to wrap around several applications that have a need to either pass information between them, or a need to be utilized as part of a similar process.
It's worth noting that there is also the JBoss Portal Platform, in addition to those above.
Also, there is a new version of the Portlet specification currently in development: http://jcp.org/en/jsr/detail?id=362
I have written a relatively simple Java App Engine application which I would like to be able to port to another cloud provider.
I am using the JDO datastore API so I think my data handling should be portable to other backends as listed here: http://www.datanucleus.org/products/accessplatform/index.html
I would ideally like to deploy my application onto EC2 with minimal code changes. What is my best approach?
Note: I am aware of the http://code.google.com/p/appscale/ project but I want to avoid using this as it doesn't look like they are updating very often.
AppScale remains your best option to avoid rewriting any code. They do keep up to date with official App Engine - for instance, they just released preliminary support for Go. Even if they weren't so assiduous at keeping up to date, though, this would only be relevant if some feature you required wasn't yet supported - and it sounds like your needs are fairly basic.
JDO should be trivial, there might be some Google specific configuration here and there but generally it should be easy. The storage model Google promotes is not bad for RDBMS either, but you might need to fine tune your model depending on the backend you end up with.
If you're not using the low-level Google APIs, you should be pretty much there.
I managed to get my application working on EC2 using the following components.
Tomcat 7
Datanucelus
HBase
I had to manually create a table in HBase for each of my data classes but was able to configure Datanucleus to auto create the columns.
I also had to change my primary key value generation strategy from identity to increment as per this table of supported features.
http://www.datanucleus.org/products/accessplatform_3_0/datastore_features.html
We have a desktop java application (image-processing) that is working great, now we have to add a client/server architecture using Java EE plateform.
We must use also MVC, and interacting with many other libraries like JDOM, JMatlink(MATLAB), and calling some exe files.
Based on your experience what is the best choice to do that (framworks, ... )
Correct, you must use an MVC framework to design a flexible and reusable web application on the Java EE platform.
I suggest the following design:
Use JSF (Java Server Faces) to design the front end. As you are migrating your desktop application then it will better suit you becuase it's Component and Event driven framework.
Middlware: EJB 3(or EJB3.1) This will provide best available flexibility, performance and security to call your Business components directy from JSF Beans or any other remote application.
Over here you can use various design pattern to encapsulate Library and database access i.e. DAO (Data Access Object).
Use DTO (Data Transfer Objects) to transfer your request/response.
Hope it will give base to start your research.
If you can abstract the layers that talk to the backends such that your frontend (Swing?) doesn't need to know where those service are located, you are half-way there.
The key should be a good module concept. Frameworks like the NetBeans platform help you with that, and they can easily integrate non-visual modules that handle the backend code.
I'm not sure what you mean with "We must use also MVC"
MVC is a design pattern not a library or framework.
But if you use something like the NetBeans platform, you'll be applying that pattern anyway, because it forces you to think in modules. Each module will have a defined responsibility and during startup it registers itself with the application.
Take an application that allows you to manage people (e.g. for a human resource department). One module is responsible for displaying a form where the user can look at a single employee. That module in turn looks for a provider that can load or list all employees. How that provider gets the data is invisible to the front end. It could use a flat file, a relational database or a call to a remote EJB server (this is were you could plug your JavaEE stuff in)
The application could even download the modules from the server if correctly configured.
The key is to make the modules independent from each other. This is true for any large scale application regardless of the technology used (web application, a server side daemon or a desktop application)
We are in the process of working on our second generation of our eCommerce site. The contracting firm that has been brought in is pushing for the use of WebSphere Portal vs using JSP/Spring MVC etc to build out the UI part.
Many parts of the new release will be based on Version 1.
The contracting firm is an IBM partner - so I assume that there is a conflict in interest in determining the best solution for the UI.
So, I am reaching out to the group to get a feel as to is using IBM WebSphere Portal worth the money - ROI?
Going forward we will be using an off shore company to maintain the application once it goes live - so we have to consider those skills sets.
We provide Web Sites to Consignors to allow them to sell/auction their inventory of Vehicles. The underlaying Business Logic is pretty much the same for each consignor and is handled in a separate tier. The issue is that currently we have created a core set of UI and Controllers which are then extended into a Consignors project. Each Consignor "Store Front" is a separate deployment.
Here is what I know or have been told about Portal:
IBM WebSphere Portal OTB will handle the basic security - user log in and the portlets that they can see (Spring Security can do the same thing)
IBM WebSphere Portal OTB can handle the theming or re-skinning the portlets based on what company the user is associated with. (Standard UI practices can achieve the same thing)
IBM WebSphere Portal can provide re-use of Portlets (Not sure I buy this since so far each customer has demanded their own screen layouts along with the data collected and how it is displayed)
IBM WebSphere Portal can help with time to market - That is start with a base reference implementation and then show them what can be changed in a 45 - 60 day turn around.
I am open to anyone who can also provide more benefits of its usage.
Follow on Question
In response to a statement made by #Bozho - what are the guidelines if any to determine if a portlet solution is warrantied.
IBM does not trigger any good references in terms of quality software in my head. And all points above are marketing nonsense. There are two things you need to assess:
do you need a portlet solution. (This is regardless of the portlet implementation).
which portlet implementation to choose
I cannot decide these for you, but I can tell you that:
spring provides even advanced user and security handling (spring-security)
even if you choose portlets, you can use spring. Spring has portlet support.
if you choose portlets, make sure you choose a good implementation. As I mentioned, I wouldn't go for IBM.
It entirely depends on what your end game is.
It looks like the supplier has recommended Websphere Portal with a view to setting up a virtual Portal for each Consigner - so they can be managed separately, which make sense as you can just deploy the same portlet in each virtual portal with a bit of customization and also the consigner and user roles can be handled easily by portal out of the box.
However Portal is a pretty big piece of kit. If you want to integrate content from various sources and present the data in a standard way to the end user based on their role,etc, or it you're planning on using some of its existing functionality, i.e. dynamically updating portlets on the same page through events, Web Content library, integration with Remote Portlets, integration with collaboration tools, integration with process server/bpm tasks, blogs, wikis, etc, then it might be worth using a portal solution.
If however all you want to do is essentially create a web app, then Portal's total overkill and I'd just stick to an app server with whatever frameworks make the job easier