Interview with Mark Hapner on JBI, Web services, SOA

Discussions

News: Interview with Mark Hapner on JBI, Web services, SOA

  1. In this interview, Mark Hapner, Web services strategist at Sun, discusses everything from Web services and application integration, to the role of Ajax in Web services development. He reviews the Java Business Integration standard, stresses the importance of an open ESB architecture for the Java platform and provides his vision for a global computing model.

    Read:

    Part 1 - Hapner on SOA and the global computing model
    Part 2 - Hapner on Java Business Integration
    Part 3 - Hapner on Ajax, integration and SOA security

    Threaded Messages (4)

  2. Path towards composite applications[ Go to top ]

    Hapner touches on many things, but one issue struck me:

    The interview starts out with Hapner's view on the biggest misconceptions around Web Services and SOA, in a nuthell: We're fairly successfull in converging on basic concepts such as messaging. However, a lot more is needed to get to the real 'composite application' level.
    I couldn't agree more. His later statements on the role of JBI only seem to reenforce his earlier point: We're still working on the basics.

    One of the hard problems I see ahead is the diversity of both the width (completeness) and depth (granularity) with which business applications expose their functionality wither through a legacy API's or through a set of webservices.

    An example: A particular (legacy) billing application might require you to mimic user interface like behavior, working through a predefined flow of screens. Each such a 'screen' might be exposed as a webservice.
    Composing a business application that includes services offered by this billing system should become easy.
    So, I ask myself: What measures are we taking to ensure that as soon as this particular application is 'Web Services' enabled the composition becomes easy?
    Surely, we would need the billing application to offer some kind of call ordering constraints to a tool that would allow us to 'compose' based on its services.

    I'm very curious as to the thinking on this issue. Is there any work on including applications exposed (simplified) execution models into the whole 'webservices' phenomenon ?
  3. should it be xml?[ Go to top ]

    Interesting reading...

    Though as i am new to this topic i would ask a question about message format in WS-*, JBI, SOA...

    Should it be XML?

    As far as i know
    WSDL has a protocol binding so protocol neutral (there is hessian WS, not sure about binding though)

    BPEL - WSDL driven, no XML?

    WS-Secitry - i think has XML under it

    WS-BA WS-CAF BTP - i think have XML under it

    JBI relies on WSDL so can have no XML but what is normalized message then?

    I am not against XML in messages but i do now want always to be able to read a message....
  4. should it be xml?[ Go to top ]

    Interesting reading...

    Though as i am new to this topic i would ask a question about message format in WS-*, JBI, SOA...

    Should it be XML?

    As far as i know
    WSDL has a protocol binding so protocol neutral (there is hessian WS, not sure about binding though)

    BPEL - WSDL driven, no XML?

    WS-Secitry - i think has XML under it

    WS-BA WS-CAF BTP - i think have XML under it

    JBI relies on WSDL so can have no XML but what is normalized message then?

    I am not against XML in messages but i do now want always be able to read a message....
  5. should it be xml?[ Go to top ]

    Interesting reading...Though as i am new to this topic i would ask a question about message format in WS-*, JBI, SOA...Should it be XML?As far as i knowWSDL has a protocol binding so protocol neutral (there is hessian WS, not sure about binding though)BPEL - WSDL driven, no XML?WS-Secitry - i think has XML under itWS-BA WS-CAF BTP - i think have XML under itJBI relies on WSDL so can have no XML but what is normalized message then?I am not against XML in messages but i do now want always be able to read a message....

    A JBI Binding Component can talk any protocol and use any wire format it wishes. So it could talk DCOM or CORBA or ASN.1 or CICS any old binary stuff you want.

    The idea is that inside the JBI service bus messages are normalized and a normalized message can have its body logically represented as a chunk of XML to make it easy to route stuff in a polymorphic way without having to grok every singe binary encoding mechanism available - yet the physical on-the-wire can be whatever the Binding Component wants.

    James
    LogicBlaze