BEA Weblogic 6.0 beta is available for public download. Weblogic 6.0 features almost full EJB 2.0 support (no dependant objects yet), J2EE compliancy, a distributed transaction manager (two phase commit), clustered JMS, web based administration (no more weblogic.properties or weblogic.classpath), and more.
Read BEA's press release
Download BEA Weblogic 6.0 beta
Wow! Looks like a complete overhaul of the familiar directory structure. I spent 30 minutes and still could not find the weblogic.property file. This is a config.xml which has some of the functionality of the property file. The myserver directory is replaced my mydomain also.
Hi everyone. My name is Tyler Jewell and I'm the Worldwide Technology Strategist for Education at BEA. I'm intimately involved with the strategy for educational services support of WLS 6.0. As a result, I'm very familiar with the new version of the product and the many new features that it has to offer. If anyone has any questions about the new release, please feel free to ask me at any time -- they might actually provide valuable input into the strategies that we employ. I'm available on here or at tyler at bea dot com.
Hi, Tyler. I went to a presentation you gave on WLS 5.1 in NYC back in April. Great stuff! As a matter of fact I am still waiting for your EJB book to be published by Sams. Are you too busy to write it now?
Now I have read the Release Notes of WLS 6.0 Beta and got to know the multitude of changes made from WLS 5.1. Many of the familiar directories/files/scripts/utilities are now gone, even the WebLogic Console and the EJB Deploytool, and the weblogic.class.path! Now I have a question about how the new version will impact the WLS Developer Certificate. I have scheduled to take the current exam next month. Now with all these changes in WLS 6.0, I am concerned that the certification will become obsolete right away. Should I wait for the new exam? What's your thoughts?
Your concern is a valid one. With all of the changes that have been made to WLS 6.0, the existing test essentially become "broken". I am not intimately familiar with the changes to the Certified Professional program that are going to be made at this time. As such, I cannot guess as to the timeline that the exam will be updated. I have put in a request to the individual that runs BEA's certification programs. Once I get a response, I'll make sure to post it here as well.
Here is the response from the person who runs the certification program at BEA:
Your concern is valid. All certification are tied to a version of the
product and this is common in the industry. If you were to certify in
October your certification would be somewhat short lived depending on how
you looked at it. On one hand to pass the certification you had to
demonstrate a level of competency with WebLogic Server that was equal to a
skilled developer with 3-6 months of experience. Obviously that means
something to BEA and the customers/employers who would use your services.
BEA revises WebLogic on a 6 month cycle and it would be difficult for us to
mandate that you retest every time we rev the product. What we are
currently proposing to the people who run our partner programs is that BEA
Certified professionals retest once a year. To simplify things we are
proposing that testing be available at low cost at the BEA user conference
Say you're working on a large team (eight developers) and everyone runs thier own private copy of WebLogic and we want to keep the configurations identical.
Is there an easy way to export your server's configuration so that it can be shared with the other team members?
This is exactly what we do today using WebLogic 5.1 and the weblogic.properties file. For 6.0 its not clear if the .xml configuration files can be shared and, if so, which ones.
Ok... Great question.
This product is radically different. The weblogic.properties file is deprecated because the product is migrating towards using a persistent configuration store. By default, it will be configured to use a config.xml file, but it will be abstracted so that you can easily port your configuration to a database or an LDAP server. Even though you will be able to configure the config.xml file, it will be highly recommended that you do not do so and the DTD for that format will not be published. All configuration will be capable through the web based interface or through command line utilities, notably weblogic.Admin.
Now, what gets interesting is how the configuration is propagated. WLS 6.0 will now use a domain model. A domain is a configuration area that inherits a security model and has a unique naming space. Also, within a domain, transactions will be non-interposed and you will have load balancing and failover. It will be possible to have one or more clusters within a domain, but each cluster will have to be homogeneous in the services that it offers. Initially, there will not be inter-domain traffic between multiple domains, but that type of functionality will occur in future versions. Anyone familiar with Tuxedo this must sound awfully familiar!
Now, within a domain, there are two types of servers: Administrative and Managed. There can only be one administrative server per domain. The administrative server reads the config.xml or other persistent store to get ITS configuration AND the configuration of all of the MACHINES, SERVERS, GROUPS, and APPLICATIONS for the ENTIRE domain. When a managed server boots, it connects to the admin server and downloads it's configuration -- it NEVER touches the config.xml file or any other administrative feature.
This is awesome for group development because you can define multiple server configurations in the single config.xml file. All of the developers will be able to connect and define the servers that they want to use. When you boot a server on your machine, it connects to the central admin server and tells it which configuration that it wants. Of course, you can do all of this development locally as well.
Obviously, there is a lot more to this, but you get the gist. This is definitely a significant improvement over previous versions.
Thanks for the info you provided.
Now in 6.0, using an Administrative server don't I get a "single point of failure" ?
What happen when the Administrative server crashes down?
thanks in advance.
This configuration strategy sounds awfully like WebSphere today. A WebSphere domain stores its configuration in a database. A WebSphere domain can have several models (a BEA 6.0 cluster) and the model can be replicated on to several VMs on a single box or multiple boxes. Model/clones support fail-over/load balancing.
Can you point out how the direction you've outlined compares with WebSpheres configuration model today (pros/cons/differences)? IBM have received a lot of criticism wuth regard to this type of approach due to the extra complexity it brings with it. Some of this in IBMs case was due to stability issues with the supporting tooling but people seem to like text files rather than a database for the configuration information despite the disadvantages.
Also, when will WebLogic support true clustered JMS? It seems from the docs that clustered JMS means several queue managers in a single cluster but there doesn't appear to be any load balancing across these queue managers or auto fail-over between them also. Do you know when BEA will add this functionality? I'm currently building e-trading systems and when using an EJB server as a messaging hub these features would be very valuable. I'm trying to compare WebSphere + MQ/JMS and WL 6.0 and WL JMS for future projects.
Thanks in advance for any feedback.
About the configuration/complexity issue: by default, a server serves as its own admin server and is completely standalone. In that scenario, config.xml serves the same role weblogic.properties used to server, and there is no added complexity. Only if you want to use centralized domain management and administration do you need to worry about admin vs. managed servers and there we hope the distinction will make it much easier to manage a large domain.
Also note that the configuration file uses XML, not a database format. In the future we want to give customers with very large domains the option to use LDAP or database if the wish to do so, but for the simple case (developer/small application) we want to keep things simple.
In the WebLogic 6.0 management model, the configuration of your entire domain is centralized in config.xml. This makes it much easier to see what you have configured and it eliminates the need for a shared file system. This makes administration much easier, especially across heterogenous OSes.
The Admin Server is used at boot time, so that all servers can access the shared domain configuration (including J2EE archive files, security info, etc), but users can take the admin Server down without adversely effecting all the managed servers. The admin server is needed to manage the domain (change configuration/monitor/etc) so you'll want to bring it back up as soon as possible. It is not, however, a single point of failure.
BEA Systems - WebLogic Management Lead
Thanks, Benjamin... Definitely well put.
In lieu of the WebSphere implementation, I can't make any direct correlation -- my experience with WebSphere is definitely much more development related and I don't want to make any guesses as to how WLS' domain model differs from WebSpheres (yet :).
Thanks for the response. Can you say anything about my JMS questions?
Based on BEA's press release, which states: "Building on its position as the
market's leading J2EE application server (by a 2-to-1 margin over its nearest
competitor) and its consistent track record of being
first-to-market with many J2EE innovations, BEA was the first independent vendor
to announce Java 2 Enterprise Edition (J2EE) certification with BEA WebLogic in
August 2000. J2EE certification for BEA WebLogic Server validates its rigorous
adherence to the J2EE specifications and further demonstrates the market
leadership of BEA WebLogic as the de facto standard platform for over 1,000
systems integrators, independent software vendors (ISVs) and application service
providers (ASPs). ", I would like to ask BEA:
"When will you actually be shipping the J2EE certified version?"