Microsoft, IBM and BEA Deliver new Web Service Specifications

Discussions

News: Microsoft, IBM and BEA Deliver new Web Service Specifications

  1. Microsoft, IBM and BEA have delivered specifications for Business Transactions and Process Automation for Web Services. Specifically the new specs address transacted communications of Web services (WS-Coordination and WS-Transaction) and the Business Process Execution Language.

    Read the Microsoft Press Release here.


    More Info on Web Service Specs
    ==============================
    BPEL4WS: Business Process Execution Language for Web Services
        (represents the merging of WSFL and XLANG)
        http://www-106.ibm.com/developerworks/webservices/library/ws-bpel

    WS-Coordination: Describes an extensible framework for providing
        protocols that coordinate the actions of distributed applications.
        http://www-106.ibm.com/developerworks/webservices/library/ws-coor

    WS-Transaction: Describes coordination types that are used with the
        extensible coordination framework described in WS-Coordination.
        http://www-106.ibm.com/developerworks/webservices/library/ws-transpec


    Microsoft: http://msdn.microsoft.com/webservices
    IBM: http://www.ibm.com/webservices
    BEA: http://dev2dev.bea.com/techtrack/standards.jsp

    Threaded Messages (31)

  2. How much will the royalties be???


    Ha Ha
  3. A message to this trio[ Go to top ]

    The software industry seems to not want SOAP for anything but integration related problems. So Sun and IBM, please stop wasting your resources on this bound to fail technology. Use those resources instead to make Java an even better technology. As for M$, I don't care about what they do. I'll be the last person on this Planet to leave Java for their Java clone which runs only on Windows.

    Francis
  4. A message to this trio[ Go to top ]

    Web Services is not about SOAP. SOAP is just one binding for a web service. WSDL is like a languange for defining interfaces in a protocol agnostic way. This interface definition can be decorated with a particular binding such as SOAP over transport X if desired.

    I think it's unfortunate that the JSR-109 stuff is so SOAP centric and hence, the confusion between web services being about SOAP continues. JAX-RPC is too SOAP centric in my opinion and also only handles synchronous web services. I believe that asynchronous web services will be more common in the BI space and hence question the relevance of JAX-RPC in this space.

    An example of an alternative to JAX-RPC would be WSIF from IBM. IBM uses WSIF to implement our JAX-RPC implementation in WAS 5.0. IBM uses WSIF internally to talk with any web service, whether it's an EJB, a business process (asynchronous), a JMS based service, a Java snippet, a .Net component etc. Notice I haven't mentioned XML either. Web services is not about XML, XML is a possible rendering of a service invokation but by no means is it the only one. Web Services, of course, uses XML/XSD as the way to describe web services artifacts (WSDL, BPEL, etc) and this is a good thing as we only need to write a single parser for everything.

    Expect most vendors to implement a web services invocation engine which supports JAX-RPC but also features SPIs to allow different protocols to be plugged in as well as support asynchronous services and correlation services. Correlation services are needed to determine which application/component needs to be called when an asynchronous response arrives at a later point. Features such as DII and DSI are also necessary to implement web services bridges/gateways.

    So, from this perspective as an integration technology web services has a role, WSDL can be used to define services regardless of the underlying communication mechanism and WSDL gateways aka web services brokers can be used to connect app A to app B.

    Services adapters can be plugged in to these brokers to do conversion and even more complex flow oriented stuff. It's a shame that JAX-RPC has a limited role in these scenarios (except for synchronous SOAP oriented ones). Web Services brokers will become the next generation of message brokers with much more capability than message brokers offer today.

    I did an article articulating this about a year ago for this site and today I'm helping make this a reality on the IBM WAS team. Other vendors are likely working on similar things.

    So, stop concentrating on SOAP, it's just one transport. It is not what web services are about. Look at the bigger picture.

    WSDL, BPEL, service brokers etc built on Java combined with a J2EE platform makes a very good integration story. Coupled with Javas portability then it has the potential to become a compelling story for enterprises that need an integration platform. In this manner, Java is being enhanced by these activities.

    Have a great weekend,
    Billy
    (WAS enterprise team at IBM)
  5. A message to this trio[ Go to top ]


    >> JAX-RPC [...] only handles synchronous web services

    Not quite sure what you mean by this.
    Synchronous RPC is only 1 of the 3 styles supported by JAX-RPC. The other 2 are asynch 1-way and asynch request-response. Are you talking about synchronicity, or the decoupling of producer and consumer?

    Also, will JAX-RPC in fact be supported by WAS5? Its different from the info I have been given - however, from your sig, you seem closer to source.

    -Nick

  6. A message to this trio[ Go to top ]

    Decoupling of producer and consumer, direct explicit support for asynchronicity if you will.

    Billy
  7. SOAP, A message to this trio[ Go to top ]

    Billy wrote:
    >
    >Web Services is not about SOAP. SOAP is just one binding for
    >a web service. WSDL is like a languange for defining
    >interfaces in a protocol agnostic way.

    Web services is about interoperability. Without SOAP there's no wire-level interoperability.

    >I think it's unfortunate that the JSR-109 stuff is so SOAP
    >centric...

    SOAP is a universal dialect without rival, and it makes sense to require it.

    >Notice I haven't mentioned XML either. Web services is not
    >about XML...

    XML is human readable, openly parseable, tunnels effortlessly, is stateless, and readily marshals to oject-oriented languages. An interoperability effort is necessarily limited without XML.

    >So, stop concentrating on SOAP, it's just one transport.
    >It is not what web services are about. Look at the bigger
    >picture.

    There is no "bigger picture" without standardized plumbing.
  8. SOAP, A message to this trio[ Go to top ]

    Web services is about interoperability. Without SOAP there's no wire-level interoperability.

    <bn>
    Web Services is about integration. Interoperability can be achieved if everything speaks the same on the wire as you suggest or by using brokers/adapters which convert. I say, why convert if your stubs can speak directly the language of the other side.
    </bn>

    SOAP is a universal dialect without rival, and it makes sense to require it.

    <bn>
    When everything only talks SOAP fine, but while legacy systems still exist and need to be integrated, it's only a part of the equation.
    </bn>

    XML is human readable, openly parseable, tunnels effortlessly, is stateless, and readily marshals to oject-oriented languages. An interoperability effort is necessarily limited without XML.

    <bn>
    Nope, XML as an intermediate form for tooling generating adapters etc is useful but again, legacy systems and non functional requirements for integration applications may preclude the luxury or transforming to XML and then to something for the sake of XML if you see what I mean. So, again, I again with most of what you said, I'm just saying that use XML when it's of value not 'just because'.
    </bn>

    There is no "bigger picture" without standardized plumbing.

    <bn>
    If standardized plumbing was a requirement then we wouldn't be in the mess we are right now with regards to integration. Unfortunately, there are a large variety of middleware in use so any integration solution must work with them all as WSDL is the way the interfaces to these middlewares are going to be specified. What the message format is and what the wire format is are too additional issues which WSDL solves nicely and SOAP and XML are just two choices in the integration toolbox, not the only two.

    Thanks for the comments, it's great to have a lively debate on this stuff.

    Billy
    </bn>
  9. SOAP, A message to this trio[ Go to top ]

    "I say, why convert [to XML] if your stubs can speak directly the language of the other side." -- Billy

    You know "the language of the other side"???
    Web services is for large audience, which implies heterogeneity. That's why XML interchange makes sense.
  10. SOAP, A message to this trio[ Go to top ]

    Web services is for large audience, which implies heterogeneity. That's why XML interchange makes sense.

    <bn>
    It's a larger audience than that. It's also supposed to be useful in intra enterprise integration. A lot of customers have vertical applications and need to integrate them. A lot of the data that needs to be exchanged will not be in XML. Even if they could be XML, non functional requirements such as message size or CPU cycles to process (read parse) the messages may preclude it in any case. A simpler format such as name/value pairs may be more appropriate.

    Eventually, these formats will become XML but in the interim lets accept that they are not XML. We could go for a big bang approach and switch everything to XML but it's hard to sell the big bang approach to anyone. Too much risk and unknowns.

    An incremental approach is more likely and now what we have is an Island of XML that's trying to grow and expand to encompass that rest of the enterprise.

    Now WSDL allows me to model these incoming messages in WSDL parts and then map them to a binding. Initially, that binding may not be SOAP but I don't care because WSDL protects me. MY binding may map the message parts to name value pairs. But, you know what, I don't care, I just code my app to use WSDL generated stubs to talk to the IIOP system (for example). Later when the data format switches to SOAP/XML, I change my binding or transport to be SOAP and voila, thats it once I recompile my stubs. My apps don't change. The WSDL stubs are the same regardless of the wire data format and protocol. That is why WSDL is useful, not SOAP and not XML. WSDL frees you from worrying about 'mundane' matters such as low level data formats or transport protocols.
    </bn>
  11. SOAP, A message to this trio[ Go to top ]



    >>Later when the data format switches to SOAP/XML, I change
    >>my binding or transport to be SOAP and voila, thats it once
    >>I recompile my stubs.

    Do you really see this happenning much in practice?
    What would be an example?

    I would have thought that if a working non-XML binding existed, then any move to SOAP would be part of a larger change to the functionality and therefore the interface.
    I cant think of a situation where people would "upgrade protocols" - what advantage are they going to get?

    I see the primary value in WSDL in being able to generate bindings for different languages, and for different transports (http, ftp, smtp, JMS, MQ, etc etc).
    However, the common binding between all of them is XML.

    -Nick
  12. SOAP, A message to this trio[ Go to top ]

    Nick,
    XML is another binding, it's obviously got a better future than the others but it's just another choice, albeit the preferred one. WSDL gives you flexibility over both transport and data format and that's a good thing. Because we now have a component specification language which scales from tightly coupled components in an application like EJBs with none or little performance degradation using RMI/IIOP to loosely coupled BI type stuff using XML with SOAP or what ever. The stubs for both ends look the same. Thats the value of WSDL.

    Billy
  13. SOAP, A message to this trio[ Go to top ]

    Nick,
    I think another way of looking at this is that with WSDL wrapping my components, I can build middleware and plumbing which can be used in tightly coupled environments such as J2EE, loosely coupled BI type stuff or a mix of both. This wasn't really doable in a natural way pre WSDL.

    This will have the effect of improving the quality of such middleware in all areas.

    Billy
  14. SOAP, A message to this trio[ Go to top ]


    I agree 100%. WSDL is going to be very powerful for describing any interface, it has few of the restrictions (based on implementation language & remoting technology) that predecessors had.
    Just not sure about people using WSDL in existing apps where they now use IDL... (is this what you mean, or have I missed your point?)


    -Nick

  15. "The stubs for both ends look the same. Thats the value of WSDL." -- Billy

    I notice that no matter who's argued what here, we all seem to endorse WSDL. That's in stark contrast to UDDI, which most folks reckognize as pure hype.
  16. SOAP, A message to this trio[ Go to top ]

    "I cant think of a situation where people would upgrade protocols..." -- Nick

    Effortless tunneling is a reason to switch to an HTTP-based protocol such as SOAP.
  17. A message to this trio[ Go to top ]

    WSDL is like a languange for defining interfaces in

    >a protocol agnostic way. This interface definition
    >can be decorated with a particular binding such as
    >SOAP over transport X if desired.

    Well, this concept seems come from DCE RPC...no wonder.
  18. A message to this trio[ Go to top ]

    IBM and BEA are the reason Java is so successful. They are expanfding their interfaces to allow other systems to reach Java implementations.
  19. A message to this trio[ Go to top ]

    <Quote>
    IBM and BEA are the reason Java is so successful. They are expanfding their interfaces to allow other systems to reach Java implementations.
    </Quote>

    What a load of crap, IBM and BEA just played their chips right and jumped on the right train at the right time. The only people who should receive benefit are the individual practioners, not these corporate, put my stake in the ground, entities.
  20. Correction![ Go to top ]

    Replace Sun with BEA in my previous post.
    Sorry!

    Francis
  21. Will have to look into this. Would like to see how this
    competes or compliments the work already being done
    by OASIS with the Business Transaction Protocal (BTP).

    See: http://www.oasis-open.org/committees/business-transactions

    As for WS-Coorindation and BPEL4WS, unknown.

    I hate to see competing specifications. Some might say it
    is the survival of the fittest, but what happens to
    Web Services in the mean time?

    Just some random thoughts.

    Cheers,

    Noel.
  22. The main issues that needs clarity before these are developed and deployed in real world scenario( and not just fictious flight reservation systems) are :

    1. Is this a feasible/practical approach to add another layer of complexity. Doesn't the flow description further call for a heavy middleware gateway approach to access a set of Web Services. Will this not become critical spot for the successful utilisation of the Web Services. Well might be big bucks for a heavy centralized server side systems :-), or probably this are visioned to be a distributed to client side.

    2. Can the execution of the WS interfaces really be automised through composition declaration (Flow). Considering the fact that these Services are developed over the Web by several parties. (Probably feasible for closely inter-related businesses.)

    3. Can the traditional flow techniques be applied to Web Services ? As they are supposed to be develop not just by one party and probably will not follow a common convention on the message structures. The Mapping seems to be the solution, but how much of incompatibility will these flow mechanisms be able to handle.

    4. There are features such as dynamic service lookup and composition within a flow systems, these seem to be too far fetching, maybe a feasible thing with a specific domain and in closed circle of inhouse defines set of service interfaces.

    5. The flow systems handles the faults and exceptions within transactions through compensations whose implementation is directly provided by the service interfaces. This means that the service interfaces prior to the inclusion within a flow should already address these. Then what is the added advantage these flow languages provide. Can this similar effect be done through Messaging conventions and client system implementation rather moving the logic to a server side ?

    Sorry for cross posting this previous thread but it seems relevant here.
    URL : Web Services Conversation-Workflow-Choreography Web http://www.theserverside.com/discussion/thread.jsp?thread_id=14886
    regards
    Balakrishnan
  23. I'll try to address some of your concerns, see my comments in <bn>

    1. Is this a feasible/practical approach to add another layer of complexity. Doesn't the flow description further call for a heavy middleware gateway approach to access a set of Web Services. Will this not become critical spot for the successful utilisation of the Web Services. Well might be big bucks for a heavy centralized server side systems :-), or probably this are visioned to be a distributed to client side.
    <bn>Once asynchronous web services become the norm for BI type comms then some type of middleware is needed to handle such conversations which can be long lived and interrupted in nature. Except when you are guaranteed 100% connectivity and availability of your BI party then persistent state/flows are needed to track the conversation. Whats a client in this scenarion, it's likely another application server, .Net or J2EE or broker/gateway type product. I don't think clients in the J2EE sense is a good place for such logic given the persistent/reactivity requirements. That's not to say that a client cannot use JAX-RPC to talk with a server synchronously, it's just that a client cannot handle an interrupted conversation that well.</bn>

    2. Can the execution of the WS interfaces really be automised through composition declaration (Flow). Considering the fact that these Services are developed over the Web by several parties. (Probably feasible for closely inter-related businesses.)
    <bn>I believe so. This is where public and private flows come in to the picture. Private flows are your businesses processes, specific to your business. These private flows have points at which they need to communicate with the BI party. Public flows (flows known by you and the BI party) are used to co-ordinate these conversations between this point in your private flow and the corresponding point in their flow. Ideally, these public flows are standard, with standard flows and data types. This may not be the case in which case you and your BI party develop a private one. Obviously, developing custom ones is expensive so ideally standards such as RosettaNet, ebXML etc are key to lowering the cost of implementing this integration.</bn>

    3. Can the traditional flow techniques be applied to Web Services ? As they are supposed to be develop not just by one party and probably will not follow a common convention on the message structures. The Mapping seems to be the solution, but how much of incompatibility will these flow mechanisms be able to handle.
    <bn>Yep, when using standard based communication this will be the case but as outlined in my reply to point 2, such mapping layers are needed and should not require XML. We need ways to map from all data formats and not just XML. XML may be the intermediate form between the two parties but the data pre mapping may not be XML. I think that standards such as Rosetta Net etc or mapping plus public flows are good patterns for solving most of these issues.</bn>

    4. There are features such as dynamic service lookup and composition within a flow systems, these seem to be too far fetching, maybe a feasible thing with a specific domain and in closed circle of inhouse defines set of service interfaces.

    5. The flow systems handles the faults and exceptions within transactions through compensations whose implementation is directly provided by the service interfaces. This means that the service interfaces prior to the inclusion within a flow should already address these. Then what is the added advantage these flow languages provide. Can this similar effect be done through Messaging conventions and client system implementation rather moving the logic to a server side ?
    <bn>Well, one way of looking at it is that the compensation actions are specified for a given web service. I'd prefer to see users being able to group a set of connected activities and specify a compensating flow. It's important to realise that compensation actions may not be synchronous them selves. Imagine a compensation flow which involves displaying a message on a screen, the operation then telephones the other BI party to cancel, when a positive response from the BI party is received then the work item is checked in and compensation has succeeded. The bottom line is that flow systems are an important part of co-ordinating asynchronous interrupted conversations, and compensation is just one of these.</bn>


    Thanks
    Billy
  24. Thanks Billy for a detailed comments, Here is my response to few of your comments in <bala> :-)

    1. Is this a feasible/practical approach to add another layer of complexity. Doesn't the flow description further call for a heavy middleware gateway approach to access a set of Web Services. Will this not become critical spot for the successful utilisation of the Web Services. Well might be big bucks for a heavy centralized server side systems :-), or probably this are visioned to be a distributed to client side.
    <bn>Once asynchronous web services become the norm for BI type comms then some type of middleware is needed to handle such conversations which can be long lived and interrupted in nature. Except when you are guaranteed 100% connectivity and availability of your BI party then persistent state/flows are needed to track the conversation. Whats a client in this scenarion, it's likely another application server, .Net or J2EE or broker/gateway type product. I don't think clients in the J2EE sense is a good place for such logic given the persistent/reactivity requirements. That's not to say that a client cannot use JAX-RPC to talk with a server synchronously, it's just that a client cannot handle an interrupted conversation that well.</bn>
    <bala> The concern here is that a generic middleware which needs to maintain the context of execution of the process/es which handles several 100s of clients(J2EE based / serverside components) specifically on Long Living Processes seems to be a overkill.Imagine this similar to a UDDI like registry but a broker instead which has even greater demand system resources as well a huge persistance requirement in addtion to probably handling Privacy \ Security Issues. I think so that if this is more likely distributed to the client side then it probbaly is a more realistic scenario in many ways.</bala>

    2. Can the execution of the WS interfaces really be automised through composition declaration (Flow). Considering the fact that these Services are developed over the Web by several parties. (Probably feasible for closely inter-related businesses.)
    <bn>I believe so. This is where public and private flows come in to the picture. Private flows are your businesses processes, specific to your business. These private flows have points at which they need to communicate with the BI party. Public flows (flows known by you and the BI party) are used to co-ordinate these conversations between this point in your private flow and the corresponding point in their flow. Ideally, these public flows are standard, with standard flows and data types. This may not be the case in which case you and your BI party develop a private one. Obviously, developing custom ones is expensive so ideally standards such as RosettaNet, ebXML etc are key to lowering the cost of implementing this integration.</bn>
    <bala>I agree with the idea of Private vs Public, I see now how the RosettaNet & ebXML can benefit from these scenarios in the Web Services .</bala>

    3. Can the traditional flow techniques be applied to Web Services ? As they are supposed to be develop not just by one party and probably will not follow a common convention on the message structures. The Mapping seems to be the solution, but how much of incompatibility will these flow mechanisms be able to handle.
    <bn>Yep, when using standard based communication this will be the case but as outlined in my reply to point 2, such mapping layers are needed and should not require XML. We need ways to map from all data formats and not just XML. XML may be the intermediate form between the two parties but the data pre mapping may not be XML. I think that standards such as Rosetta Net etc or mapping plus public flows are good patterns for solving most of these issues.</bn>
    <bala>From the Web Services interfaces point of view and related to Business process which could compose them into a workflow, I do not see how non XML based mapping is to be addressed. Is this not hidden behind the WSIs. So mapping of XML data is still the main view to this isn't it ? Are you talking of some sort of Binary Data \ something else ? Can you explain ?</bala>

    6. <Bala> Considering that a Business Process is defined using a Flow language, which represents composition of several Web Service Interfaces together. This can be viewed as a single Web Service as you expose only the publicly accessable interfaces to operate such Business Process. (I mean the client using the life cycle operations or the ultimate consumer\s of the Business process as a whole). This can then easily be considered as a Composite Web Service, right ? So if this can be a composite Service and the client system can be considered as any other WSI. Then why can't the same affects of such a Workflow system be implemented internally by a single Web Service. Do we in this case need such complex servers and specifications ? I personally am not against workflows and systems like this, but am interested to see such systems. but I am only trying to get out a strong reason why we need it for Web Services. </Bala>

    Thanks for your discussion,
    With Best Regards,
    Balakrishnan
  25. Hello,

    As a follow-up to the BPEL4WS specification that was released Friday by IBM, Microsoft and BEA, we have also developed an implementation of BPEL4WS called BPWS4J; it is available immediately at:
      
        http://www.alphaWorks.ibm.com/tech/bpws4j

    BPWS4J consists of two parts: an engine and an editor. The BPWS4J
    Engine is an all-Java implementation of BPEL4WS that runs in a
    servlet container. The BPWS4J Editor is an Eclipse plugin that can
    be used with Eclipse v2.0+ (http://www.eclipse.org/).

    BPWS4J uses WSIF for making service invocations, so it
    supports java and EJB bindings in WSDL (in addition to
    SOAP), so you can view these just like SOAP services and
    use them in BPEL4WS-described processes.

    BPWS4J was developed by the Component Systems Group at the IBM TJ
    Watson Research Center. The members of the group are: Francisco (Paco)
    Curbera, Matthew J. Duftler, Rania Khalaf, Nirmal Mukhi, William A.
    Nagy, and Sanjiva Weerawarana. Paco and Sanjiva are co-authors of
    the BPEL4WS specification.

    Bala, I believe youd get a better understanding of BPEL4WS
    and why it makes sense for web services by trying this out.

    Nirmal K. Mukhi
    Component Systems Group, IBM Research
    (BPWS4J team)
  26. How do you compare your specification with BPML + WSCI?
  27. They will converge.

    Billy
  28. Thanks billy to answer the question. Do you have the idea when they will converge and what the expected converged specification would look like?

    regards
    deepak mittal
  29. Probably as soon as BPMI.org realizes that they can't beat em, so better join em.

    unfortunate, because BPML seems to have better support for transactions, etc. so much wasted effort, why did IBM not join BPMI.org. Or maybe they did, but had some disagreements. who knows.

    meawhile, all of us get tossed around in this mess.





  30. See my comments:

    1) <bala> The concern here is that a generic middleware which needs to maintain the context of execution of the process/es which handles several 100s of clients(J2EE based / serverside components) specifically on Long Living Processes seems to be a overkill.Imagine this similar to a UDDI like registry but a broker instead which has even greater demand system resources as well a huge persistance requirement in addtion to probably handling Privacy \ Security Issues. I think so that if this is more likely distributed to the client side then it probbaly is a more realistic scenario in many ways.</bala>

    <bn>
    It's not overkill if this is your situation. If you want reliable interrupted conversations then this persistent state does need to be tracked. This takes resources and yes, there are privacy concerns. What is a client here? Another broker for your BI partner? Given some web services for even common place stuff can have lifetimes of several days (ordering a PC) and longer if you also model warranty and customer support post purchase etc. A flow could easily reach years. Thats why you need the infrastructure.
    </bn>


    2.<bala>I agree with the idea of Private vs Public, I see now how the RosettaNet & ebXML can benefit from these scenarios in the Web Services .</bala>
    <bn>Cool</bn>

    3. <bala>From the Web Services interfaces point of view and related to Business process which could compose them into a workflow, I do not see how non XML based mapping is to be addressed. Is this not hidden behind the WSIs. So mapping of XML data is still the main view to this isn't it ? Are you talking of some sort of Binary Data \ something else ? Can you explain ?</bala>

    <bn>
    WSDL is not XML. WSDL it-self is expressed in XML but I can and do easily have WSDL definitions for a service which I communicate with using IIOP. The bindings for the service specify how the parameters to the service and encoded. It doesn't need to be XML. You still need adapters to transmit the information between you and your partner using what ever middleware is required. It may be faxes, it may be a CICS deal, it may be RMI/IIOP, it may be email, it may SWIFT or FIX, it might even be a web service. Your flow shouldn't care. How the points on your private flow interact with the outside world should be handled using a layered approach using the public flows. So, you don't care if you see what I mean. You design your private flows using your data formats and middleware. It's the job of the public flow to hide any data conversion and middleware issues when dealing with external BI parties.
    It may be and will probably be the case that tooling can generate components which act as 'in' WSDL services which accept a foreign data structure using some middleware and inject it in to your system. The same tricks can also be used for out/in scenario as well as in/out and out scenarios.
    </bn>


    6. <Bala> Considering that a Business Process is defined using a Flow language, which represents composition of several Web Service Interfaces together. This can be viewed as a single Web Service as you expose only the publicly accessable interfaces to operate such Business Process. (I mean the client using the life cycle operations or the ultimate consumer\s of the Business process as a whole). This can then easily be considered as a Composite Web Service, right ? So if this can be a composite Service and the client system can be considered as any other WSI. Then why can't the same affects of such a Workflow system be implemented internally by a single Web Service. Do we in this case need such complex servers and specifications ? I personally am not against workflows and systems like this, but am interested to see such systems. but I am only trying to get out a strong reason why we need it for Web Services. </Bala>

    <bN>
    Not quite. Absolutely, a flow can be viewed as a web service. This is exactly what WebSphere 5.0 does do. How-ever, what kind of web service is it? It's an asynchronous one. You'll get the response possibly minutes, or hours or much later. This highlights the issues with JAX-RPC which we've already discussed with regards to this. Now, think harder about a flow. The flow once triggered may require you to respond later in the flow or to poke the flow by sending it an event. Each of these interactions is modelled using it's own WSDL interface. So, now your flow has one WSDL for invoking it, and one WSDL for each in/out and in nodes (from your point of view). Creating the flow will likely give you some form of correlation ID which you'll need to persist for later out's to the flow. The out/ins or outs will need to be co-ordinated and it's this co-ordination of multiple related events which really drives the suitability of flows for making this more manageable. It would be wrong to think of web services in synchronous terms. Once, you start thinking about them from as asynchronous point of view then I think using flows to co-ordinate these events makes a lot of sense and is why IBM and other vendors are investing in this technology and why standards like WSFL/BPEL/BPML are important to web services and to Java.

    Billy

  31. BPMI.org just released 1.0 of BPML back in June. Has BEA dropped their support of this spec in favor of BPEL4WS? BEA now supporting both WSCI from BPMI (with SAP, etc.) and this new choreography specification?

    The presence of these "big dogs" on this new spec make the BPML effort seem irrelevant.

    Can anyone shed some light on what is going on?

  32. I'll have to pay for specification? I am not mad, and people too, as well!