Discussions

News: Q&A: Mark Carges on Ajax, portals, Web services, JBI

  1. In a three-part Q&A, BEA Systems chief technology officer Mark Carges looks at how Ajax and SOA will affect portal development and what's lacking in JBI and BPEL. He previews Web services tools BEA intends to add in the future, why Web services need more runtime muscle and where BEA thinks it can fit in the open source world.

    On that latter point, he thinks corporate stability will mean a lot to open source development:
    "The customer doesn't know what the future is of these frameworks. The people who created them, what if three years from now they move onto something else? Look at BEA with Tuxedo. Tuxedo is 21 to, 22 years old now. BEA is still putting out new versions and supporting old versions. Just like IBM and CICS, they know we'll be there for a long time. ... There's a whole spectrum between that and what happens if interest wanes. That's happened with a number of open source projects. It's happening right now with Struts and JSF. People are moving to new things. Well, what if you put all these Struts-based apps into production, what happens? That's starting to catch up with people and that's where the blended model is important because you can see what corporations are betting on and who's standing behind it.
    The full interview can be found at
    Part 1 - Ajax and portals
    Part 2 - BPEL, JBI, SOA
    Part 3 - Open source and runtime SOA

    Threaded Messages (19)

  2. This is an interesting model Mark describes here. First customers use OS products because these products are new, exciting and free. Then big companies step in and add their own features on top of OS products. Big guys provide customer support for their own add-ons as well as for original OS product. As developers of OS product switch to developing something else, the commercial vendors become the only source of support for systems, built with OS framework. Seems like a nice ecosystem at first glance.

    But the problem with this approach is that commercial vendors usually cannot commit their patches and changes into main OS trunk themselves, so they create their own versions of OS products. We can see how this happens to Linux. A commercial vendor cannot provide support for all flavors of a particular OS product.

    So, if a customer purchased an add-on for OS system from a commercial vendor, then this customer can rely on vendor's support for this add-on and maybe for the whole OS product. But what if the customer built the system based on original OS framework, and the creators of this framework abandoned it? Who will provide the support? Of course, the source code is always available. But finding bugs in the framework's code and extending it could require more expertise than building an application on top of it. So, the customer would have either to hire more qualified developers, or to find a consulting company which could implement changes to framework's core for them. Now free OS product becomes expensive.
  3. So, the customer would have either to hire more qualified developers, or to find a consulting company which could implement changes to framework's core for them. Now free OS product becomes expensive.
    Since when freedom was supposed to be inexpensive? :) Throughout the history people fight for freedom and pay dire price.
  4. On BPEL[ Go to top ]

    It is the second time [1] in the last couple of weeks that I hear a BEA exec get very defensive about BPEL. In a nutshell: "Customers, be afraid of the migration pain from BPEL 1.1 to BPEL 2.0".

    The smart question to ask Mark would have been: "will customers have a harder time evolving from BPEL 1.1 to BPEL 2.0 or from your "dead ended" JPD to BPEL 2.0?".

    This type of FUD is surprising coming from the company which helped push the limit of Java by delivering an application server when servlet, JSP and EJB were at version 0.x - would BEA/WebLogic be where they are if they had not aggressively driven J2EE?

    The truth is that although there are improvements and bug fixes from BPEL 1.1 to BPEL 2.0, there are no major conceptual changes/incompabilities and therefore the evolution will be rather straight forward.

    If you are sceptical, take a look at the specs. They are available on the OASIS web site.

    Be ready for BEA to switch hat again when/if they get a decent BPEL implementation in AquaLogic (we all know that import/export does not cut it).

    -Edwin
    http://otn.oracle.com/bpel

    [1] http://blogs.zdnet.com/service-oriented/?p=427
  5. On BPEL[ Go to top ]

    Edwin,
    Mark is not being defensive at all, just stating the reality on where BPEL is today and how BEA is providing support for customers who need to do process based applications now. BEA supports BPEL 1.1 with our integration products as customers are fully able to import/export BPEL with WebLogic Integration. This capability in itself proves that we are able to provide an upgrade path from our current native XML Process definitions (JPD - Process Definitions for Java) to BPEL today as well as to BPEL 2.0 when it is finalized in the future.

    This is just the facts that customers need to be aware of as they make implementation choices today and not at all FUD. In addition, BEA is a very active member in the OASIS BPEL effort so we are well qualified to speak to the differences in BPEL 1.1. and 2.0. So, the question is really if you should be making statements such as your own that are factually not corrent about dead ending and could be considered FUD :)

    If people want to read more about BEA's involvement in BPEL and Java process standards they should just go to our website - http://dev2dev.bea.com/webservices/bpel/


    Cheers,
    Shane
    BEA Systems, Inc.
  6. Is BEA Still Peddling BPELJ?[ Go to top ]

    tight coupling personified
  7. Is BEA Still Peddling BPELJ?[ Go to top ]

    How are you defining "tight coupling" in this scenario? From your terse comment and use of the word "peddling", I assume you're implying that this is a negative.

    There are definitely use cases where process integration can and should be 100% configurable. BPEL 2.0 should allow administrators to managing these loosely-coupled integrations.

    However, the majority of process integration projects today are not just configuring existing services, but instead developing new services and using BPM as a means to gain more insight into their applications. In these cases, using only BPEL/XPath can create a steep learning curve and very unproductive development process.

    Both BEA and IBM recognized this need as we submitted the initial BPEL spec. to OASIS, resulting in the joint BPELJ specification and the creation of JSR-207 to create standard Java extensions to BPEL. Even Oracle's Collaxa engine has a pre-JSR207 way to integrate with J2EE components without forcing users to wrap everything in Web Services. Whether the eventual standard is called BPELJ or something else, I think we'll eventually see something in this space, if only to improve process performance and developer productivity.

    BPEL is all about maximizing portability between App Servers. While BPELJ may create problems porting between WebLogic and .Net, it should improve portability between WebLogic and WebSphere, for example.

    Cheers

    Monte Kluemper
    BEA Systems
    Views are my own, not my employer's!
  8. I used the term "dead ended" because:
    1) I actually think that JPD has great weaknesses: allowing developers to mix process orchestration logic and fine grain Java logic, coarse grain Java object and fine grain Java objects - resulting in code that becomes very quickly very difficult to maintain and adapt over time.
    2) That customers will have very hard time migrating JPD to any version of BPEL (see your own export document http://e-docs.bea.com/wli/docs81/bpel/export.html#1059105 as evidence of this being more of a re-write then an export).

    Another evidence of this is the lack of traction of the industry with regard to JSR-207!

    You are correct that Collaxa designed something called ScenarioBean (very early on back in Nov 2001) which combined Java and pi-calculus and allowed developers to script long-running multi-step business process using Java. The difference is that we realized very quickly that the mixing of process logic and Java logic was resulting in very difficult to manage spaghetti code and decided in 2002 to switch gears and go down the path of WSIF as the cleaner approach to bind BPEL and XQuery to services (Java Service, SOAP services, JCA services, etc.). That approach has since then be validated by IBM (who was the creator of WSIF) and Sun/JBI which is standardizing the concept of WSDL messaging and binding components.

    So if you step out and look at the path the industry is going, you might be able to see why JPD is more a dead end than a long term investment from a customer perspective and why import/export, while an interesting marketing tool, does not cut it when you get down to reality.

    -Edwin
  9. I used the term "dead ended" because: 1) I actually think that JPD has great weaknesses: allowing developers to mix process orchestration logic and fine grain Java logic, coarse grain Java object and fine grain Java objects - resulting in code that becomes very quickly very difficult to maintain and adapt over time.

    I've never seen a JPD that involved anything but course grained Java objects. Traditional BPM tools are notoriously useless. Providing an ability to round-trip between a graphical representation and Java view is a strength. But given your product's design, this will have to be an "agree to disagree" thing.
     2) That customers will have very hard time migrating JPD to any version of BPEL (see your own export document as evidence of this being more of a re-write then an export).

    And how portable is BPEL4WS 1.1 between vendors? Given that BPEL4WS is not a standard, and has several hundred OASIS-filed holes in it that are open to vendor interpretation, it's likely also a re-write.

    And let's not get started on the changes in WS-BPEL 2.0, which you say are minor, but to me look pretty major.
    Another evidence of this is the lack of traction of the industry with regard to JSR-207.

    Win some, lose some.
    So if you step out and look at the path the industry is going, you might be able to see why JPD is more a dead end than a long term investment from a customer perspective and why import/export, while an interesting marketing tool, does not cut it when you get down to reality.

    WS-BPEL 2.0 might be a suitable long term investment. BPEL4WS 1.1, being a draft, certainly isn't. Building something with BPEL4WS 1.1 is about as proprietary as building it with JPD, in my opinion. And my clients seem to agree with me (I've already defeated your product once in a major account proof-of-concept, in half the time and a fraction of the headcount. And I'll be happy to do it again! <grin>)

    Stu Charlton
    BEA Consulting (my opinions are my own)
  10. Challenge[ Go to top ]

    Stu,

    You seem to be a smart guy. Can you please come up with a couple of orchestration use cases that you think we can not implement in a portable way across Oracle BPEL PM and IBM WBI? It would be interesting to get a couple more that you think would require rewrite when moving from BPEL 1.1 to BPEL 2.0.

    > And my clients seem to agree with me (I've already
    > defeated your product once in a major account proof-of-
    > concept, in half the time and a fraction of the
    > headcount. And I'll be happy to do it again! <grin>
    It is difficult to win the all! :-)

    Edwin
  11. bpelx[ Go to top ]

    Hi Edwin -

    I would assume that moment I use bpelx, I break portability.

    I was following a thread on Oracle Forums that talks about the need to use bpelx - http://forums.oracle.com/forums/message.jspa?messageID=1054796

    I could see the need to use java (and hence bpelx) to connect to any system, generally, for performance reasons or if I don't have bindings available with WSIF (some arcane system).
  12. re: bpelx[ Go to top ]

    There is no use case that you can implement with bpelx:exec and not implement with WSIF binding to a Java Object. If you actually go through our docs and technotes, you will see that we try to heavily recommend our users to go down the path of WSIF for the reasons discribed in one of my earlier post.

    If you actually drill down a little deeper, you will see that the only other major conceptual extension we offer to bpel 1.1 and that is widely used by our customers is a bpelx:flowN which allows dynamic branching. BPEL 2.0 addresses this shortcoming with the additional of a "parallel for each" activity. You can take a look at the 2 syntax and see how difficult it will be for us to migrate that syntax forward :-)

    -Edwin
  13. Edwin,
    If you are going to respond to my post at least get my name right if you want to call me out in the title.

    It is unfortunate you want to continue down the path you are going as you are just validating Mark's statements. Obviously any upgrade from one implementation to another means that there are differences that have to be addressed when the customer upgrades their application. Thank you for making the exact point that exists from BPEL 1.1 to 2.0 just like it does from JPD to BPEL 2.0 or from the earlier Collaxa implementation to the current one. It will be great to see how good the Oracle upgrade tools are to move customers from BPEL 1.1 to 2.0 in the future.

    Customers want people to provide real business value and offer investment protection. BPEL is an emerging standard that will fill this role for some areas of business process management (additional extensions beyond BPEL 2.0 will be required). BEA is behind BPEL, active on the OASIS group, and on record that we plan to implement BPEL 2.0 in the future once it is complete. It is just that simple.

    So, either bring up a new topic for discussion or stop the grandstanding and posturing on BPEL as it is not productive for the industry.

    Shane
  14. Sorry for the typo.[ Go to top ]

    Sorry for the typo Shane. It was late when I posted the message.

    I am not sure I understand your last sentence but I think that I made my case and hopefully provided enough facts and references for people to follow up and make their own mind in how difficult or easy the evolution from BPEL 1.1 to BPEL 2.0 will be.

    Let's follow on this discussion when BPEL 2.0 ships and BEA offers native BPEL support.

    Between now and then, it would be nice if when BEA attacks the lack of maturity or portability of BPEL, that you use specific examples...

    Best,

    -Edwin
  15. Edwin,

    It is not attacking to simply discuss that things are changing from one version of a specification to another. This is the "good" part of the open community process in getting to a better specification that meets the broader needs of customers and the industry.

    Since there are around 200 issues logged in BPEL 2.0 that are being addressed at different levels there is a lot of education required for people to understand the differences in versions and plan accordingly. Customers I speak with appreciate this level of candor and find it beneficial. It would be great to see discussions on TSS to the beneifts and issues with some of the changes in the new 2.0 specification things like assignment, compensation handlers, event handlers, links, and fault handling instead of the "we like BPEL more then you do stuff".

    Cheers,
    Shane
  16. bla bla bla[ Go to top ]

    Shane,

    I am asking for specific examples and you are just generating bla bla bla.

    HTML evolved from version to version yet the evolution for users has not been that disruptive.

    Although BPEL is evolving and a lot of gray areas of the spec are being addressed, there are very little CONCEPTUAL changes from 1.0 to 1.1 to the future 2.0 (specifically assignment, compensation handlers, event handlers links and fault handlers all already exist in BPEL 1.1!!!) [Why? because the people from IBM and Microsoft who wrote the initial spec had spent many many years on XLANG, FDML and WSFL and understand this space very very well - this was not a week end project] As a result, my point is that people that learn and use BPEL today will have little effort moving to the future (The same way that people that used HTML 3.0 where better of moving forward than people using some proprietary dead ended opaque format - even if that format claimed for marketing reasons that it offered very partial import export to HTML).

    It is interesting that you can generate a lot of noise and bla bla, even pretend to be angry but have not yet come up with a specific example!

    Anyway. As I said I think that I made my case and really recommend people to read the BPEL 1.1 spec and the BPEL 2.0 spec and see if how many conceptual changes there are.

    Over and out!

    Edwin
  17. Not just - bla bla bla[ Go to top ]

    Edwin,
    I thought I just listed several areas in my last thread? No anger here at all, just trying to cut through to the point.

    BTW - most customers do not like terms such as "not that disruptive" when referring to futures, but I agree that this is a reality in evolving standards and specifications. In fact, this the major point we are discussing here....

    And it seems we agree on one item, which is that people should read the 1.1 and 2.0 BPEL specs so that they understand where things are today and how they are evolving.

    Cheers,
    Shane
  18. On OS/Free products[ Go to top ]

    "Now Free OS product becomes expensive"

    That is exactly the reason why the Free/OSS sites will tell you that open-source implies free as in beer and speech and not $0.

    You are free to download the products (or copy from someone who has it already) and do what you want with it. That is the freedom. Also, if you pay for an OS product, its yours and there are no strings attached a la EULA's of the proprietory/closed-source vendors.
  19. On OS/Free products[ Go to top ]

    I second Kanwar's notion that free/OS does not imply $0.

    Some of the best OS technology requires a significant investment in resources to develop expertise and to implement/integrate (especially if adopted early in the technology's lifecycle).

    The question in my mind is whether or not a commercial vendor's adoption/absorbtion of an OS solution reduces the amount of time required to get up to speed using it. Does the vendor provide sufficient useful documentation, stability, and sufficient backwards compatibility to offset the cost of paying for it? I believe the investment will be essentially the same, but theoretically a commercial vendor's offering requires more capital investment while a "free" offering typically requires more time.

    The jury is still out on whether or not this trend of commercial vendors embracing OS technology will actually result in that reduction in time to implementation, and some of the OS technologies have done such an excellent job in providing docs/stability/backwards compatibility that the bar is mighty high for the commercial vendors IMHO.
  20. BPEL[ Go to top ]

    I've high hopes for BPEL and JBI.

    Visual programing (especially UML activity diagram) is getting a boost from BPEL. This begs for MDA, as Andro proves. Visual BPEL is approaching the formal rigor of ProGraph.

    In some fundamental ways BPEL has better facilities(<pick>,<flow>) for concurrency than Java. I'm thinking actor-based language, ala MIT's Act languages.

    BPEL's XML grammar (and Java's lack of) positions it better than Java for metaprograming and extensibility, per XML and the Art of Code Maintenance

    I'm curious if BPEL could be unofficially applied to in-process or other lightweight integration -- for metaprograming or other scripting of non-WSDL integration. Sorta like Apache's WSIF.