Discussions

News: BEA to integrate and re-position Weblogic

  1. BEA to integrate and re-position Weblogic (23 messages)

    BEA will seek to reposition its WebLogic line as a 'Swiss Army knife' when it launches the next version of Weblogic in the first half of 2003. The key goals of the new version (code-named Gibraltar) are to combine app development with app integration and to bind together BEA's different products, including its portal, integration broker, Workshop tool and Liquid Data data access software.

    BEA rethinks its WebLogic software.

    ***Added December 16:
    Read BEA thickens the supersuite plot.

    Threaded Messages (23)

  2. WebLogic Integration (WLI) today has a confusing positioning problem. WebLogic Server for instance ships with some great tools for easing up development, but I cannot understand why BEA places a JCA development tool within WLI instead of the server in the current version. Bringing it all together under the Workshop tool is a great move! Business process management and "regular" programming should not be separated from each other in the way it's done in the current version. After all, we're all out there trying to solve the same problems, be it the good old hacking way or drawing a process.... ;)
  3. It's interesting to notice BEA making a formal announcement on implementing BPEL4WS but maybe not so surprising since IBM and Microsoft, the main authors of the BPEL specs, have announced their BPEL-related product plans already. How BPEL would fit into a proprietary framework like Workshop is a mystery to me.

    The move to put together business logic programming and process logic programming makes total sense as J2EE apps need to integrate with more moving pieces like Web services, JMS and other asynchronous components. The challenge would be to make BPEL (which is expressed in XML) developer-friendly like:
    BPEL Scenario samples.

    Cheers.

    Jill.
  4. BEA to integrate and re-position Weblogic[ Go to top ]

    <jill>
    How BPEL would fit into a proprietary framework like Workshop is a mystery to me.
    </jill>

    Workshop creates interfaces based on Soap standards, executes on and leverages J2EE standard components, and is developed using a simple class (.jws file) which is part of a new designtime/runtime framework that is in the pipeline to become a standard. Benefits of this architecture include, XQuery mapping, asynchrony and conversations without coding.

    BPEL4WS will be a natural way to orchestrate these workshop webservices and is very similar to what can be done with WLI's Busineess Process Manager today with its pre-BPEL4WS approach.

    Matt
  5. BEA to integrate and re-position Weblogic[ Go to top ]

    <matt>
    BPEL4WS will be a natural way to orchestrate these workshop webservices and is very similar to what can be done with WLI's Busineess Process Manager today with its pre-BPEL4WS approach.
    </matt>

    That's a good point. I've heard a rumour that the BPEL Scenario can orchestrate Workshop Web services and that Collaxa, one of BEA's partners, is now working on a BPEL control for Workshop. I've also found this sample that is not published on their site (I hope they won't remove it by the time you get to it):

    Hidden BPEL Scenario sample

    Cheers.

    Jill.
  6. BEA to integrate and re-position Weblogic[ Go to top ]

    Velare Technologies announced yesterday a framework to implement asynchronous processing of Web Services in Java.
    Apparently, you can build complete business logic flow in pure Java, as you mentioned.


    You can find their announcement right here:
    http://www.velare.com/releases/2121201.htm

    Ciao,

    Mark
  7. The ADK in WLI is customized to fit the Application Integration module to ease the task of configuring new Application View Services/Events. The ADK adds a couple of frameworks on top of the J2EE Connector to enable runtime service configuration tasks and EIS events.

    The ADK provides the things J2EE Connectors should have (and I hope will have). I think the ADK will merge into future releases of the J2EE Connector Spec.
  8. If this happens, we will be moving away from Weblogic, and on to JBoss ASAP. Two (three?) words: vendor lock-in.

    Steve
  9. "Two (three?) words: vendor lock-in"

    I hope they don't do something as lame as bundle their products so you can't buy them separately. If they do that WebLogic server it's the end of WebLogic - period. I hope they get it before it's too late.
  10. BEA to integrate and re-position Weblogic[ Go to top ]

    Surely. I think it will be better if there are independant Server vendor and IDE vendor. I will have more choice. Not Server lock-in
  11. I completely agree. Weblogic is self destructing, turning from nice open container into proprietary monster.
    Anybody who worked with WLI will not use it on there next project. Instead of clear separation of different component, they are piling up everything together.
    Don't you wish you were running on JBoss already?

    David Levin
  12. BEA to integrate and re-position Weblogic[ Go to top ]

    Don't you wish you were running on JBoss already?


    WLS is far superior to jBoss.
  13. BEA to integrate and re-position Weblogic[ Go to top ]

    Yeah, right…
    During first half a hour of start up it is produces
    500,000 objects.
    JBoss is modular, open server with clean configuration.
    WLS was like that 2 years ago. Now it is convoluted mess.
    David.
  14. Generally not a bad idea. However I doubt that BEA is able to go all the way that soon. Basically what I need as a developer is a tool that I can use to

    - Write code, not just webservices, but EJBs, JSPs, Java Classes (why use Workshop for coding but some stuff another Tool, say JBuilder for coding other stuff)
    - Configure metadata, as needed for WebLogic Integration, WebLogic Portal and the like
    - Create a single code tree that I can drop into source control. Please no more need to reconfigure stuff with a web interface as is currently the case with Portal

    Given that the current state is rather far away from this, I am anxious to see what the next step is.

    Personally I think that the business process management part is not a main concern. Let's get real: What you can do with these tools is basically define flow control. The heart and soul of application integration is not in the flow but in the adaptor capabilities.

    BEAs should come up with adaptor implementions that I can just plug into oracle/db2/SAP/filesystems and should not rely fully on messaging.
  15. If I have Gucci or Versace shades/glasses, do they give better sun protection than some other cheaper shades? Do I look cool, or funny, and less money.
    Open Standards are cool, such as Struts, that can run on the reference implementation, Tomcat. (Other studies showed that Apache and Tomcat have most market share, I think same is true of Struts, that is has more market share than all others combined). Manin reason for open standards is that they are more relibale, less bugs, and better support.
    OK, so it is cheaper, but that does not make it worse.

    Heres a news flash: A GUI tool, such as Vi or .... maybe Emacs. It can write:

    JSP
    SOAP
    JDO
    Struts
    C#

    I mean, you can go to MS Word, and save as text. A tool makes no difference, just do O.O.
    Not having vendor lock in: Priceless.
  16. <quote>
    Open Standards are cool, such as Struts, that can run on the reference implementation, Tomcat.
    </quote>

    They might be cool (btw. Struts is not a standard afaik), but there are different drawbacks related with (some of) them such as

    - much longer development cycles (vendor lock in sucks, but hey, running late scuks even more).

    - reference implementations can be awfully slow (tomcat 4.0.6) or awfully broken (tomcat 4.1) (just my experience)

    - less bugs? Yeah, well, have a look at the bugzilla bug tracker for any open source tool. Guess what, lots of bugs as well.

    - Doing everything in vi (or edlin for that matter). Tempting, I'd love to. However there is that big bad company out there, called Microsoft, that just keeps producing really good development tools (and a lot of vendor lock in to go with it!). Wake up guys: This is the prime competition for the J2EE universe. Even Scott McNealy noticed it.

    This is not to say, BEA will provide just the tool that addresse all that, but somebody needs to try. Oh, well, and about app servers becoming a commodity: As far as I can tell, building a really reliable, manageable, resilient, recoverable J2EE environment is (a) very hard and (b) very, very much work. If I ran such an environment, not just a couple of servlet containers I would do one of two things anayway:

    (1) Buy from someone I trust
    or
    (2) Use open source (or build open source for that matter) and SECURE THE DEVELOPERS

    Regards, Karl
  17. Hmmm, ok. Maybe you'll do the honors of convincing my boss that we need an expensive app server, expensive proprietary already-written code on top of that appserver, an expensive content management system to plug into the proprietary framework on top of the expensive app server, and an expensive IDE just to be able to hot-deploy.

    Not in this economy, baby.
    Steve
  18. "BEAs should come up with adaptor implementions that I can just plug into oracle/db2/SAP/filesystems and should not rely fully on messaging. "

    The existing AppView control which is used with J2EECA adapters support both synch and asynch modes. Events, however, are always asynch.

    "Given that the current state is rather far away from this, I am anxious to see what the next step is. "
    Workshop is "rather far" from where they were this time last year and its only V1...

    Matt
  19. BEA to integrate and re-position Weblogic[ Go to top ]

    <karl>
    "Personally I think that the business process management part is not a main concern. Let's get real: What you can do with these tools is basically define flow control. The heart and soul of application integration is not in the flow but in the adaptor capabilities. "
    </karl>

    I believe this is a rather partial view of the issue discussed. Dealing with asynchronous services immediately raises the need to handle flow inside your Java application. Once you factor in the need to handle parallel execution, reliability, scalability, exception management and sometimes transactional behavior as well, you realize that flow control is a rather big issue.

    Cheers.

    Jill.
  20. BEA to integrate and re-position Weblogic[ Go to top ]

    I agree. My main concern is not flow control per se, but there are so many other apps who have been doing this for years (Notes anyone?) ... I'm just not sure why anyone should want to buy BEA's story when they are only getting into this game playing catchup. Inevitably, their solutions are going to be buggier and require more consultants than smaller/mid-size companies will want.

    I mean, if you want buggy locked-in software why not just make it easy on yourself and buy Microsoft and hire a bunch of MSCEs? :)

    Steve
  21. Does this show that the farther WebLogic moves away from spec with its valued-added applications like portaland web services (Workshop) that clients perceive less value. I will be interested to see the new price points.

    IBM is driving so many JCP specs based on opensourcing its code base that WebLogic will ultimately look like a follower as it has to adopt these defacto and and soon to be committee standards. Do you see them embracing Jetspeed as a portal platform and Eclipse as a Workshop front-end?
  22. Quote: According to BEA's Helleboid, "single and point vendors are going away. Convergence and consolidation are being accelerated by the economy, and it's in the end-users' best interests to streamline the number of vendors that they're working with, and BEA is very much in the middle of that. Our message is that application development, portal access, enterprise application integration (EAI) and business process management need to be done in integrated fashion. It needs to be simplified, and that's our message."

    I'm not really sure that end users agree that convergence and consolidation are in the user's best interests. I think it's more that BEA can make more money selling business software than development software. It was great when every .com was developing Java, but now they want a piece of the business software pie.

    Steve
  23. BEA to integrate and re-position Weblogic[ Go to top ]

    I'm not really sure that end users agree that convergence and consolidation are in the user's best interests.


    I don't think it's good at all. Some people predicted that appservers will become commodity items. It seems that it's already happening. That's why appserver vendors are desperately trying to secure their future somehow. Small ones are being purchased, large ones are purchasing others. So, BEA wants to offer more than appserver.

    The question is "Is it what end users want?". My answer is NO. Ebd users would benefit more if appservers become commodity items, them you cpuld easily change them, choose cheaper ones etc.

    I think that OSS appservers will have advantages, simply because they are OSS :)
  24. BEA to integrate and re-position Weblogic[ Go to top ]

    <argyn>
    The question is "Is it what end users want?". My answer is NO. Ebd users would benefit more if appservers become commodity items, them you cpuld easily change them, choose cheaper ones etc.
    </argyn>

    It seems that there is consolidation as well as commoditization happening in the app server market, aided by OSS, the likes of JBoss. But the more important aspect of the impending change is the shift towards implementing integration in the context of application development. IBM describes this shift pretty well here:

    "Van Overtveldt: As we look at application serves over the past 2-3 years, we see a change in how people are using them. For the first two to three years people were using app servers to build some app logic primarily to front-end and existing applications. Right now, app servers are being used to build new applications and integrate them. So, the role of the app server changed to a next generation."

    The problem is that the leading commercial app servers carry too much baggage to make that transformation in use happen quickly and much less economically for end users.

    Cheers.

    Jill.