BEA held an executive panel meeting with the press to talk about the upcoming Weblogic 8.1. The questions they were addressing were: How can we make J2EE easier? How can we scale out J2EE? and How can we integrate J2EE? Execs from other companies give their 2 cents.
- Posted by: Dion Almaer
- Posted on: June 24 2003 10:53 EDT
Read BEA's Progress Report
- BEA WebLogic 8.1 Progress Report by Parag Gandhe on June 24 2003 11:41 EDT
- proprietary? by not myName on June 26 2003 09:09 EDT
- ??? by Peter Parker on June 26 2003 11:25 EDT
- .JWS FILES...PROPRIETARY? by Peter Parker on June 26 2003 11:39 EDT
- BEA WebLogic 8.1 Progress Report by Cameron Purdy on June 28 2003 18:44 EDT
Is there any document about BEA's plans of future development of its 8.1 Integration Server? WebLogic 6.1 and 7.1 Integration Servers are totally different from the 8.1 Integration Server. It looks like migration will be total new re-write of WLI 7.1 code into WLI 8.1 code. Is there any plan to build a tool that helps customers of 7.1 Integration Server to migrate to 8.1 Integration?
There is a tool in Workshop 8.1 beta that migrates workflows from WLI 7.0. I don't know how to migrate other things (AI views and so on), but I haven't really used them in 7.0.
I've seen the workshop product. It has some very cool features that seem like they could shorten development time.
I have been unable to get an answer from them on how portable these extensions are. It looks like page flows and the various controls get generated to classes when the EAR is created. I'm assuming that the EAR could be deployed to other app servers, but haven't yet tested.
My problem is that it doesn't seem to generate .java files for these things. That means that if your company decides to standardize on another app server a couple of years down the road, you would have to remove all of this stuff and come up with another solution so you would have something maintainable without BEA.
Is this correct, or are completely portable .java classes generated?
I think they built the work flow process on top of struts.
I would like to comment on the difference between page flows and Java processes (workflows). In 8.1, they use a different architecture. Page flows are based upon Struts 1.1. However, Java processes are deployed as Web services that may or may not be conversational. So, the two systems use very different architectures.
Struts is geared toward presentation logic and user management. Conversational Web services are a natural fit for loose-coupling, asynchronous communication and coarse-grained messaging, which are all elements essential to long-running Java processes.
I was curious if anyone had any thoughts on whether or not .JWS files created in WebLogic Workshop were proprietary?
I know you have access to the Java code but doesn't this seem like a ploy for long term vender lock in?
BEA Workshop 8.1 applications are J2EE 1.3 applications. They are defined in Java classes with JavaDoc meta tags. All of the file formats are submitted into the JCP process, so when other vendors support these type of container extensions, the applications will be directly portable.
In the meantime, here is a very good article on dev2dev that explains how the JWS container operates (explaining the bridge between meta data and J2EE). It's fairly technical and lengthy, but is a solid explanation.
Additionally, I know there are a number of concerns about portability of the applications. Everything is J2EE 1.3, but the meta data has correlations to vendor-specific deployment descriptor extensions. If the same extensions are supported in different app servers, then the application is portable with the same features. If not, then there might be further work that has to be done. BEA is VERY committed to making sure all of these file formats get pushed through the JCP and feedback incorporated in. We expect other vendors to support these standards (starting with JWS) in the future.
Finally, when using our Web application technology, called page flow, that code IS portable to other applications. Page flow is an abstraction layer on top of Struts, so the Web application generated is a pure Struts app. You can take that portion and port it easily. However, if you leverage Integration or Portal capabilities, those are vendor-specific extensions that may or may not be supported on other platforms.
The approach with .jws is consistent with several activities in the JCP.
Like JSR 175 und what is targeted for EJB 3.0.
EJBGen and XDoclet follow this for approach quite a while with significant success.
There are already non-BEA tools available like Together that model JWS.
Similiar, it is possible for any vendor to follow this concept for the runtime framework.
Actually, BEA filed JWS as JSP 181 to the JCP and has been 100% accepted,
including IBM, Sun, Borland, Apple, Macromedia, ...
To me, this does not look like vendor lock-in.
Cedric announced the AOP extensions to WebLogic 8.1 at the TSS Symposium earlier today ... see TSS Symposium, Live! J2EE by Cedric & Rob.
Coherence: Easily share live data across a cluster!