In an effort to prevent its Lotus Domino developers from jumping from Java to .NET, IBM in May will release Lotus Domino Toolkit for WebSphere Studio, meant "to give Domino developers training wheels to get into J2EE". Using custom JSP tags, developers can connect to existing Domino applications to build new JSPs while preserving the drag-and-drop design elements of Lotus Notes and Domino apps.
Read IBM Hopes Toolkit Has Domino Effect
In a related news piece, IBM said it would support weblogic from Websphere studio
So sad. Everyone is trying to dumb down j2ee. Originally I would have said what a stupid idea this is but weblogic is going the same route as well.
Maybe Fleury is right in his last cnet interview, j2ee needs to be simplified like .net. People should just write plain ole java objects and the j2ee container should hook in transactions/security/etc for them. No more of this writing stateless|stateful|entity beans or remote|home|local interfaces. Just like .net, we should be able to write plain objects and decide in a simple xml config file, if they are to be called synchronously or asynchronously.
I agree. It's good to have high level tools that simply all the low level details an integrate nicely with lower level technologies, but you can't ignore the low level. There's an old saying, if the software is designed to ignore the hardware then the hardware will ignore the software.
I like the JBoss/AOP idea of decoupling, layering, and simplifying EJB's technologies instead of writing wizards and code generators to put everything together. EJBs have a lot of good technologies and protocols, but do you *really* need to define three classes for every EJB entity you're modeling? Yes, XDoclet helps, but wouldn't it have been better to define EJB in terms of
java.lang.reflect.Proxy (or a more AOP extention of it) like JBoss currently does, so the EJB functionality you need could be layered on according to your needs? Of course the "we should be able to write plain objects and decide in a simple xml config file" approach is nice but that's just frosting on the great JBoss/AOP design.
Hopefully these ideas will filter into the Java 1.5 spec like ideas from Struts have filtered into the Java Server Faces spec and the JSTL spec.
"Just like .net, we should be able to write plain objects and decide in a simple xml config file, if they are to be called synchronously or asynchronously."
Yes, this is called EJB making use of declarative services(deployment descriptor). Though, the difference is, the developer is provided the choice as to what type of EJB he wants to develop, whereas in .NET he/she is not.
I dont know how much work you have done with .NET, but dont buy into the hype that writing enterprise components is as simple as writing a class and specifying to the COM+ container what services it needs.
It has been my experience that this is referring to the .NET ServicedComponent Class. In .NET, If you want to write an EJB type of class you extend(inherit) from the ServicedComponent class. This allows it to be managed by the COM+ Container. This is like our EJB's, which are managed by the EJB container where you can specify what enteprise services they may require (object pooling etc.)
So, in both frameworks it takes just as much effort to write a component that can be managed by a container. On top of this, the COM+ Container only offers a shadow of what a J2EE Compliant EJB container offers as far as enterprise services go. As far as I know it only offers the following (JIT Activation, Security, Object Pooling and Transaction Management).
I am not getting on either side saying which one is better, I am just commenting that to develop an enterprise component the effort is the same, but J2EE offers more container managed and configured enterpise services.
And having worked with Microsoft technologies for a long time and having spent the last few years working in J2EE as well. I would say that MSFT offers a simple, easy to understand model for software development which shephers developers into writing particular applications a particular way and J2EE offers a more robust, more open model, but more complex compared to the microsoft one.
.Net is simpler than J2EE because a typical ASP.NET app is identical to a JSP+JavaBeans app, without the use of EJB's. Even if one uses a COM+ component, it is equal to using a stateless session bean. .Net does not try to do elaborate persistence work that entity beans are envisioned to do. For database-related work they promote a model equlivalent to the JDBC Cached RowSet. No JDO, no O/R mapping. No wonder more people find .Net easier to learn.
|No wonder more people find .Net easier to learn.
Finding it easier to learn is one thing. Finding it easier to get a job done is another.
Less is not necessarily best. Less is often a sign of immaturity.
Finding it easier to learn is one thing. Finding it easier to get a job done is another.
Depending on what is the job at hand. I will go out on a limb and say >80% of the systems developed for enterprises do not need sophisticated transaction management and asynchronous messaging. The .Net toolset is more than adequate to get those jobs done. A Chinese saying goes like this: to kill a chicken, one does not need a cleaver for slaughtering a bull (excuse me for the poor translation). The same is true here.
Why do you think BEA hired an ex-Microsoftee (Adam Bosworth) as its Chief Architect, and why are they bet their future on the WorkShop tool? Because J2EE is just too hard for the mojarity of the people who are writing code today. It doesn't matter that the software engineering elite looks down upon .Net - M$FT is after the bottom three quarters of the scripters/coders/casual developers, whatever you call them. Let me try to translate another Chinese saying: if a tune/melody is very exotic, you will find few people who can sing/play it. I think BEAS and IBM both have realize this.
Yes, I think you are absolutely right. "Easier" relating to ASP.NET means to do it faster. And that is mostly due to existing controls + support for them in Studio
How many times do we have to say this: Entity EJB's != J2EE. Repeat and rinse several times! JSP + JavaBeans is a perfectly acceptable J2EE application.
Actually, something like JDO and O/R frameworks are *much* easier to work with IMHO than straight JDBC, because you work at a higher level of abstraction - objects versus rows in a database table. Of course, you have to be at least somewhat familiar with object oriented programming (which is problematic everywhere - not just on the Microsoft side). If I didn't have something like Hibernate, life would *really* suck.
Well in our IT department MS Developers are dumping .Net
and learning Java to develop.
There is a lot of crud and hype in .Net which does not fly in real world.
I hope you havent forgotten VB6 and its hype from MS.
You guys forget one thing. ASP.Net ADO is more in line with JSP and JDBC. Java gives you more for tbe bang. .Net doesnt seem to have any kind of other database schemes like cmp, jdo, etc which makes programming in java so nice. There isnt a disconnect by coding sql or calling a stored procedure. One benefit that .Net just cant do is cross platform. I've been so happy to use XDoclet to do my builds and be able to run my stuff on Linux, Solaris or Windows. I know there is Mono project but that to me is a project trying to catch up with a bullet. I dont discount .Net b/c most MS shops will go to .Net, I've been using .Net since pre-beta and its nice. But when it comes to making a decision i have a hard time choosing .Net b/c it doesnt support cross-platform. And since i'm one of those nerds who truly belives Linux will be the next wave on the server side ( outpacing unix flavors and Windows ), i like where java stands.
It's interesting, that a post regarding Lotus Domino does not attract any developers actually working with it, but opens a discussion about why and if J2EE should be made easier. Is anybody out there really working with Java and Lotus Domino on a larger frame?
Well, as a person that does, I truly can't blame you, bc. the Domino Java API is a real pain to work with and you have to invest huge amounts of time to get it working on a stable base.
The specifical point for IBM to make J2EE easier is in my opinion, that the majority of Domino Developers aren't ready for the kind/level of development J2EE stands for. There is no real "architect skill" needed to develop a Domino-Application bc. the architecture is given by the platform itself. You only "plug in" your own developments in the form of display masks, LotusScript-Code (which is a VB-Clone), and a proprietary expression language called @Formula-Language.
On the other hand, regarding RAD and Ease of understanding, Domino could teach J2EE a lot. So I think, IBM should try to move Domino completely on a J2EE-Base and make it a "High Level View" of the J2EE-Platform. This would also solve the problem about J2EE-Complexity. If you want to code easily, you can use this View, if you need to do more complicated things and need more control, you could code "a level deeper". Supplying "High Level/Ease of use"-Tools for a complex platform, without forcing anybody to use them, seems IMHO to be the crux here.
I used to do a lot of Domino development and worked with a lot of Lotus Domino developers at various consulting firms and IT shops. I would less than 10% would have the foggiest idea what J2EE is, much less know how to use it. Domino is meant for, and mostly used by, lightweight developers that want to do everything in a lame VB-like form builder.
No wonder they haven't replied--trust me when I say that 95% of theServerSide is way over the head of 95% of Domino developers. Sorry for sounding like such an arrogant jerk, but your average Java developer is 20 times sharper than your average Domino developer.
Just didn't want to use rough words on that subject, bc. there are some friend domino developers of mine that just *might* read this post ;)
You might also end up with somebody who knows both you and your friends telling them ;-)
...it's a small world after all, innit?
"but your average Java developer is 20 times sharper than your average Domino developer."
What does that mean? what metrics are you using to base your assumptions on?
I am a Domino developer. 100% of .net is a mystery to me atm. Is that because I am a 'lightweight' or because I have not educated myself in that domain yet?
Its not necessarily about being 'smart' or should that be smug in your case.
J2EE is not rocket science Mike. Its just a matter of getting the right education. You seem to have a big sense of your own self-importance.
And yes, you do sound like an arrogant jerk. You are not really sorry though. Dont apologise-its probably because you are one.
I think the point Oliver made is valid, even if Mike's reply might have been a bit harsh. I believe that Domino/Lotus Script/@Formula language developers have a different focus, and different skills. You are not likely to turn a Domino developer into a J2EE developer easily.
In the past, the way to extend Notes/Domino with components requiring "real" programming environments was to develop server tasks with the C/C++ API or LSXs (Lotus Script eXtensions) for the client side. If this could be replaced, e.g. by being able to develop EJBs/Web Services/Taglibs that could then just as easily be used by Domino developers as the existing Notes/Domino infrastructure, it would be just great. But I don't think this is going to happen, since I don't believe that IBM is ever going to port Domino to J2EE, however often they announce it ;-)
I am a Domino developer, and a Java/J2EE developer. Stefan's point about Domino requiring different skills and a different focus is quite valid. Granted, Domino does not support EJB's, but who needs it to? There are a number of complex, integrated tools available through Domino, such as LEI (Lotus Enterprise Integration) and DECS (Domino Enterprise Connectivity Service) that I can use to retrieve data from any relational backend without all the overhead EJB's carry.
I'm a Java fan, but there are some things I can do a lot quicker with Domino because I don't have the overhead. As far as architecting goes, there's a lot more involved with Domino than most people here know. You have to know which design elements are best for which purposes, you have to understand the security model, and what you can accomplish where you are working, in what context, and with what tools and/or programming languages.
And for those of you who think that Java will always be superior, I have a complete e-commerce website with shopping cart, e-cards, knowledge repository, art gallery, and email notifications. I have a blog I'm putting in place when I have a couple of hours, and my wife, who doesn't understand even html, can create content and add products to the site, and I built the site in about 100 hours. I couldn't even come close to that if I had to use Java.
It's all about the right tools for the right purpose. BTW, the Domino J2EE toolkit has been available as a Beta for several weeks and will be officially released this summer. Although I don't have WSAD, since it uses the Eclipse framework I downloaded it to use with my Eclipse IDE.
Well said Alex! I too am a Domino Developer, I have done limited Java development but desperately want to work with the J2EE architecture. Problem is justifing the expense and time to do J2EE. Most companies I work for love Domino/Notes because it is quick and cheap, and have little concern about J2EE's strengths, building applications that are robust and scalable.
I have argued the point of developing using J2EE. Encapsulating business logic into a EJB, but with the economic environment, management prefers quick and cheap to robust, reusable, scalable and right. Very shortsighted but a reality at this time.
Another point would be using the right tool for the job, convincing management that they need a Lamborghini, "J2EE", to get a load of groceries "building a basic application", is a hard sell, when they know that the VW Bug, "Domino", will do the job just fine.
Is J2EE more sophisticated than Domino, absolutely. Can a Domino app be built faster and cheaper than a J2EE app, certainly. What is best is a matter of perspective.
I think IBM is doing a pretty good job of cornering both the high and low ends of the market, and the new J2EE-Domino tools is a smart way to bridge the gap and facilitate the purchase of new hardware and software.
Just my two cents,
..as there are some Domino developers around when you call them.
And to be more precisely on that "kind of agreement": I'm not calling anyone stupid. Actually you wouldn't be able to use your modelling/architect skills on the domino platform (apart from working with lotusscript classes, that you can't use in some places) even if you wanted to. So the platform kind of "keeps you stupid" regarding these skills and gives you little chance to learn about them without moving to a different platform.
On the other hand, there are numerous projects where the given domino architecture fits just well and is the base for good and working solutions, that are created with very low effort. So it's no fault to do things that way, but you have no choice to get a level deeper. I once was a fan of the domino strategy, but the limitations are so obvious (and the implementation so bad at some places) that I just needed to move away from it.
So, coming back to the original point of this post, there must be some way to implement the Domino RAD strategy on a J2EE base. I'm not sure, if this will happen any time, too (as I think, this is mostly a political decision inside IBM), but I would like to see something like that. WHAT I am sure about, is that the Domino Java API in the current state won't be the bridge - or even a base for any bridge - to J2EE, that IBM wants. There definitely is need for some work, even for a complete redesign.
Domino's Java API will not be the bridge to J2EE for Domino developers. At the risk of sounding obvious, Domino developers don't require the type of modeling/architecting skills you refer to because we don't process the same type of OO, nor do we have to worry about optimization of relational tables to store data.
On the other hand, Domino does make a decent, easy to work with data store, and if the J2EE classes help us get away from combining presentation with storage logic, it would be a huge benefit. I see applications where I work that I think would benefit greatly by moving the presentation out of the native Domino environment, but I can't because of Domino itself and internal resistance to certain changes that would need to happen. Personally, I'd like to see the move to more of a pure Java environment that required the modeling/architecting skills you speak of, but because of the corporate mindset I don't see that happening here or at a lot of other Domino shops.
I can fully support the statements about Lotus designer skill level.
>There is no real "architect skill" needed to develop a Domino-Application bc.
>the architecture is given by the platform itself.
I would even extend that to the statement that "modelling & design" skills are missing:
I tried to get some information on how to map a simple UML class
model (simple = 6 classes incl. relationships and inheritance)
to lotus notes and I was not able to get that information from
anywhere (books, internet, IBM sites).
(If someone has a hint, please let me know!)
What really surprises me is that even Lotus itself is not improving that area.
Because of this bad situation, most "real designers/architects" feel that Lotus is more a "hack" than a well-designed RAD platform.
(because RAD also means, that you can map your complex (UML-)model easily to an implementation).
Having said that, I really hope that IBM is able to "merge" J2EE and Lotus.
As already written elsewhere, both worlds can learn from each other.
And at least in my domain, certain parts of the product development could
be improved very much by a good RAD platform/tool, on top of J2EE, of course.