IBM releases trial of WebSphere Studio Application Developer

Discussions

News: IBM releases trial of WebSphere Studio Application Developer

  1. IBM developerWorks is hosting a trial version of WebSphere Studio Application Developer for Linux and Windows. Its heavy on capabilities for J2EE development including support for EJBs, XML editors, Web services wizards, etc. Specifically WSAD is a pluggable tool-development and integration platform that works with the Eclipse open-source organization. Theres also a series on how to build and publish a weather forecast Web service using WSAD, WebSphere Application Server, and the UDDI test registry.

    Page with downloads, tutorials, and information

    Threaded Messages (20)

  2. Team Support
     
    Details on how Team Support is managed..........
    "This article presents some how-to information on using the Concurrent Versions System (CVS) team support that comes with the WebSphere Studio Application Developer beta. It is written for users who are already familiar with the VisualAge for Java team development environment..................
    Similar to the VisualAge for Java team environment, CVS is based on a client/server model. In VisualAge for Java, there is a server process called EMSRV that manages shared resources; there is an equivalent server process for CVS.................."

    Full text here...Team Support
  3. I am still amazed that WebSphere only supports EJB 1.1, J2EE 1.3 spec is final and 1.4 on its way…. Why are they so slow?

    Thierry
  4. IBM slow?[ Go to top ]

    I agree... I wonder about this as well... even EJB 1.1 took a long time. This is in stark contrast to IBM's general image concerning Java - which includes (IMHO) enthusiatic support and advocacy of the platform. I would have thought (although I have no personal experience with WebSphere) that IBM was concentrating on quality instead of speed to market, but anecdotal evidence on sites such as this suggest to me that Websphere is a bit quirky and has nothing over its competition in terms of quality.

    I do predict, however, that the days of lagging support for J2EE specs are over. I'm sure Mr. Elison (sp?) is none too happy about the pramati announcement posted earier here!

    If its any consolation to IBM's past record with WebSphere - not adopting the new standards rapidly wouldn't have made a difference to companies such as my employer... where entity beans and container managed relationships are viewed upon about as favorably as replacing the mainframe with a Commodore VIC-20. (I'm a huge fan of the new stuff though - btw). Luckily I was able to get them to bring Weblogic in... so I can sneak in using the new features when no one is looking :)
  5. IBM slow?[ Go to top ]

    Just a funny remark made by a colleague here at work about the Eclipse project and IBM. Eclipse = block/impede (the) Sun ;)

    -krish
  6. IBM slow?[ Go to top ]

    I dont think so, Ihave just finished developing a medium scale application with W/S V 4 and let me tell you WebSphere 4 is Dogs **** even if it supports ejb 1.1. All our development was done using WebSphere Application Developer, and speeded up devlopment by 50% easy.

    WebSphere App Server:
    1. Has great capeabilities for load balancing. ( I deployed a horizontal scale Architecture
    2.Easy to deploy applications.
    3. J2C easy to add connectors use.
    4. Super fast OK some apps were sitting in the same JVM still quite impressive as the apps were talking to legacy systems.
    5 list endless.

    WebSphere App Developer:

    All I can say you have to try it to believe it!!!!!!

    feel free to email for more info: mbabur at ukonline dot co.uk
  7. Specs are not the only thing that goes into the release of a product.
    J2EE 1.3 just became final last month. No application server is fully 1.3 certified, WLS 6.1 is based on the final draft. WLS's own documentation claims to use the 1.3 spec with care.
    IBM ensures specs are final and well accepted by customers before throwing there ducs in the basket. The next release of WebSphere will be 1.3 and it will be here sooner than you think.
    Currently, WebSphere 4.0 and WSAD support relationships and EJB QL from the EJB 2.0 spec. WAS 4.0 addresses itegration, developement to production, and has solutions to most real world problems.
    In most situations, object-relational mappings are over-kill. Most of the time replicating a data model into the application is a big waste of time for an application that can issue a simple query.
    The specs alone do not solve business problems.
  8. Agreed !

    Besides for Message Beans, there is really nothing good in the latest EJB specs -> 1.1 is more than enough.
    WS 4.0 supports msg beans in a non standard way. It should be fixed in the next version.

    Anyway, I am stil waiting for JDO (or any other real O-R mapping API) to become part of the J2EE spec and that's not going to happen soon. EntityBeans are just a joke.

    So please don't complain too much about WS features. It's more than what you need in 99% of the cases.

    OR
  9. EntityBeans are just a joke.


    Ah yes, the EntityBean. Whipping boy of preference for many on here... While I've never seen a funny entity bean per se - I have seen them used in funny (or rather sad) ways. With proper demarcation they have been quite effective for me in isolating massive amounts of concurrent transactions. There are those of us who see great value in the new CMRs and query language (or more generally the option to abstract resource tier details away from Java code). Actually I'd go as far as calling 2.0 CMP elegant. I think at least some of Entity Beans' poor reputation stems from improper/naive use, rather than the spec itself.

    The whole debate is analogous to the one which initially surrounded Java itself. That one involved people who saw potential, people who didn't get it - joking about it instead... causing it to gain a generally bad reputation (even 'me' I admit at one point), and people who worked on it to the point where the naysayers generally look like an essentric minority. History repeating?

    I do admit I know little about JDO... other than its not widely implemented and relatively new. I'm (genuinely!) curious... are objects persisted by JDO inherently aware of transaction demarcation like entity beans? Its not my intent to comment on JDO's merits - but I suspect its reputation benefits from its own relative obscurity. In my case -for example- you can say what ever you want about JDO... I can't counter you anymore than the people who used to blah blah blah about the Amiga.

    But anyway - concerning IBM Websphere and the comment that IBM will wait until a spec is popular with its customers until offering it... basically that could be interpreted as saying IBM lets demand build up to a threshold before offering a solution. No thanks - I would prefer the options to be put before me so I can decide what fits best, instead of standing in IBM's "customer demand" queue.

    cheers,
    Markus
  10. My statements, again, were addressed at object-relational mapping in general. I have implemented many Entity Bean applications, and understand EJB 2.0 quite well. Calling people names, like naive, is not the answer. I can call you naive for some of your comments.

    >>With proper demarcation they have been quite effective >>for me in isolating massive amounts of concurrent >>transactions.

    I'm glad this was effective for you. This can be accomplished with Session Beans, the Command Pattern, and JDBC. It was quite elegant and effective for me. I did not call one begin or commit.

    >>The whole debate is analogous to the one which initially >>surrounded Java itself. That one involved people who saw >>potential, people who didn't get it - joking about it >>instead... causing it to gain a generally bad reputation.

    Stick to the topic rather than getting into a whole philosophical issue. No body attacked Java or EJBs, just Entity Beans.

    >>are objects persisted by JDO inherently aware of >>transaction demarcation like entity beans?

    Transaction demarcation is not just an Entity Bean feature, Session Beans handle demarcation as well. The only transactional issue that Entity beans handle that Session Beans don't is moving synchronization and concurrent access up into the entity layer rather than letting the database do it. However, in a real world application, databases are usually accessed my many applications making this feature of Entity Beans useless or overkill.

    >>basically that could be interpreted as saying IBM lets >>demand build up to a threshold before offering a >>solution. No thanks - I would prefer the options to be >>put before me so I can decide what fits best, instead of >>standing in IBM's "customer demand" queue.

    IBM is addressing customer's demand and offering a whole software platform full of products. I don't think automaotive companies are sitting there saying, if my app is not J2EE 1.3, i can't sell cars. Or a brokage company is saying, if I don't have EJB 2.0 and its EJB QL, my trading application will suffer greatly.



  11. My statements, again, were addressed at

    > object-relational mapping in general.

    I wasn't responding to your statements or your post and I'm actually not sure what the point of you responding to me was. Considering this is a place to shoot the breeze on all things J2EE this kind of banter would have been enjoyable except for the lame attempts to make yourself my moderator.

    I WAS responding specifically to...

    >>> EntityBeans are just a joke.

    >> I think at least some of Entity Beans' poor reputation
    >> stems from improper/naive use, rather than the spec
    >> itself.

    > Calling people names, like naive, is not the answer. I
    > can call you naive for some of your comments.

    You just did - undermining whatever point you were making. I'm not sure what "answer" you are referring to- but I haven't called "people names". I have seen Entity Beans being implemented without the developer having a proper understanding of what they are doing. That's what "naive" means - their ACTIONS were naive. You're responding as if you read "anyone complaining about Entity Beans is naive".

    > replicating a data model into the application is a big
    > waste of time for an application that can issue a simple
    > query.

    So this situation would not be a proper use for entity beans and O/R? Could such an improper implementation contribute to entity beans' poor reputation due to it having been "a big waste of time" and probably achieving suboptimal performance? How useful would it be to switch to another O/R mapping technique like JDO when the problem is that O/R is the wrong tool anyway?

    >>are objects persisted by JDO inherently aware of >>transaction demarcation like entity beans?

    > Transaction demarcation is not just an Entity Bean
    > feature, Session Beans handle demarcation as well.

    I'm not talking about demarcating transactions ... I'm talking about an object being inherently AWARE of transaction demarcations... in which case what you said is not true unless the session bean is stateful and you implement and flesh out the SessionSynchronization interface. My question specifically concerned JDO persistence.

    > ...rather than letting the database do it.
    > However, in a real world application, databases are
    > usually accessed my many applications

    I'm glad its the "real world" we are talking about because WLS 6.x uses database locking for managing concurrent entity bean access by default. It DOES let "the database do it". Regardless - none of this precludes there being situations where an exclusive lock on the bean instance would be acceptable/desirable if you were in fact restricted to only having such a lock (is that a Websphere thing?).

    > No body attacked Java or EJBs, just Entity Beans.

    "Attacks" on Entity Beans are exactly what I am responding to and I'm glad you've recognized them as such. But where do you see me defending EJBs or Java? What are you talking about? I drew an analogy between Java's early rocky reputation and that of Entity Bean's current one. Didn't like it / didn't get it? Aww shucks.
  12. No one here is trying to be your moderator. I was responding to some of your comments about Entity Beans. No matter what you say, your comments seem to imply lack of understanding to the individuals who use Entity Beans.

    Applications read, update, creates, or deletes data. If you can give me a situation where Entity Beans are an ideal canditate over Session Beans and JDBC, please let me know?

    I don't use JDO, anyway, I'm sorry if you felt I was insulting you because I was not trying to.
  13. I'm sorry if you felt I was insulting you because I was

    > not trying to.

    Ditto here - I was up a little too late last night. I was not intending for anything to be taken personally.

    Yes - it is my opinion that Entity Beans have been used before being understood... and that they have performed poorly because of this. This is not meant as a comment on the capability of the people who did this... there may have been all kinds of reasons for it (deadlines / lack of mentoring availability etc etc)... rather I only mean to point out that its not the fault of the specification itself.

    A situation where Entity Beans are an ideal candidate over Session Beans? I assume you mean sending a data value object to a Session Bean for persistance? I suppose this could be an entire book chapter. The very short answer is this: if you understand and are comfortable with the Entity Bean specification it doesn't appear complicated to you anymore. At this point you have available to you a:
    standardized / componentized / optionally network accessable / completely transaction isolation capable / scalable / portable / vendor speed optimizable (because its BEA or vendor X's job to wring every last millisecond out of the resource tier interaction - not yours... if BEA falls asleep at the wheel, vendor X is there to take over). You can worry about the and resource tier decoupled (in the case of CMP and a lack of JDBC)



    I regret this conversation developed the tone it did and also that it happened under a non-directly related heading.
  14. Ack - that post got cut short by accident. Let me just mention the following... because I don't hear the idea being discussed (probably because I haven't looked hard enough):

    One of the problems I had with Entity Beans under 1.1 was that it made little sence to generate a list of account names (for example) by grabbing and instantiating all of the account entity beans in the domain and then pulling just their names.

    Yah - there were some ways to optimize this, but wouldn't most people have added a method on a SessionBean to handle the task - especially if there are many similar tasks? Now there is the unpleasant situation of several sources of truth for the same information in the resource tier. At least I find this unpleasant.

    While partitioning of the fields within a 2.0 entity bean is an intriguing option I'm more interested in the new ability to move these types of methods to the Bean Homes. More importantly - and what really captures my imagination -is that the home methods also have access to the EJB-QL and the representation of your domain within it.

    Now it should be possible to get the same set of account names without circumventing the container that manages the entire account object domain and more importantly doing so efficiently. Now there is a single component acting as a source of truth for the resource tier wrt the account domain.

    I'm no container persistance code expert, but even I can think of optimization possibilities - the best part is... its NOT MY PROBLEM! its the app server vendor's. And I'm expecting all kinds of optimizations to happen here for my $10K/cpu. If not - hello vendor b, c, -> zz.

    Does it mean the end of JDBC in future development efforts? OK OK - I can hear the laughing, but I think there is the longterm potential to move towards that on domain objects represented by Primary Keys. Final Draft 1's dependent objects would have been nice, because the PK wouldn't even have needed to be present.

    ahh... back to work writing JDBC persistance code (for now),
    Markus
  15. I was not intending for anything to be taken personally.


    Me neither, I like having these discussions and able to give and take.

    >>The very short answer is this: if you understand and are >>comfortable with the Entity Bean specification it doesn't >>appear complicated to you anymore. At this point you have >>available to you a:
    >>standardized / componentized / optionally network >>accessable / completely transaction isolation capable / >>scalable / portable / vendor speed optimizable (because >>its BEA or vendor X's job to wring every last millisecond >>out of the resource tier interaction - not yours... if >>BEA falls asleep at the wheel, vendor X is there to take >>over). You can worry about the and resource tier >>decoupled (in the case of CMP and a lack of JDBC)

    I think that the specification has potential, I have to say that most situations, either at the code level or deployment level, 100% portability never happens. To my knowledge, CMP implementations are backed by JDBC. Weather the code is generated or coded, switching vendors would not be a problem, weather it be JDBC or CMP. Switching databases would be an issue in both cases. I feel assessablity and isolation can happen either with Session beans or Entity Beans. Decoupling the different tiers are a matter of design. I feel Java 2 Connectors are really an area the can greatly decouple the application.

    Anyway, I enjoy these conversations and feel nothing personally. I have a great deal of respect for people in this industry.
         

     

  16. IBM ensures specs are final and well accepted by customers before throwing there ducs in the basket.

    Every vendor does the same. How would customers accept new specs?

    Kumar.
  17. <quote>
    Every vendor does the same.
    </quote>

    Actually, no. We implement specs before they're even written.

    --
    Cedric


  18. Cedric,
     I missed IF at the begining.


    Kumar.
  19. Premature implementation[ Go to top ]

    Cedric,

    > Actually, no. We implement specs before they're
    > even written.

    And reimplement them after they (the specs) are written as well? ;) Your comments would also imply you are "certified" compliant before the specs are released as well? (Well the specs have been finalized for what - over two months now . . . ?)

    -krish

  20. >> "Currently, WebSphere 4.0 and WSAD support relationships and
    EJB QL from the EJB 2.0 spec. WAS 4.0 addresses itegration,
    developement to production, and has solutions to most real
    world problems. "

    Yes, and it implements all these (and the "Message Bean") in non standard ways.
    You have to use external XML deployment descriptors for EJBQL. You have to use the Websphere-specific descriptors (XML or database, depending on your version) for the entity relationships.
    Also, the "Message Bean" is just the pre-MDB, JMS consumer + Session Bean pattern used by developers - not at all the Message Driven Bean.

    It depends on how much importance you place on the portability of your application. It seems a waste to spend the effort on writing a J2EE application only to immediately throw away the vendor neutrality that it gives you by using vendor specific features. Why not go with a proprietary platform? Perhaps the proprietary platform is better suited to your problem domain.(?)

    I guess if you are happy with IBM and never want to move away from Websphere, then you wont think twice about the non-standard implementations. Its the difference between being standards compliant and "standards-based".
  21. IBM is not slow. Check out http://java.sun.com/j2ee/compatibility.html. What do you see under J2EE 1.3 certifications?
    - COOL:Joe
    - WebSphere App Server TD
    - Sun's SDK 1.3

    Where is Oracle, BEA, iPlanet?... What I really like about IBM is that it is doing real work more than marketing and benchmarketing. (Since there is a lot of marketing, there is even more of real work)