Is it enough to use only Java?
Yes. Our newly created applications have been written only for web and we did all back-end with Java only (the only exclusions are selection for Views). No, we do not miss @Formula, Lotus Script or SSJS, we simply do not need those languages in our daily work. Java is better than LS/SSJS for us. You can develop much better/faster using Java and get all candies: open sources, forums, stackoverflow or even shift at some point to Java completely if it has sense for you. However, if you read my main posts I mentioned that we still had some problems while work with Java, Solution isn't really perfect and let me explain all those weakness we have right now.
- Domino has 2 Java runtimes (huge pain for us): one is for xPages and another one for Java Libraries+Agents. Java Libraries can be reuse in xPages and back JAVA/JAR are not accessible from Libraies/Agents. Our Java libraries are core for xPages and it means we have to build JAR from them and include them for xPages. It takes time and we really do not like that, it simply looks wrong. The solution is to put JAR to Domino OS, however we are limited with access to Domino's OS. Due to that fact we have one serious disadvantage - our JAR files that we attached to Libraries and Agents have to be extracted and loaded to memory each time we run agents.
- We are forced to use IBM Designer (and few of us would like to work in different IDE). As I mentioned we work via GitHub and it takes some time to build project (developer -> github -> jenkins -> domino). That's not a problem for FE, as they can do their tasks locally and after all just commit changes. BE part is located on Server so if we work without IBM Designer we have to wait 1-2 mins till changes come to it and only then we can do our tests. That's sad.
Does it mean @formula, Lotus Script, SSJS are not required to know?
Those languages are still important part of our 'old applications' and it will take years to completely re-write them to web and there should be a sense to do that, as it is time/money, @formula language is still only 1 way to make selection in Notes Views.
Pros
- open source;
- problems resolving (forums, community);
- more abilities;
- in case of migration to java platform, easy migration;
- 2 Java Runtimes
- ...
Summary
We are happy with what we have so far. We still have problems in terms of how to setup our development process. We will continue to look for perfect solution for our problems.
Other articles in this series
- How we build our web applications based on Domino
- Split back-end and front-end areas, they should not block each other and be independent as much as it is possible.
- Front-end guys should not have any knowledge about Domino, they don't need IBM Designer installed at all.
- Back-end guys must have knowledge about Domino, however they don't need to use IBM Designer, only in very rare cases. Backend should be done using only Java (no LS/SSJS/@Formula etc)
- Using Git+Jira is must and Jenkins server as builder server
- Auto-tests.
10 comments :
> Java Libraries can't be reuse in xPages and back JAVA/JAR are not accessible from Libraies/Agents.
If you want to use the same Jars in XPages and Agents then put them into lib/ext folder of the Domino server.
This also improves the performance on the server in using those jars. Especially in relation to Agents vs embedded Jars in the agent.
@sodoherty.com
> If you want to use the same Jars in XPages and Agents then put them into lib/ext folder of the Domino server.
Yes. It's good, well-known feature. Unfortunately we could not use it in our project. We have strict rule do not put anything in to the server OS. So we could not put jars in to the "lib/ext"
Well I was just clarifying that it is possible, where you mentioned it wasn't.
Just be aware by putting the jars directly into the Agent, that you are adding performance/memory overhead on every agent call.
The Jars are detached on the fly local to the server, then loaded into the JVM, then disposed of when the agent completes. This happens every time the agent is called.
So it works fine, but if the agent is under any kind of serious load you are liable to cause the agent to fail. You will see stacktraces in AgentLoader if this is the case.
When they are in the lib/ext, they are loaded into memory once.
Also some API's don't like the embedded method. Google API for example used to have problems if the jars were not put into lib/ext.
I understand your blog post is best practises based on your project, but personally I'd use an XPage JSON component or DDS to get your data if you are interfacing externally.
@ sodoherty.com
> Well I was just clarifying that it is possible, where you mentioned it wasn't.
You are right (I will update post), I simply forgot to mention that, and we mentioned, we are not allowed to add anything to Domino server OS :(
Though I appreaciate the effort, I really wonder why people want to get out of DDE, not use Custom Control , not use SSJ and so on... According to me you then loose some of the RAD aspects that makes Domino unique and so productive.
Using Java mainly is a good practice in my opinion though, but being so "purist" is a bit to far for me...
Michael
This were truely interesting posts Dimitry. Not sure, if I understand it correctly You seem to pass on a lot of features web-frameworks with ur strategy.
Wind has drive me into jsf2 projects and one huge problem in general atutude of corporate users of jsf2-framework is, that they often don't care much about how the html-documents and ajax calls are structured and how they are generated. Normally it ends in huge balls of mud with randomly composed set of css rules, bad structure, very bloated data in session, etc.
JEE application tends to be better structured in the EJB/JPA or spring-data/spring-transaction parts than in the web-jungle.
So if you have frontend devs that really know what they are doing and offer them a nice playing field to concentrate on their skills, it sounds ok.
@Michael
>Though I appreaciate the effort, I really wonder why people want to get out of DDE, not use Custom Control , not use SSJ and so on... According to me you then loose some of the RAD aspects that makes Domino unique and so productive.
I am completely agreed with you. I am just developer but product owner or another person who decide what we need to do to satisfy clients.
Very often product need to have special features that are able to do only by custom way. In the site, that represent company, almost all features are very custom.
We start from using different ready to use UI libraries & plugins - almost all of them ended by heavily changing it's behaviors or even complete replacement.
We found that better (faster and with best result) to use low level frameworks, like jquery, velocity and so on and do the rest of job by himself.
@axel
>one huge problem in general atutude of corporate users of jsf2-framework is, that they often don't care much about how the html-documents and ajax calls are structured and how they are generated. Normally it ends in huge balls of mud with randomly composed set of css rules, bad structure, very bloated data in session, etc.
We start to use velocity on the old application, that generate it's HTML on the back side by agents. JSF was not available for us. Now we use both ways - generate HTML dynamic on xPage nad generate HTML in backend by agents.
We do not find any good reason to switch to pure JSF. Velocity does not have the power of JSF, but it look enough to us.
Be aware that for each of the web solutions mentioned, you will need to spend a good deal of time reading up on how they work and how to use them. Once you know, it seems fairly easy, but there are a number of important ideas to understand before it all makes sense.
Is it enough to use only Java? Yes. Our newly created applications have been written only for web and we did all back-end with Java only (the only exclusions are selection for Views). No, we do not miss @Formula, Lotus Script or SSJS, we simply do not need those languages in our daily work. Java is better than LS/SSJS for us. You can develop much better/faster using Java and get all candies: open sources, forums, stackoverflow or even shift at some point to Java completely.
Post a Comment