Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Visual Studio .NET looks good (Kyle?)

 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, before someone shoots me and deletes this post, I'm a J2EE guy. I refer to .NET as .NOT. I was on a COM+ n-tier project a year ago, and made the decision that J2EE was the better bet.
Here is the point of this post. I'm sure this may not be the best place to post this, but I thought since Kyle faces this at IBM, he may want to comment. I just viewed 3 hours of webcast from last weeks VSLive. www.fawcette.com/reports/vslive/gateswebcast/default.asp
And finally, here is the point. The Visual Studio IDE looks excellent. It occured to me that all of those things we think are negative in the J2EE world (vendor lock in and one platform and only one IDE choice) actually may be a positive when it comes to the learning curve required by the developer base. For example, install Windows and install Visual Studio, and you are good to go ...at least they made it look that way . With Java, install correct version of JDK, pick from a large list of application servers, good luck settling in on an IDE, figure out how to get remote debugging to work, figure out what your deployment procedures will be, ANT?
I made the decision that if I was an IT manager, I would eat this extra learning curve for my work force, because I would not want to have to lock into the windows platform. That said, if I was the IT manager, I like the idea of 1 language and 1 platform from a training and support requirement perspective.
So someone give me some feedback. Does anyone else think that the J2EE world is now officially at a severe disadvantage on the tools front when contronting potential clients about J2EE development vs .NOT. I have just spent a very busy 8 months ramping up with J2EE and EJB. I was convinced after watching the Visual Studio webcast, I could be good to go in a much shorter time frame.
???
 
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO, if you are solution provider, not an inhouse developer of a big enterprise. You should go with J2EE, which gives you more choice for entering different market.
Imagine, after you deploy/test against different AppServers, you can claim you are able to support so many different platforms(webserver, OS, DB server).
With .Net, so far only one choice Windows. How can you catch up your customer demands on other platform. You have to rebuild everything.
For a specific application, no problem .Net will provide better productivity than J2EE.
I work for a solution provider company, which moved from MS platform to J2EE to meet increased customer demands on Unix platform.
Simon Song
Certified Enterprise Developer for Websphere
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I totally agree with you, Simon. I had the same experience. I was a Sr. MS developer. I am now heading for Enterprise Developer. I hava passes SCJP and VAJ.
 
Mike Jones
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simon,
Thanks for the reply. I get the impression that the bartenders here won't touch any topic that could be political in nature. Maybe there are javaranch rules published somewhere that I can read so I won't waste my time posting the wrong type of question. I see your point about solution providers having a different mindset. Obviously, it is easier to learn inferior tools than have to write code bases for different platforms. I have only worked at large companies that build internal business software for themselves (i.e. not to sell or market). Therefore, that is how I should have framed the question. I still stand by my point, however. Regardless of what J2EE development your are undertaking, that when it comes to tools, MSFT just presented a single, impressive IDE for the developer community. With J2EE I get to choose between Eclipse, VAJ (I agree, why test on something going away), Forte free, Forte expensive, WebSphere Application Studio, JDeveloper, yada yada yada, not to mention which application server. You get the point. It looks like MSFT just pointed out very bluntly, that corporate america n-tier development doesn't have to be married to such a hodge podge of confusion. The short version.... the developer shouldn't have to work this frickin hard to put the J2EE development puzzle together. Developers are at the mercy of the big boys for tools.
I think the economy will turn back up, and the war will be on between .NET and J2EE. I know what I have to prepare a client for when it comes to tooling up for J2EE. In some respects, the fact that it is hard creates the demand for those of us that pull it off. I'm just afraid corporate america is going to say hey... what about this .NET thing... I think our current staff can pull this off. It would be a shame for J2EE to lose out just because the development tools were a maze of confusion.
I think having choice in platforms and application servers is great, it just comes at the cost of developing the required skill base. I've been in alot of client sites over the years, and if you make things to hard, they will not follow.... or they will follow until an easier solution comes along.
JMO.
Mike
[ February 20, 2002: Message edited by: Mike Jones ]
 
