IBM's software group is getting ready to release a Java development tool that claims it will ease the process of building custom business applications.
The tool, called IBM Rational Rapid Developer, is expected to be unveiled soon. IBM's proposed approach to development using this tool resembles an MDA-based one - they call it "architected RAD," or architected rapid application development.
In some respects, IBM seems to be positioning it as IBM J2EE For Dummies. IBM also says that the tool's not for experienced J2EE developers.
Eric Schurr, a marketing VP from IBM said, that "it is aimed at developers without Java expertise and is not specifically intended for skilled J2EE developers, which are the target customers for WebSphere Studio."
IBM Rolls Out First Software Tools from Rational
IBM's Rational cooks up Java plan
IBM Preps DB2-Based Integration Software
Is this IBM trying to come up with its own BEA WebLogic Workshop?
Is there as big a market for these "anyone can build a J2EE app" tools as the business people think? Have any of you used them and care to discuss your take?
Is this IBM trying to come up with its own BEA WebLogic Workshop?
The new tool from IBM is a great mix of rational modeling technologies + NeuArchitect ( A tools aquired by Rational years ago) + IBM's best IDE + plus industry proven knowledge of two great company ( rational and IBM). How can you even think about comparing the tool with a properatory WLS application builder called workshop?????????????????????
How can you even think about comparing the tool with a
> properatory WLS application builder called workshop?
Can you please elaborate that a little bit more? If WLS Workshop is proprietary, I don't understand how NeuArchitect or Rose or IBM's best IDE constitute a "standard"?!?
I think you know UML is kind of universal language for communicating and visualizing the design ideas in best way. Rational is a company followed that standards through out their business life. Rational even before merging with IBM was in market with tools developed based on universal standards of UML language. In any work place Rational tools never stopped the developers or architects using any vendors application servers or database or operating system.
But in other hand, if I developed a web services or portal application in WLS workshop. I never ever go to deploy that into another application servers from vendors other than BEA. I understand that is something called proprietary approach to design and development of an application. Since BEA doing business in Java language which is default made for build one and deploy anywhere concept, people may think BEA is not into a vendor specific business. But if you go into details of any products from BEA except the WLS container, you can easily understand that they are into BEA's vendor specific application development approach. You could able to verify this concept easily with an application developed with products such as
BEA Process Integrator
BEA Jam for Mainframe
BEA Portal etc
I have looked into workshop tools during its early days and came to know that it is nothin but a visual basic concept( got from people joined with BEA from Microsoft as part of Workshop deal) + Jakartha struts framework + BEA's properatory workflow which they used to apply in early version of portal and process integrator.
Rational tools are made for people who like to think about software design and development process in a universal approach but BEA workshop is made for people who use BEA's other tools such as WLS server, portal etc to develope an application good enough tp run in BEA server.
A simple Web Application built on workshop consisting of struts / jsp's etc. may be ported to another app server, the issue is that when you get into frameworks such as Portal and Process Management, there are no mature standards out there.
The Portal version of the same Web Application would atleast require an implementation of the Portal Framework to also exist on the other app server. Similarily an application that uses the process management engine or message broker would require that an implementation of the process management engine and message broker also be present on the other app servers. You simply cant take any Portal project (whether it's IBM or BEA) and port it to whichever app server you want.
Ideally we would like to be able to build a portal on one portal server and move it to another. Or build a generic business process on one process engine and move it to another. This is typical behavior where companies will innovate and then push those innovations towards standards eventually competing on implementation as is somewhat the case with app servers today.
The web services example is a good one to take. Currently there are no clear standards on asynchrony, state management etc, hence you have JSR 181. BEA is driving JSR 181 through the standardization process. JSR 181, defines how to use simple Java classes with declarative annotations to build powerful enterprise-class Web services, was unanimously approved by the Java executive committee in April 2002, with the JSR 181 expert group working on developing a standard specification since that time. BEA will also be making a publicly available reference implementation later this year. Similarily there is JSR 207 called "Process Definition for Java" (PD4J) which defines a standard for a Java based process definition language and there is a long list of other Portal standards as well (JSR 94, 127, 168 etc.)
its the innovate and standardize process that we need to wait out and see who eventually comes out ahead.
"Ideally we would like to be able to build a portal on one portal server and move it to another. Or build a generic business process on one process engine and move it to another. "
This is possible today. You just have to look away from the like of IBM and BEA who all build tools/Portals/Frameworks to work only with their App servers. There are a number of Portal, Web Services, BPM Frameworks/Products out in the market place that allow you to deploy to a number of different Vendor's App servers.
J2EE is bigger than IBM, BEA and Sun!
J2EE is bigger than IBM, BEA and Sun!
That is true however when you think that IBM+BEA+SUN have 70% of the market, a standard not supported by those companies doesn't have an automatic big acceptance. Or, should I say, the standard acceptance of a given framework/technology mostly depends how fast it makes part of the J2EE or Java? If it is not, it has to solve a frequent/common problem in a very elegant way, something like the Struts does to become the de facto standard.
The other aspect is the diversity of the frameworks. We recently had a look at the open source Workflow engines/frameworks and believe me, there is a lot of them out there! So, which one is going to become a standard (if any)? Apache Struts is (again) a good example. Although it is widely used, it is still hard to say that Struts is the de-facto standard because there are tens of other frameworks and some of them do a very good job. Only the introduction of the new specifications like "JavaServer Faces" or "Process Definition for Java" can standardize the implementations and protect us.
The other aspect is the diversity of the frameworks. We recently had a look at the open source Workflow engines/frameworks and believe me, there is a lot of them out there! So, which one is going to become a standard (if any)? Apache Struts is (again) a good example. Although it is widely used, it is still hard to say that Struts is the de-facto standard because there are tens of other frameworks and some of them do a very good job. Only the introduction of the new specifications like "JavaServer Faces" or "Process Definition for Java" can standardize the implementations and
You are not forced to follow any framework. But when your company blindly go and buy a framework from company like BEA ( BEA portal or integration or jam ) cuz of they have 70 % market share today. What you are getting is nothin but a low standard framework which work only with a single vendor. Their price is also too much and they are selling the product on Weblogic brand name. Once again by just following the market share options, some vendor like BEA fooled around your company management. A right engineer who know the power of Java can easilly build a good web frame work within six months and take to production.
Well it probably depends on perspective....
> Rational tools are made for people who like to think about software design
> and development process in a universal approach but BEA workshop is made for
> people who use BEA's other tools such as WLS server, portal etc to develope > an application good enough tp run in BEA server.
Actually, I think that UML, like the Rational Unified Process, is a *product* that Rational invented. True enough, it is a standard, undergone all the standard processes etc., still Rational is the major support source for UML. What I find interesting about this "Universal Language" is that there is almost no way to produce production quality UML without using specific and expensive Tools.
Sure you can use Tools like ArgoUML, Visio, Violet etc. to produce Something-That-Is-Quite-Like-UML. But this is like coding in, say, something-that-is-quite-like-java. Yet for real sound UML you have to go with Rational, STP (whoever owns this now) or maybe TogetherSoft (now Borland, I believe). Sure enough you can generate XMI but to get that exported and imported in another tool with all information, annotation, implementation and layout preserved: Good Luck. Now that is what I call vendor lock in. Porting a million lines of code is probably a lot easier than porting a thousand diagrams.
Of course diagrams and processes are great and much needed (BTW, I still think conceptually, OPEN was far ahead of RUP but had much worse marketing, and maybe, tool support).
What I find interesting about this "Universal Language" is that there is almost no way to produce production quality UML without using specific and expensive Tools.
Actually, these tools don't even support the UML standard very well. I have used UML successfully as a simple design notation, but neither it nor any UML tool out there has actually helped
me design better software. I still have yet to see a tool that even comes close to helping me design and visualize my work.
Sure enough you can generate XMI but to get that exported and imported in another tool with all information, annotation, implementation and layout preserved: Good Luck. Now that is what I call vendor lock in. Porting a million lines of code is probably a lot easier than porting a thousand diagrams.
Amen. XMI has been a complete failure from a portability perspective. Trying to take an XMI file from one UML tool to another almost always fails. In fact, some tools (I won't mention any names) can't even import what they exported! Ugh...
There aren't any good design tools out there IMHO. The whiteboard is still my best friend. Old reliable, but boy I could use an upgrade... <sigh>
Director of PatternsCentral
"Where Patterns and People Meet"
I feel RAD is good for small applications which has perfect design right from the start of the project. Usually the requirements keep changing and so the db model aswell. It will be difficult to use the tool in this case.
The tool in my aspect looks more like ASERA (can be said as Very much simplified and eased form of ASERA) but it will be very difficult to port the applications which is build on custom frameworks. Further, it will be very difficult to debug/profile since most of the code is written by the tool itself. It requires other IDE like WSAD for debugging purpose. I believe it is good for developing considerably a small project with a team of maximum 3 or 4 people and with core JSP / Servlets. Any custom libraries / frameworks if used in the development will be difficult to maintain. I also noticed the tool generates quite a lot of code and if configuration management is not done properly it can really screw up the life of the developer.
The tool, called IBM Rational Rapid Developer, is expected to be unveiled
> soon. IBM's proposed approach to development using this tool resembles an
> MDA-based one - they call it "architected RAD," or architected rapid
> application development.
...because I am sick of the term MDA. Because with MDA (as I have seen it, as Booch etc. talked about it) the model does not ever drive the architecture - it's the platform and the artefacts predefined for the platform that drive the architecture. Gee, the term drives me mad. Anyway, I like it being called ARAD, because that is exactly what it should be: Some architecture derived by knowledgable people - tool vendors, internal or whatever - that can then be used by tool users to design and build the actual "business requirements".
BTW: Business requirements. Another term that drives me mad.
Picked up a JDO book yesterday (not bad a book by the first look of it). Of course the author stresses that the programmer can concentrate on the business requirements rather than coding persistence. Guess what. For most businesses, making the data persistent *is* at the very core of their business requirements. JDO's pretty cool, though :-).
"because I am sick of the term MDA. Because with MDA (as I have seen it, as Booch etc. talked about it) the model does not ever drive the architecture - it's the platform and the artefacts predefined for the platform that drive the architecture."
Fair assessment. The name "model-DRIVING architecture" would be more accurate.
"Gee, the term drives me mad."
The industry's gone through a variety of alternative names for things like MDA, including "model-integrated computing", "executable models", "model translation", "model compilation", "generative programming", and "recursive design". Now we're stuck with the label "MDA".
If IBM says the tool is easy to use I trust them. Usually IBM tools are pretty difficult to use for people coming from an MS background.
Musaddique Husain Qazi
.NET is just a bad copy of J2EE ...
Its not a new tool. Rational adquired Neuvis and they are evoluting the Neuvis "Neu Architect" application.
I don't know about the rest of you, but I don't want dummies working on a J2EE project with me. I don't want some chucklehead who can point and click generating code. I will never get the rationale behind making these sorts of "click Next 7 times and you have a functional application" IDEs. Nor does it seem reasonable that one could specify a UML diagram with enough specificity to generate production-quality, fault-tolerant code (or rather would want to).
It seems that stuff like this, and the BEA Workshop is solely geared towards selling the server to managers who have no other basis for comparison. "Hey, if my idiot programmers can deploy a J2EE app without knowing J2EE, that sounds great!"
Would any of you get surgery from a doctor using "The Complete Idiot's Guide to Brain Surgery"? Who would get abord a plan piloted by someone using "Teach yourself Airline Piloting in 24 hours".
I will never get the rationale behind making these sorts
> of "click Next 7 times and you have a functional application" IDEs.
:-) You write your application (Sorry! The wizard writes it) in 2 weeks instead of 4 however you loose 4 weeks to solve a trivial problem that would take a few hours to solve if you knew the code... I don't like them either...
I´m inclined to agree with the previous speakers about not wanting "J2EE for Dummies". There are a few aspects that would speak for it, such as lack of skilled developers for some project (resourcing) etc, but having previously seen the results of "point-and-click" code I´d rather see the project take 7 months instead of 6.
The code is usually non-standard spaghetti-code that is hard to comprehend and hard to debug. It is extremely non-reusable and is on a larger scale full of design-flaws.
Ever tried to build new functionality and expand a system that is hardcoded for a particular implementation and full of the simplest design-flaws? Its hell! Sometimes its easier to just redo parts from scratch.
One of the great promises of OO is reusability, but these kind of tools tend to shoot it right out of the water.
Any "productivity" gains are quickly eaten up by costs in subsequent projects for further development and new functionality, debugging for trivial bugs and just plain-old change-requests that ALWAYS will turn up during a project if the customer cares the least bit.
Given good guidance, a developer will be reasonable Java-developer in a year, and given a reasonable java-developer, he will be a reasonable j2ee-developer within six months.. Note: Didnt say great though.. This depends a lot on the person, some might be great in that time, others might not be that even after 5 years, its all down to their will to learn new skills and put their "ego" aside.
I just got spammed on this but probably worth viewing to make an opinion on the new IBM tool.. http://webevents.broadcast.com/ibm/developer/061103/index.asp?loc=202
J2EE is complex.. period. When people start learning J2SE, J2EE getting past the semantics of coding and concepts the enormous amount of add-on's/frameworks/patterns/os projects is out of control. I just read through an Accenture J2EE architecture that nearly relies upon all open source products. Not just a few but over a dozen. Given all these choices how is someone supposed to figure out all of this when you could just buy a solution. Sometimes buying is just much simpler but also because some research analyst has indicated this is more cost effective. Sometimes I think Microsoft just like Apple at times has it right, control the crown-jewels within their environments. The openness of Java is great but were making it too difficult ourselves, everyday it's a new tool to make this or that better.
I can't recall how much time I wasted trying to determine a decent mvc framework and then it's what persistence framework should I use and will it integrate? These vendors are all trying to repeat the days of Microsoft VB success. Fine, click away code towards a solution and I'm sure most will work. The issue with this audience (serverside) is that most are craftmans at hand and just plain prefer perfection. That's a pretty small audience, it's like being a mechanic for an indy car, sure you could fix my nova but let me make a few professional enhancements and this thing will be ready for the track.
The gui tools will get better plain and simple.
When people start learning J2SE, J2EE getting past the semantics
> of coding and concepts the enormous amount of
> add-on's/frameworks/patterns/os projects is out of control
I don't think that people learn J2EE like they learn J2SE. Almost nobody learns all of J2EE's content. A development team would usually have presentation layer developers (JSP, servlet, Web framework), middleware people (EJBs, JMS, etc.), etc. Even in J2SE there are packages that one doesn't use all the time. So, we would definitely have specializations.
> Given all these choices how is someone supposed to figure out all
> of this when you could just buy a solution.
I think that the main reason why the companies have Software/Technical Architects. Keeping up with the new technologies/tools is a part of the job. One either has to have good learning skills or good delegation skills :-). Or a manager having a technical background may be really useful.
It may be hard to pick the best of the frameworks for each layer. But I find it harder to rely on a product that does all magically using a proprietary *vertical* framework.
IBM Rapid Developer in TheRationalEdge (Official Rational Magazine) :
Architected RAD: Tackling the challenges of on demand business
IBM Rapid Developer = IBM Rational NeuVis NeuArchitect (See screenshots in article)
NeuVis Home Page
redirected to Rational press release but now in IBM site :-)
I am student of IT and developing a website using jsp builder i am using RUP model for development but can not find any particular software .can u guide me in this respect.thanks i'll wait for ur reply.
I actually asked for RUP rational unified process which will help me in building website related to my project, if u know any thing about it then plz reply.RUP is like other developing models such as RAD (rapid applicatipn develpoment).The incremental model etc.