Concerns about moving to WebSphere and the future of Domino |
 |
EXPERT RESPONSE FROM: Alex Homsi
|
|
|
|
| > |
QUESTION POSED ON: 06 September 2004
I have been doing Domino development for a few years. During this period, I have developed simple discussion databases to complex workflow applications for Web and Notes clients to e-commerce Web sites with both Domino and a relational database as the backend. I have done coding using Formula language, LotusScript, done agents in Java and used JavaScript with my Domino Web applications. My questions are:
- I want to start working my way towards WebSphere. What should be my initial step(s) for getting there?
- The more I read about WebSphere, the more I get confused. There are different versions of WebSphere out there for different platforms. Which one should I use for taking my first steps? Do I need to worry about this?
- How would I transition my experience and knowledge from Domino to WebSphere?
- How would I transition my applications from Domino to WebSphere?
- Since I am jumping into a new boat, is this the right boat to jump into? I mean what does the future hold for this new boat? Is it a stable boat? Should I jump into some other boat like Oracle and .NET? If I have to take a fresh start, why not jump into a boat that has a more stable history?
- I do not see any future for Domino. Is that a fair observation?
- Why is there so much push from IBM towards WebSphere? Domino is going to use a relational database as the backend in version 7, you can write Java agent in Domino and it has a HTTP server, so what is WebSphere adding to all this?
|
|
|
To continue reading for free, register below or login
To read more you must become a member of SearchDomino.com
- There are currently two options to tackle WebSphere if you are a Domino developer. The first option is to learn mainstream J2EE development and SQL to develop transactional applications. This option falls short when it comes to building collaborative/workflow applications, the same type of applications that Domino is good at. Keep in mind that J2EE does not offer framework support for this class of applications, while Domino does.
The second option is to consider a third-party framework that augments the J2EE stack with a set of high-level services and APIs that can offer a Domino developer the same high level of abstraction that you have in Domino and familiar document-centric constructs. In both cases, you will still need to learn how to package and deploy a J2EE application as a war or ear file using the WebSphere administration console. Even if you invest in a specialized vendor framework, understanding Java and J2EE is always a plus.
- The WebSphere Advanced Single Server is definitely a good starting point.
- The Domino object model is a document centric model where the "Note" object is the building block for information sharing, workflow routing and contextual collaboration. The optimal way to transition this experience and knowledge to the J2EE world is to have an open standards rendition of the Domino framework and expose similar APIs to the Domino object model through which you would manipulate XML documents the same way you manipulate a "Note" in Domino. Skills leverage cannot be achieved unless you use a framework that is designed for this purpose -- whether it's one that you build in house or you buy from a vendor.
- Application migration tool vendors often use a technique called framework translation to automate the migration process between two platforms. This is especially efficient when the source platform has a common public framework of design elements that is shared by all applications. A framework-level migration has three important side benefits: consistency across migrated applications, skills leverage and enhancement/maintenance agility. Rewriting the code of an application or generating it, without the use of a common framework or API, is not economically realistic. I have seen companies try to migrate their Domino applications to J2EE using brute force (an army of J2EE programmers), rather than leveraging available migration frameworks. Awareness is increasing about the benefits of such frameworks and this is a good thing for the Domino community.
- I definitely see Lotus Workplace becoming the new Domino of the J2EE world. I predict that Lotusphere 2005 will be all about transitioning Domino developers to Workplace. Much like J2EE, .NET does not offer any framework leverage for Domino developers. Microsoft's argument that Domino developers are better off with VB.Net because the language syntax is close to LotusScript is a joke. The framework is what makes Domino skills, not the programming language.
- This is a fair observation if you're talking about Domino's proprietary architecture. The future is Workplace becoming the new Domino. Lotus is just missing a new Workplace Designer tool for Domino developers to develop for Workplace using the same terminology, concepts and framework that you have today in Domino Designer. Once they have it, the transition will become crystal clear. At Lotusphere 2004, Lotus promised to show this Workplace Designer at Lotusphere 2005. If they pull it off, this is going to be huge for the Domino community.
- You're right, WebSphere doesn't bring much to the table for Domino developers -- it's too core level. Workplace is foreseen as the bridge from Domino to J2EE, not WebSphere on its own.
Do you have comments on this Ask the Expert question and response? Let us know.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