Simon Song
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike,
So far as I know, some big enterprise IT houses(like Schawab, Morgan Stanley, etc.) are pushing aggresively on J2EE as their internal development standard platform. Maybe, those enterprises love Unix will adopt J2EE much easier. Coz, they have sufferted the pain in different C on different Unix. Posix doesn't help to ease the migration of C based applications at all, not to mention difficulty in MAKE file migration.
And big IT shops tend to adopt multi-vendor approach to get higher availability(coz, if Solaris is broken, maybe AIX still works), so how easy to develop one solution and run on different vendor platform is also a key issue to these shops.
.Net is good, WebService will be better. With WebService, who cares about the implementation of the service? Though it is not that mature, it is the right direction.
About Dev tool productivity, personally I think VAJ->WSAD provides the best one. And ANT based build-deploy process is superior. And if your developers have really grasped Java, they can pick up any IDE tool they like(Eclipse, IntelliJ, JBuilder, Cafe, etc.). And use a solid SCM, develop the ANT script, that's so flexible. If you want to standardize IDE tool, you can go that way also. In my company, we standardize on JBuilder, it is a pain to me. So there are people just use SlickEdit to check in sourcecode into Vss. I am trying WSAD.
I have worked on WebSphere, iPlanet, Weblogic recently, the transition is pretty smooth to me. So come back to my point, as long as you grasp the core of Java/J2EE, you will benefit in the long run. The learning curve could be high, I regard it is a challenge not a pain.
 
Mike Jones
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simon,
"The learning curve could be high, I regard it is a challenge not a pain."
I like that. Actually, after slinging code as long as I have, you are dead on. The fact that is hard does makes it more interesting. I was thinking more from a perspective of providing a skilled workforce, than individual learning curve. It's ironic that you mentioned "core java/J2EE". That's exactly what I have been trying to define. I sat down and started a J2EE Project Skills Checklist that I could present to potential clients to help them make sure they had a good idea of what they were getting into, if they were new to the J2EE game. I divided the skills checklist between up front requirement gathering skills (OO design, UML, maybe entity model), and Development skills (development environment configuration, IDE, java, EJB, JSP, Struts, Tag libraries, JavaBeans, Design Patterns, Ant deployement, JUnit testing, ...). I also had a section on skills required for production environment (production configuration and monitoring, ....). I would like to provide skilled teams (3 or more) to client sites for the development section of that checklist. I'm not sure I can sell that concept, but that's another post. Here is the challenge. List that core Java/J2EE skills that developer job candidates should have, or in my case, the skills that must be covered by the teams.
Something like:
JSP,Tag libraries, Java Beans, Struts / MVC
EJB, Design Patterns, Ant*, JUnit*
IDE*, Application Server*
JDBC, J2EE (transaction, security, ??)
Teams (CVS*, SourceSafe*)
* hard to define base / core requirement
What would you add to the core list?
Mike
[ February 20, 2002: Message edited by: Mike Jones ]
 
