Discussions

News: BEA launches WebLogic 7.0 Beta, Weblogic Workshop, Dev2Dev

  1. Major announcements have come from BEA at this weeks BEA eWorld conference. BEA has announced J2EE 1.3 certified Weblogic Server version 7 beta, a new IBM DeveloperWorks-style developer portal called dev2dev.bea.com, and Weblogic Workshop: a new visual-basic style tool for building J2EE apps (formerly known as Cajun).

    Get it at WebLogic 7.0 Beta Download.

    Check out BEA's new Developer Portal: http://dev2dev.bea.com, where you can download a beta of Weblogic Workshop.

    Read about Weblogic Workshop.

    View Documentation at WebLogic 7.0 Documentation.

    Threaded Messages (44)

  2. One Disappointment is JMS is still not *really* clusterable.

    From Docs:
    http://e-docs.bea.com/wls/docs70/jms/intro.html
    "JMS topics and queues are still managed by individual WebLogic Server instances in the cluster."




    And hence there exists a Single Point Fail Over. Hope fully final version will have real JMS Clustering.

  3. It seems to me that JMS is in fact clusterable. The following is from the Release Notes:

    ===========================================================
    Distributed Destinations within WebLogic Clusters

    The highly available implementation of WebLogic JMS offers a level of redundancy, and therefore service continuity, in the event of a single Weblogic Server failure by enabling you to configure multiple physical destinations as members of a single distributed destination set. Specifically, an administrator can configure multiple instances of a given destination within a WebLogic Server cluster. If one instance within the cluster fails, then other instances of the same destination will be able to provide service to JMS producers and consumers.
    ===========================================================

    I think the problem is that BEA just takes the old documentation and slaps the new version number on it until they actually get around to updating all the documentation.
  4. Re. clustered JMS: WebLogic Server 7.0 does in fact provide high availability distributed JMS.

    WebLogic Server 7.0 JMS allows you to distribute your JMS destinations (quques and topics) across multiple servers within a cluster. This is configurable through the administration console, and is a completely new feature in this release.

    Here is how it works: you application knows only about logical JMS destination - the same way it was before.

    A logical destination can actually map into multiple physical destinations on different servers. When a message arrives to a logical destination, it is actually delivered to any of these physical destination thus delivering load balancing capability. The distributed cluster-wide JNDI tree knows about all the destinations. In case any of the physical destinations goes off line for some reason, it's removed from the tree. The logical destination, however, still remains functional. The users don't notice anything.

    A similar approach has been, and still is used for the distributed JMS message factories.

    What you've found in the documentation is probably not-yet updated text from the previous release where it was true. This will be fixed. Thanks,

    Vadim Rosenberg, Tech. Product Marketing Manager, WebLogic Server, BEA Systems.
  5. I talked to Zach, the BEA JMS architect, at eWorld at JMS destination clusterabliity. So here's the real scoop, without any marketing spin :-)...

    JMS destinations in 7.0 can failover, but are not replicated. For example, you can deploy multiple persistent queues with the same JNDI name across all nodes of a cluster. A client will hit just one until that node fails, in which the cluster will transparently failover the client to the next available node/queue. HOWEVER, what's stored in the first queue remains in the first queue (since its persistent) until someone manually brings that node back up.

    Needless to say, I was sorely disappointed by this. I would still like to see a primary-secondary replication failover queue, a la HTTPSession replication, but this is not happening in 7.0. Hence JMS is only halfly-clusterable now, not wholely clusterable.

    Gene
  6. WLS JMS clustering has been improved. It is not perfect, but is much better. The concept of a distributed destination set helps remove the single point of failure from a message sender (producer) perspective.

    From WLS 7.0 Documentation
    ----------------------------------------------------------
    WebLogic JMS offers a level of redundancy, and therefore service continuity in the event of a single Weblogic Server failure by enabling you to configure multiple physical destinations as part of a single distributed destination set. Producers and consumers are able to send and receive to the distributed destination. WebLogic JMS then distributes the load across all available physical destinations within the distributed destination.
    ----------------------------------------------------------

  7. WebLogic 7.0 JMS offers two levels of fault tolerance
    1. Distributed destinations. This allows more than one physical destinations (queue/topic) for the same virtual name. This allows for uninterrupted operation in case of machine failure. The inaccesible element of the virtual queue is off line and when restarted, it joins the cluster and adds itself to the virtual queue.
    2. Migratable instances. If there is a single instance of a JMS destinationon one node. In case of a crash this can be migrated to another node. This assumes that the data is still accessible from the migrated node (using remote JDBC or dual ported disks). This is usually referred to as failover.

    These features should satify all requirements of high availability.
    I am curious to get input from folks that think that more is needed. What would you like to see more in this area?

    Amrit Bains
  8. Weblogic Workshop (Cajun) is very impressive. They have developed a 2 way mechanism for editing/creating WSDL and Java classes. One way of going is to write a Bean and have Cajun expose the Bean's methods as Web Service (SOAP) methods. Another way to go is to visually edit the SOAP methods and the Bean methods change too. Very nice.

    -Frank
  9. Workshop is a love-at-first-sight. Nice, breezy look and feel along with lots of useful tools that will certainly help the developers. A winner. Will have to work more to comment on the stability.

    "Design View" gives a real nice snapshot of the code.
  10. I've downloaded the WebLogic Workshop Beta and gone through the tutorial. My initial impressions are mixed:

    Good Stuff:

    - Easy installation. Compared to Visual Studio .Net this is a breeze
    - Nice look and feel. Its a mix of Visual Studio .Net and IntelliJ
    - Good testing harness for web services. This could be one of its killer features.

    Bad Stuff:

    - Only lets you create web services
    - No integration with source code management systems.
    - No support of IDE plug-ins

    There are plenty of big issues that I'm undecided about. The first issue is how comfortable I would be locking myself into this development methodology. (the big thing is the format they have that define web services - .JWS files) Granted, the lock-in you have to accept in using this tool is going to be less then the lock-in you have with Visual Studio .Net, but it is an open issue.

    The other big issue is how much the tool seems to push asynchronous web services. Take the tutorial and you'll see what I mean. I don't buy it that these are needed all that often.

    -Alan
  11. How do you mean lock-in? My take on Cajun - pardon me but I just like the name Cajun so much more than Weblogic Workshop :-) - is that they are using JavaDoc comments to tag the exposed methods in a SOAP-based Web service. The same classes would compile in other IDEs. Have I missed something?

    -Frank
  12. DOUBTS
    ======

    (1) How open is the Workshop? How much is the "lock-in" fear? Any comments on how easy would it be to cross-deploy the applications developed in Workshop to other app servers?

    (2) Ease of use comes with a cost. Is the ease of use for not-proficient-java-programmers a burden for proficient-java-programmers.
  13. Hi Everyone-

    I had the wonderful pleasure of actually getting to deliver the WebLogic Workshop demo on stage with our CEO Alfred Chuang this morning. And, I'm here to tell you that WebLogic Workshop is 100% open and doesn't have vendor lock-in. Now that it's out, I can tell you all about it.

    The JWS format is a standard that we are working with Sun and a number of other vendors to publish as a JSR. It works like JSP: there are no proprietary libraries -- it's just Java code with JavaDoc annotations. The annotations and format will be part of a spec. The JWS file resides on a server and is hit just like a JSP file would be hit from a browser. When the JWS file is hit, a J2EE EAR file is created and deployed into the server. If the JWS file is modified, the EAR file is recreated and deployed. Since JWS is a standard, we encourage other vendors to support it (meaning that any JWS file will operate on any other application server). Right now, WebLogic Server 7.0 is the first platform to support this format. The tool environment we provided was more of a reference graphical representation for the standard that other tool vendors could support as well.

    So, in the end, there are no proprietary libraries that are used. You should really give it a shot.

    And, by the way, I think that GA will have code repository capability -- keep in mind that this is the beta.

    Tyler Jewell
    Director, Technical Evangelism
    BEA Systems, Inc.
  14. Tyler,

    Thanks for your post. Please let me elaborate on some of my points from my post.

    First, in my opinion standards are good but I'm becoming disillusioned with the standards processes that are in place (JCP and W3C in particular). So I would be willing to accept something that is not a standard as long as it is documented and open, and as long as the vendor is on record as commiting not to change the interfaces.

    You said in your post that "The JWS format is a standard", but its seems at best disingenous to call the JWS format a "standard" at this point. Unless I'm wrong the spec is not submitted yet, and specs have a habit of changing during the JSR process. I doubt that even BEA would have the power get a JSR spec rubber stamped.

    Unless I really missed something in the Workshop docs, there was no mention of a code repository in the section describing the beta limitations. I didn't see anything about it in the marketing materials either. Speaking of the docs, why is there no PDF of the Workshop docs available? Its really terrible to try and read them by paging through countless HTML files.

    Again, thanks for posting.
  15. Tyler,

    Where can I find more information on WebLogic Workshop? White papers, etc. The only option I seem to have is to download and install the beta, which requires I download and install WL7. Kind of drastic!

    Also, pretty much every link I tried on your dev2dev.bea.com site is broken - page heading displays and then nothing!

    BTW, BEA appointing itself as a standards making body and generally devaluing the term 'standard' is not in BEA's interest.

    regards

  16. I've put together a knowledge kit to show how WebLogic Workshop puts together Web services. The knowledge kit is at http://www.pushtotest.com/ptt/thekit.html. You'll also find a sample Web service called Curmudgeon and a test agent that test Curmudgeon. Hope you enjoy it. -Frank
  17. Hi Tyler,
    While you are answering questions one more for you. what are the damages.. er costs associated with Weblogic workshop? I couldn't find enough info on your website.
    BTW it looks good and I would love to buy it as long as It doesn't shoot a big hole in my pocket.
    Thanks
    Ravi

  18. WebLogic is NOT the ONLY platform to support JWS.

    Apache Axis supports them too.
    http://xml.apache.org/axis/index.html


  19. I don't think the AXIS jws is same as BEA jws. I could not find AXIS jws using the javadoc mechanism to define the behaviour of your webservices.

    Vimal

  20. > WebLogic is NOT the ONLY platform to support JWS.
    >
    > Apache Axis supports them too.
    > http://xml.apache.org/axis/index.html
    >
    >
    >

    Hi,

    We want to know the differences between AXIS and weblogic 7.0 web services, and
    which is better.

    Thanks

  21. The real news today is this press release. BEA has aquired Appeal Virtual Machines -- the people who make JRocket (http://www.jrockit.com).

    -nate

  22. Aha! I was wondering what was gonna happen to them. So now we have three big VMs with big company support. IBM/Sun/BEA. And knowing the guys at Appeal, I think BEA made a great deal.

    Good luck Appeal and BEA!
  23. So, first, you guys all need to keep in mind that this only a BETA, not the GA release. So, that means that there are certain things that aren't available and won't be available until GA: white papers, PDF documentation, code repository support, etc.

    Second, WebLogic Workshop is NOT a standalone product. In fact, the value in what we have is the runtime, not the GUI that comes along with it. The JWS format requires a server to take the format and create EAR files from it. We just happened to throw an IDE on top of the format to make it easy to edit it. But, given this, WebLogic Workshop isn't a standalone product, rather a runtime service that's part of WLS 7.0 along iwth a reference IDE. In fact, there are other tool vendors that are already looking at supporting JWS natively in their own tools. There will be nothing stopping other runtime vendors from supporting this technology.

    Third, we are working hard to drive this into the standards body. This takes time (JSPs started out as JHTML, etc.). But, it will happen.

    Finally, we are not talking about packaging and pricing at this time -- that will be announced at GA which is first half of this year (read < 4 months). Even though I can'te tell you about pricing, I can tell you that we are migrating AWAY from our SDK model and engaging in a subscription model. This is great news for the developer community because the entry level subscription will provide developers with support and development licenses that have a very long expiration time (we can't reveal that right now, but it's really good).

    Tyler
  24. I havent downloaded 7.0 Looking at the way Weblogic is heaading towards...looks like it is comming out with a tool like TogetherControl Centre...Am I right in saying so ? is there UML drawing tool support also......


    regs
    Rajeev
  25. Mr Ty;er,

    Can you name a few vendors who are considering implementing jws format? In one of your earlier postings you seem to be implying as if the sun has already bought into this idea and it is about to become a standard and a subsequent posting from you seem to be implying that BEA will be working hard to push this into becoming a standard? Obviously there is lot of difference between the two. Can you please try to clarify?

    Vimal
  26. Finally, we are not talking about packaging and pricing at >this time -- that will be announced at GA which is first >half of this year (read < 4 months). Even though I can'te >tell you about pricing, I can tell you that we are >migrating AWAY from our SDK model and engaging in a >subscription model. This is great news for the developer >community because the entry level subscription will >provide developers with support and development licenses >that have a very long expiration time (we can't reveal >that right now, but it's really good).

    You mean I can't buy it off the shelf just like VB and will have to keep paying BEA for the privilege of developing web services :(.
    But I thought that this was like visual basic for web services ???
  27. Many VB developers get their environment as part of an MSDN subscription though.
  28. Tyler,

    Subsciption model? Sounds like M$ stuff ... Cent per call ...
    What will happen with companies who already have licenses for WL?. It will expire in near future?
  29. Will 7.0 support Java 1.4?
  30. Workshop comes with jdk1.4 ; so I suppose 1.4 support is present.
  31. We've done considerable work with JMS, WebLogic 6.x and clustering and gave input to BEA regarding the lack of clustering and some suggestions.

    Although destinations can now be distributed there is no failover of the persisted messages pertaining to that server. So you need to find some mechanism for retreiving thee messages yourself or perhaps associating the persisten store holding these messages to a new server and add this to the cluster. Tey automating this using JMX. A christmas cake to the first to provide an automated implementation for this.

    WebLogic JMS is on the whole just about there, but it is not ready for the big time, in my opinion, until it provides FULL clustering.
  32. Tyler,

    Will 7.0 use NIO you run on 1.4? I also noticed that 7.0 is already significantly faster than 6.1 is...
  33. Hi Guys-

    WLS 7.0 will ship GA in the first half of this year on 1.3.1 JDK, but will be certified on JDK 1.4 VERY shortly after ship. We are seeing huge performance gains on the new JDK so we want to get there quickly.

    Tyler
  34. I had some fun trying out the Weblogic Workshop, it's a pity BEA does not offer the same nice environment for EJB,JSP, etc. development. It seems to be a really productive tool. The look and feel is also very impressive.

    However these new "Controls" make me feel uneasy, anyone tried them?

    For example the way the documentation and the sample explains how you can access databases with the database Control, is really looking good on a "Hello World" app, but to use something like this in a proper application environment, goes against most of the design principles.
    Basically you have the SQL statements in the javadoc tags, and magically through the opened jdbc connection, you will get back the result set which will travel as xml to the web service's client.
    It looks like embedding SQL statements in JSP pages really.
    Now there's a good chance that the tool actually generates a set of properly designed components, but by seeing the jws code it clearly not makes you think about MVC patterns or caching or any performace optimizations.
  35. <quote>
    I had some fun trying out the Weblogic Workshop, it's a pity BEA does not offer the same nice environment for EJB,JSP, etc. development.
    </quote>

    We do: check out WebLogic Builder (next to Workshop in the Start menu).

    This tool supports J2EE files (.ear, .jar, .war, .rar) but not JSP's. Other features include:

    - automatic creation of EJB descriptors
    - smart compilation
    - fetch information from a running server
    - deployment to a server

    Check it out.

    --
    Cedric

  36. <quoted-quote>
     Posted By: Cedric Beust on February 27, 2002 in response to this message.

     <quote>
      I had some fun trying out the Weblogic Workshop, it's a pity BEA does not offer the same nice environment for EJB,JSP, etc. development.
     </quote>

     We do: check out WebLogic Builder (next to Workshop in the Start menu).
    </quoted-quote>

    Hey Cedric. Look into my eyes: You want to play golf.... ;^)

    My interpretation of his comments are that Workshop supports the authoring of web services, creating new code*, but that he doesn't see a tool that provides the same support for the other types of server-side components.

    I don't believe Builder supports the creation of server-side components, but, rather the packaging/configuration/deployment of existing components. Is that correct?

    * - There's more to authoring than creation, such as packaging/configuration/deployment and testing, version control, publication, etc.



  37. Where is the Builder link? I looked for it but I'm not sure where the "start" menu is. Checked dev2dev and bea.com ... I found a Builder tool for Tuxedo mentioned in the press releases.

    Sorry I'm so clueless about this. But I'm really interested in this.

    Thanks,
    Steve
  38. <quote>
    Where is the Builder link? I looked for it but I'm not sure where the "start" menu is. Checked dev2dev and bea.com ... I found a Builder tool for Tuxedo mentioned in the press releases.

    Sorry I'm so clueless about this. But I'm really interested in this.
    </quote>

    In the beta, go to the BEA menu and you will see both WebLogic Workshop and WebLogic Builder next to each other.

    You can also start the tool with "java weblogic.marathon.Main".

  39. Ugh, no jdk 1.4. Well, unless our client is begging for faster performance (and I doubt they will), there won't be much reason for us to upgrade to 7.0. Guess we're stuck with an old jdk.
  40. Will 7.0 use NIO you run on 1.4? I also noticed

    > that 7.0 is already significantly faster than 6.1 is...

    BEA's certification of 14 will more than likely not add NIO support.

    Sun delayed 14 at least once, possibly more to ensure that NIO was cooked. As such integrating with NIO near the end game of 14 and our own 7.0 became too much.

    Cheers
    mbg
  41. About the Builder tool:
    It is more of a deployment tool for EJBs, while Workshop is a full-fledged development environment for Web Services.
    Even the look-and-feel is different.
    I really don't know how you could equate the two.

    Please, someone from BEA, react on the other part of my message as well, it worries me that noone tries to convince me that these "Controls" are not evil :)
  42. Please, someone from BEA, react on the other part of my

    > message as well, it worries me that noone tries to convince
    > me that these "Controls" are not evil :)

    Balazs, I am a BEA developer on the Workshop team. This probably means I am both somewhat well-informed as to the implementation details and also somewhat baised ;). I'll give your concerns a shot.

    In your previous post on this thread, you mention some concerns that are specific to the Database Control that is included in the Workshop Framework.

    The basic goal of the Database Control (as with most Cajun controls) is to provide an interface for accessing the services of an external resource using an interface that frees the developer from having to worry about many of the messy details normally associated with access to the resource using standard J2EE APIs.

    In the case of the Database Control, we are talking about database access via JDBC. The control allows the definition of a method signature, the mapping of method parameters to values within a SQL prepared statement, and a mapping of the statement results back to native Java type The knowledge required to perform database operations using the control amounts to an understanding of basic Java datatypes and SQL. Required knowledge of JDBC APIs to achieve this: zero!

    The run-time for the control does work to provide efficient resource allocation and caching on behalf of the service developer to fulfill the semantics implied by this contract. In hiding many of the details, it has an opportunity to both optimize on the developers behalf and to avoid many common mistakes the developer might make if writing the code themselves. A case in point: you'll notice that the database control examples don't include any of the try/catch/finally logic you'll invariably find around code accessing JDBC connections. A common 'newbie' mistake is to omit this and leak connections under exception or other premature exit conditions. With the database control, there is also an implicit guarantee that the connection is being managed in way that guarantees that a leak will never occur, no matter what code the developer using the database writes.

    > Now there's a good chance that the tool actually
    > generates a set of properly designed components, but by
    > seeing the jws code it clearly not makes you think about
    > MVC patterns or caching or any performace optimizations.

    Workshop (by virtue of its generation of J2EE components) and the simplified resource abstractions provided by controls does seek to reduce the scope of design and architectural decisions a developer has to make to get the ball rolling. There is no reason you should have to be a certified J2EE architect and have knowledge of all relevant J2EE APIs and architectural options just to write business logic. And remember, at heart a JWS file is just Java. If the simplified abstractions are too simple or inappropriate for a specific use case, there is always the possibility of replacing them with exactly the same J2EE code you'd have written without them.

    The "goodness" of controls: the developer doesn't have to learn how to write this J2EE code on day one. With the Database Control, they don't have to have mastered JDBC to execute their first query against the database. Similar logic applies for using the JMS Control (to simplify reading/writing JMS messages), the EJB Control (usage patterns for EJB client APIs), etc.

    I firmly believe that for many application use cases, they'd never need to learn these things, but hopefully you can agree that not making this knowledge a prerequisite to leveraging J2EE is a good thing for the platform, for the developer, and for the companies that pay them to get real work done.

    There will always be a need for J2EE architects capable of making good design and architecture decisions, but at heart, Workshop seeks to broaden the scope of what can be accomplished with J2EE for those who are not architects.
  43. Open or Not - Are controls Evil?[ Go to top ]

    Hi all

    I've taken some time to download and evaluate WebLogic workshop, and have concentrated somewhat on the open issue.

    BEA claims that any applications generated through WorkShop - using controls (ctrl files) and java web services (jws files) will be able to be ported to any J2EE compliant application server. That is, they are not doing anything proprietary.

    I looked at one example - the lucky numbers sample. This uses a data base control - LuckyNumberDBControl.ctrl to create a table, insert some rows and do queries.

    When this is compiled it generates a LuckyNumberDBControl.class file. No java file is generated, so you will not be able to modify the source.

    On further investigation, this file extends from weblogic.jws.control.DatabaseControl. This file is in the server\lib\knex.jar file. Looking at the LuckyNumberDBControl.class file shows that there are no DB statements in this class, it's just an interface. The actual DB statements seem to be in the LuckyNumberDBClient.class file.

    Moreover, this class file seems to be more than just a class file. It contains not just the DB statements, but also the full WSDL document and the source code for the client class file. Can this file be loaded using a standard class loader, or do I need something special to interpret the other stuff lurking in the byte-code?

    My guess is that this means the applications built with WorkShop are portable, providing you can also use the proprietary WebLogic classes needed to power the controls and web services.

    Questions for BEA:
    1) Will BEA allow their jar files to be distributed in ISVd products created using the workshop
    2) Will this be allowed for none weblogic installations (IBM WebSphere for example), since most ISVs will not want to be limited to one platform
    3) Is the bytecode being used for the genarated classes standard or proprietary?

    Questions for Sun, IBM, Oracle, Borland, etc:
    1) Will you guys be supporting the .jws and .ctrl mechanism for creating applications?
    2) Will you support BEA in making this a J2EE standard through any JSRs?

    Dave
  44. Open or Not - Are controls Evil?[ Go to top ]

    It seems that BEA's claim that a JWS/CTRL can be deployed to any J2EE-compliant app server should be qualified to say that the app server must also support the JWS/CTRL formats.
    <p>
    I think we're locked into WLS until other app servers start supporting these standards, just like we had limited choices on JSP servers before they became universal.
    <p>
    I doubt BEA would condone you using weblogic.jar in other app servers.
  45. Regarding the JDK 1.4 NIO package, we have not converted to it in 7.0, and are still supporting our own native io libraries. We experienced problems with the NIO implementation in the JDK 1.4 betas; I don't know if they were ever resolved.

    As far as I know, the product works pretty well under JDK 1.4, but we have not yet had time to do a full certification.