Simon Song
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike,
I have been working as a consultant before my current job. It is natural for a J2EE consultant to bring in the J2EE project concept, including team organization, build/deploy process, unit test/system test/load test process.
The beauty of J2EE is you can enforce MVC. The developer skill is tiered,
1. JSP/HTML/DHTML, use DreamWeaver, FrontPage, for debugging JSP you need a good Java IDE(VAJ, JBuilder, or other JSP debugger)
or Applet, use JBuilder, VisualCafe, VAJ
2. Servlet/Bean(command bean, value object), be familiar with Java programming is enough, use any cheap Java IDE is fine
EJB developer, 2 groups?
3. Session Bean developer(Facade, Biz Process), should be familiar with domain requirements, understand RMI-IIOP overhead, understand EJB spec.(security, stateless vs stateful, passivate/activate, etc.)
4. Entity Bean developer(CMP, BMP) or JDO/JDBC/SQLJ based Persistence Management layer developer, understand ER model, proficient in SQL language(you have to write SQL even for CMP in Finder methods, not to mention BMP), familiar with EJB spec(know what's vendor extension, what's standard, encapsulate vendor extension part into a seperate bean...)
5. Build/release engineer, should be there inhouse already, understand SCM, knows build script(better refreshed with ANT, knows Jikes is much better than javac...), and understand specific AppServer packaging/deploying requirements.
6. Administrator of AppServer, solid knowledge of AppServer(better earn a Certified Administrator title?), they understand the deployment issue and the magic tuning knobs of AppServer. They should better be able to deploy different versions of the solution on the same instance(WAR under different context, EJB under different JNDI names) to save company's licensing cost,
Besides you need domain experts, good OO designer, project manager, 3,4,6 developers you defintely need put some topguns in these tiers.
Struts is good model, but for simple project you can adopt it later. After the people familiar with JSP/Servlet based programming model, and becomes proficient in choosing the right logic/control flow with JSP/Servlet.
Taglib is good, but you can seperate these common tasks to one developer. The others just use it, no need to maintain it.
For Design Pattern, you shouldn't scare green-hands. Do more code review, help them refactor to grasp pattern is much more effecient.
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mike Jones:
[QB... removed ...
And finally, here is the point. The Visual Studio IDE looks excellent. It occured to me that all of those things we think are negative in the J2EE world (vendor lock in and one platform and only one IDE choice) actually may be a positive when it comes to the learning curve required by the developer base. For example, install Windows and install Visual Studio, and you are good to go ...at least they made it look that way . With Java, install correct version of JDK, pick from a large list of application servers, good luck settling in on an IDE, figure out how to get remote debugging to work, figure out what your deployment procedures will be, ANT?
I made the decision that if I was an IT manager, I would eat this extra learning curve for my work force, because I would not want to have to lock into the windows platform. That said, if I was the IT manager, I like the idea of 1 language and 1 platform from a training and support requirement perspective.
So someone give me some feedback. Does anyone else think that the J2EE world is now officially at a severe disadvantage on the tools front when contronting potential clients about J2EE development vs .NOT. I have just spent a very busy 8 months ramping up with J2EE and EJB. I was convinced after watching the Visual Studio webcast, I could be good to go in a much shorter time frame.
???[/QB]



Now take this with a tiny little grain of salt...
I can beat Microsoft at its own game. It's easy -- just forget all other vendors. Just buy all IBM and everything is just as easy as it is with Mickeysoft.
I'm dead serious. You've been deceived into believing that their single-vendor story is better than any other single vendor story.
So, forget about BEA, and Oracle and all the other vendors. Buy WSAD. Install it and bang -- you can build, test and run all the J2EE components and Web services as well. No picking a JDK or installing any extraneous app server necessary. Deployment -- that's as simple as asking WSAD to "export" -- out pops a WAR, JAR or EAR file ready to import into WebSphere.
Team development? -- it's built in. I can choose either ClearCase or CVS right out of the box.
You're thinking that everything is as complicated as your particular environment -- guess what -- since I don't care about other vendors mine's not...
Kyle
 
Mike Jones
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Simon,
Excellent response. That's the difference from someone breaking into J2EE (me) and someone who's been there (you). I wasn't that far off from the real world, but you definetly filled in some of the missing pieces. Question. What's SCM? Answer: SCM = "Source Control Management" Second question: You mentioned an OO design guy. Let's say hypothetically I'm going to use Struts, and follow some sort of design patterns on the EJB side (i.e. facade, etc). I picture the OO design guy / gal taking UML up to "what" is required (i.e. use cases, initial class diagrams, and maybe also helping to drive the entity model). I would then expect this initial "what" requirements handed of to the developer teams which will introduce the "how" (i.e. Struts and design pattern choices) into more detailed UML (i.e. sequence diagrams). This is where I figured outside consultant teams could be sold to the client ... the initial requirements become the contract for what the developers will deliver / build. It seems like their is a definite split of labor here, but maybe you end up with more interaction / iterations. Even if that is true, it still seems the tiered labor not only applies to the developers, but also between the initial requirements gathering and development. Anyway, I really appreciate the response.
Mike
[ February 21, 2002: Message edited by: Mike Jones ]
 
Mike Jones
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
I can take all of the salt you got. I think your response if fair enough. To make an apples to apples comparison, it would need to be made with one J2EE vendor and run on one OS platform. If a 100% IBM J2EE solution is equal to or better than .NET for learning curve, and maybe cost, plus you have the hedge to port to another application server, platform or IDE if required, no matter what the pain... it does seem like a win win. I hope to be able to test that premise in the near future. I'm currently working thru Monson-Haefel's EJB book with your workbook. I'm using Eclipse for now, but will upgrade to the WSAD later. If I understand it right, Eclipse is a base of WSAD, so the learning curve should not be wasted. FWIW, I like what I have seen with Eclipse so far. Plus it has the upside of not rebooting Windows 2000 on it's own, like Forte CE.
I did see a question posted earlier about certification and VAJ. It would seem that if one was interested in IBM certification, they would want to certify with WSAD instead of VAJ. Is it correct that WSAD certification is not available yet? If so, do you have any idea when it will be?
By the way, I have heard there is a WebSphere user group in Tulsa, OK, but have been unable to track it down. I couldn't find it listed on the IBM website. Do you have any ideas how I might track it down... local sales rep or something.
Thanks for responding. I think I just needed to reinforce my J2EE commitment over the last year. Perhaps I baited you a bit, but I like your answer.
Mike
 
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


So, forget about BEA, and Oracle and all the other vendors. Buy WSAD. Install it and bang -- you can build, test and run all the J2EE components and Web services as well. No picking a JDK or installing any extraneous app server necessary. Deployment -- that's as simple as asking WSAD to "export" -- out pops a WAR, JAR or EAR file ready to import into WebSphere.
[unquote]
The problem is that most of us are developers and we do not choose the platform. Its our senior managers who do this. For example I was supposed to work on the IBM platform and now I am working on BEA as the company go me placed over here. So this increases the development curve for a developer working on the J2EE platform.
However there are some advantages too. The basic advantage is what its disadvantage is. I am able to move from one application server to another. Its J2EE compliance that works wonders over here

 
Mike Jones
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rahul,
I agree. There is a difference between a companies perspective, and a J2EE developer. You may be highly skilled with WebSphere, but your next job may be another application server. You are hit with the learning curve. This is not the case if you are a .NET developer. Also, take the case of a company IT manager that has selected J2EE, and only needs his staff to develop software for their company (i.e. company is not a solution provider as Simon described). This manager chooses IBM as a single J2EE vendor. Here is the question. Do you commit your developer's learning curve to all of the IBM proprietary solutions, or do you hedge your bets, and have your developers learn core, more generic J2EE skills that could transfer to other vendors if required down the road. I will give you an example. Let's say WSAD is all over it for deployment, but done in a proprietary way. (This is hypothetical because I haven't used it) Would it be better for your developers to learn procedures seperate from the tool / IDE, like standalone Ant scripts. My point is, do you bet the ranch on IBM at this point, or do you always make an effort to build vendor independent skills. By definition, if you choose .NET, you have bet the ranch. With J2EE, it would seem you can choose to, or not. At a minimum, it would seem like you would want to note where you are using proprietary solutions and have a good idea of what it would take for your development staff to move another direction.
Note: I'm not trying to make a positive or negative statement about any technology or vendor. I'm just formulating my opinions about real issues companies and developers face when making these types of decisions.
JMO
Mike
 
Simon Song
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike,
Yeah, SCM is Source Control Management
For design/architect team is also tiered, you need a group of people involved. Some senior developers are also welcomed, they provide what they can do, how long it will take. So the architect/design team knows when the project can be done. Usually one UI engineer, backend engineer will join the team, many applications should consider UI perspecitve earlier. IBM has User Centric Design apporach, I think it is good. After you gather use cases, let UI engineer think about UI layout. Do more usability research(check with end users earlier for feedbacks), then decide the OID based on the Object Digram, etc.
It depends on the client requirements and budget range, you can push vendor-centric approach first to make sure you can deliver something. Later on, introduce more vendor-neutral technologies(Struts, Ant, whatever) if the client is satisfied with you.
    Bookmark Topic Watch Topic
  • New Topic