[ebxml-dev] WS vs ebXML poll

[Jean-Jacques Dubray <jjd@eigner.com>]

Webservices.org is running a poll about ebXML vs WS. Cast you opinion.

http://www.webservices.org/index.php/poll/result/27


Jean-Jacques 
 

>>-----Original Message-----
>>From: Jean-Jacques Dubray [mailto:Jean-Jacques.Dubray@eigner.com]
>>Sent: Friday, June 14, 2002 6:27 AM
>>To: 'Frank. Christopher'; 'ebxml org'; ebtwg-bps@lists.ebtwg.org
>>Subject: [ebxml-dev] WSCI SUN, BEA vs IBM and .NET
>>
>>I as explained (www.ebpml.org/wsci.htm) I would not hold my breath on
>>YAS (yet another spec) for web services choreography. It is
embarrassing
>>enough that these guys have now 4 specs to deal with while ebXML has
>>only one.
>>
>>It is clear to me that this spec is a faint attempt to regain traction
>>while IBM and MS are cruising the web services space.
>>
>>Ultimately, the W3C does not even have the beginning of a plan to
>>standardize the choreography of web services !
>>
>>Cheers,
>>
>>Jean-Jacques Dubray____________________
>>Chief Architect
>>Eigner  Precision Lifecycle Management
>>200 Fifth Avenue
>>Waltham, MA 02451
>>781-472-6317
>>jjd@eigner.com
>>www.eigner.com
>>
>>
>>
>>>>-----Original Message-----
>>>>From: Frank. Christopher [mailto:C.Frank@seeburger.de]
>>>>Sent: Friday, June 14, 2002 5:55 AM
>>>>To: ebxml org; ebtwg-bps@lists.ebtwg.org
>>>>Subject: AW: [ebxml-dev] New WSCI spec competes with BPSS.... NOT
>>(very
>>>>long)
>>>>
>>>>Hello,
>>>>
>>>>I am stunned. There really is a spec which competes with BPSS? How
>>dare
>>>>they?
>>>>
>>>>Reading this thread, I get the impression, that actually Ford never
>>>>build a new car as long as Volkswagen has not sold ALL of the cars
of
>>>>their last new series.
>>>>
>>>>I just finished reading the thread with Jean-Jacques comments (well,
>>>>most of them;-) and had a look at the WSCI spec myself. I am not
even
>>>>close that deep into the BP(M) than Jean-Jacques is. But I just
>>thought:
>>>>yepp, this (WSCI) is another SUV vehicle which has four tires (maybe
3
>>>>and a half) but is confusing pedals for brakes and acceleration
which
>>>>will make driving a bit complicated. (By the way: Thanks a lot
>>>>Jean-Jaques for doing the analysis.)
>>>>
>>>>We, the software "producer" (and I include Sun, MS and IBM) are in
>>>>competition (as Ford competes with Volkswagen) with each other, and
we
>>>>are not playing the game because of the game, but because of the
>>money.
>>>>Great, if we can overcome this and generate together something
clever
>>>>like ebXML. But this does not necessarily mean that we do this and
>>only
>>>>this. If we cannot put ebXML to market until others (or you or me;-)
>>>>generate something "newer" (and "better" is unfortunately
secondary),
>>>>ebXMl has, for whatever reason, to notice Darwins rule.
>>>>(And the very same does apply for WSCI.;-)
>>>>
>>>>If WSCI or any other "standard" or "trial" is overuling BPSS I would
>>cry
>>>>bitter tears (like most of the readers of this list I guess)
>>especially
>>>>if it would be overruled by something which is less good (remember
>>CORBA
>>>>and COM), because I could put all my clever thoughts and already
done
>>>>implementation to trash, but this is the world we live in. Being the
>>>>best thing to solve the issue, consists of so much more influences
>>then
>>>>only the plain (cool) technology (from the deepest bottom of my
heart:
>>>>unfortunately consist of so much more than technology).
>>>>
>>>>Best Regards
>>>>Christopher
>>>>(SEEBURGER AG, Senior Developer/Research)
>>>>
>>>>
>>>>(Truman: "If you can't stand the heat, get out of the kitchen.";-)
>>>>
>>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>>>Gesendet: Freitag, 14. Juni 2002 07:09
>>>>An: andrzej@chaeron.com
>>>>Cc: 'Assaf Arkin'; 'Stefano POGLIANI'; 'ebxml org';
>>>>ebtwg-bps@lists.ebtwg.org; 'Christopher Ferris'
>>>>Betreff: RE: [ebxml-dev] New WSCI spec competes with BPSS.... NOT
>>(very
>>>>long)
>>>>
>>>>
>>>>Andrzej:
>>>>
>>>>Thank you very much for pointing this specification to us.
>>>>____________________________________________________________________
__
>>__
>>>>____
>>>>Summary
>>>>
>>>>After much blabla and sarcasm I analyze the WSCI spec. Aside from
the
>>>>fact that this spec is a shameless cut and paste from BPML 0.4, as
>>usual
>>>>- and it is now a constant amongst "web services spec writers"- they
>>>>treat B2B as an extension of app-to-app integration (with is not the
>>>>same as EAI).
>>>>
>>>>The key semantic of EAI is publish/subscribe. This has been
>>established
>>>>for at least a decade with the developments of MOM and yet, the
>>authors
>>>>of WSCI try to brainwash us saying that point-to-point integration
is
>>>>better. You should tell Ford or Boeing about that.
>>>>
>>>>No guys, Collaboration are mostly a B2B concept (see below), and
>>>>therefore should have B2B semantics such as non-repudiation, legally
>>>>binding, confidentiality, security, tamperproof,... I talk with real
>>>>customers every day which need these semantics. I even talked to a
>>>>customer today that was pleasantly surprise to hear about Core
>>>>Components. He told me this is exactly what he needed as their data
>>>>model varies a bit and ofteb with the business partners. I was
stunned
>>!
>>>>These semantics would not be too hard to add to WSCI, but you guys
>>lack
>>>>the understanding of what B2B is about, it is NOT app-to-app
>>integration
>>>>over the internet. Where have you been in the last 4 years?
>>>>
>>>>Far from "killing" ebXML this specification represents the missing
>>link
>>>>that would allow us to link ebXML with business process definitions.
>>>>
>>>>I actually feel sorry that someone would like to "kill" another
spec.
>>>>However, this is good when people use this kind of words, it brings
a
>>>>lot of suspicion and often signals something without substance.
>>>>____________________________________________________________________
__
>>__
>>>>____
>>>>Disclaimer: all the thoughts expressed here only represent my
opinion
>>>>and not the one of my company. Some of the comments are for the
>>purpose
>>>>of entertainment, given as jokes -french humor- others are an
>>objective
>>>>analysis of WSCI/BPSS for the education of the interested reader.
>>>>
>>>>I am sure that some of my comments are plain wrong, out of ignorance
>>or
>>>>sarcasm.
>>>>
>>>>I apologize in advance if my comments hurt the sensitivity of the
>>>>reader. It must be this hot summer night in wonderful Grotzingen
>>germany
>>>>that got me started. Ah... unless it is the mirabelle.
>>>>____________________________________________________________________
__
>>__
>>>>____
>>>>
>>>>This is always fun to see a new Specification from Intalio (since
this
>>>>is so much based on BPML 0.4, I assume Intalio is the main driver).
>>>>However, it would be nice if they could finish the other specs
before
>>>>they start new ones, BPML comes to mind. I guess they must be
looking
>>>>for more funding yet again. We live an extraordinary time, people
>>write
>>>>a few paragraphs, add a few ppt figures (you should see BPML 0.1 to
>>>>understand what I am talking about), don't forget to fetch a few
names
>>>>from industry giants, add the smell of "killing" something and boom,
>>>>millions of dollars fall from the sky to do more of that, without
any
>>>>control: does it makes sense? do this guy knows what he is talking
>>>>about? If you succeed with the first round, you can even attempt the
>>>>second round -the sky is the limit- by changing a little bit your
>>>>paragraphs, changing the title, bandwagon the latest hottest idea on
>>the
>>>>market, an boom, jackpot again. The odds are far better than the
>>lotto.
>>>>I must be in the wrong business.
>>>>
>>>>It is also fun so to see that Intalio finally gets it. Even though I
>>>>have a lot of respect for people like Assaf, it would have been only
>>two
>>>>years next September that I joined BPMI and try to convince him that
>>>>"Collaboration" was a key artifact of the Business Process
Definition
>>>>metamodel, namely, a Business Process is for the most part a series
of
>>>>collaborations mediated by the Business Process Engine. This is
>>>>represented on figure 1-1 of the WSCI spec. I have shown that kind
to
>>>>picture in BPMI many times, with all but contempt. In particular
this
>>is
>>>>what makes the "technical binding" of the operations far easier. The
>>>>funny part is that BPML was designed without any alignment with B2B
>>>>semantics (as of v0.4) while 90% of the processes that will be
defined
>>>>with BPML involve B2B interactions! I think that Intalio must not
sell
>>>>many products so they have not yet integrated notions like orders,
>>>>invoices, customer support, negotiation, commitment, fulfillment...
>>They
>>>>probably do a lot of internal stuff at this point.
>>>>
>>>>I commented many times about the "Marketing world" in which we live
so
>>>>let me comment now on the new ebXML "killer" on the block. As
volume,
>>>>bass or treble is not an option to carry out your message, the only
>>>>thing left is "word inflation". As usual I will try to be as
objective
>>>>as I can, Assaf is a really smart guy and more than often produces
>>>>excellent work: Castor, Tyrex, BPML, I guess WSCI is the exception.
>>>>
>>>>So let's start dissecting this new killer. The introduction tells
us:
>>>>"WSCI provides an important foundation for ...
application-application
>>>>collaboration." Ah..Ah... so they are doing this as an alternative
to
>>>>EAI.. uhm where is B2B here? .. Ah yes they talk about it later ...
>>>>"These business processes may reside entirely within the confines of
a
>>>>single company, or span across multiple organizations or companies."
>>Yes
>>>>this is a constant amongst web services people: lump sum EAI and
B2B.
>>>>B2B is just application-to-application integration beyond the
>>firewall,
>>>>so what's the big deal about B2B? Well, you should try to convince
>>Ford
>>>>which has 2500 enterprise systems world-wide, or Boeing which has a
>>mere
>>>>84 procurement systems that it has to do application-to-application
>>>>integration over the internet with its tens of thousands of
suppliers.
>>I
>>>>guess Intalio could not be further from the reality. I am surprised
>>that
>>>>BEA and SUN could associate their name with this kind of approach. I
>>>>would assume, that this is not really SUN or BEA talking just the
>>>>individuals eager to paste their names on this kind of sheet (not
>>shit).
>>>>However both BEA and SUN don't have much to offer in terms of web
>>>>services. BEA has just released a new "IDE for web services" KaKa,
>>Kajun
>>>>or something like that but to web service enable what? A few session
>>>>beans? SUN is in complete disarray desperately trying to catch up
with
>>>>.NET and IBM by controlling all the possible web services
>>>>specifications. They lost the Java, J2EE, EAI/B2B (Forte) battles
with
>>>>abysmal market share, to the point that they are now giving away
>>iPlanet
>>>>-free, who wants to bet that they will dominate the web services
>>battle?
>>>>No the guys that get it are the webMethods, Sybase, IONA's of the
>>world.
>>>>Their approach is based on understanding the value and positioning
of
>>>>Web Services. In particular they are a complementary paradigm to
EAI,
>>to
>>>>that effect, WebMethods provides the best approach I have seen so
far
>>in
>>>>the industry, and they don't need to "kill" to sell it (see my
summary
>>>>on www.ebpml.org/showcase.htm). Yes some of the web service spec and
>>>>infrastructure can be reused for B2B but you need the "business
>>>>semantics" that WebServices keep lacking. ebXML IS business level
web
>>>>services, that sits on top of RPC level web services. So let's dive
>>into
>>>>this point, boy this is fun.
>>>>
>>>>First, the acute reader would have noticed that the WSCI bears a
>>strong
>>>>resemblance with BPML 0.4., the transaction model, the correlation
>>>>model, the choreography model are all direct copy and peste from
BPML
>>>>0.4.
>>>>
>>>>In the overview section of the spec, here we go again:
>>"...interactions
>>>>between services - either in a business context or not" that
statement
>>>>suggest to me that they have no Business semantics, I guess that's a
>>>>good way to kill ebXML but let's verify that. And they cannot
>>emphasize
>>>>this point enough (Thank you guys): "WSCI does not assume that Web
>>>>Services are from different companies, as in business-to-business;
it
>>>>can be used equally well to describe interfaces of components that
>>>>represent internal organizational units or other applications within
>>the
>>>>enterprise." The problem is that in traditional EAI the business
>>>>semantics are an unnecessary burden, while no business semantics
makes
>>>>the spec unusable in B2B scenarios. This is very layering seems to
be
>>>>the right thing to do.
>>>>
>>>>The key semantic of EAI is publish/subscribe. This has been
>>established
>>>>for at least a decade with the developments of MOM and yet, the
>>authors
>>>>of WSCI try to brainwash us saying that key app-to-app semantics
are:
>>>>"Most Web Services, however Participate in longer conversations,
>>>>spanning beyond the boundaries of a single operation. In these
>>>>conversations, the ability to perform certain operations depends
upon
>>>>the previous exchange of messages as well as the way to interpret
the
>>>>content of each message may be influenced by the previous exchange."
>>No
>>>>I am sorry, there are very few scenarios in EAI that can be
supported
>>by
>>>>this kind of approach. You are back to point-to-point, wake up guys
!
>>I
>>>>am actually surprised of this approach as Assaf had found a very
>>>>interesting concept in BPML (Consume and Produce). However, the spec
>>>>breaks the concept with the global model, it is no longer a pub/sub
>>>>semantic but rather a binding semantic. Another "detail", I did not
>>find
>>>>in the spec the notion of "transformation" though it is a key
feature
>>of
>>>>EAI system an necessary for loose coupling integrating,... oh yes,
>>this
>>>>is the new an improved point-to-point integration model where all
>>>>application share the same semantics.
>>>>
>>>>You don't get it, do you? Collaborations are mostly a B2B thing. Yes
>>you
>>>>can model some API interaction in point-to-point manner. But, you
>>don't
>>>>publish your orders, you send them to your suppliers ! The problem
>>again
>>>>is that WSCI does not support any business semantics, not even
>>pub/sub.
>>>>Who are you going to convince to use WSCI? Can't use it for B2B,
can't
>>>>use it for EAI.
>>>>
>>>>Let's analyze the different aspects of the spec:
>>>>
>>>>First, to be clear, all these concepts are directly repurposed from
>>BPML
>>>>0.4. Even the concept of Human Agent is coming from there. I must
>>admit
>>>>that I can't wait to see what BPML 1.0 will look like. Maybe a cut
and
>>>>peste from WSCI?
>>>>
>>>>I like the distinction between WSDL (Static interface definition) as
>>>>opposed to WSCI (dynamic behavior of the static definition). This
>>>>approach gives you an automatic binding between the collaboration
>>>>definition and the technical parameters of the web service.
>>>>
>>>>"Business processes are increasingly relying upon collaboration",
boy
>>>>why didn't I think of that before, I guess Assaf, you are finally
>>>>getting it. Just change increasingly by "almost exclusively" and you
>>are
>>>>there.
>>>>
>>>>"WSCI is not a "workflow description language"": strange, because
all
>>>>the semantics are coming from BPML 0.4.
>>>>
>>>>1) Message choreography
>>>>"The Action, is the basic construct of WSCI, and it is bound to some
>>>>WSDL operation. WSCI specifies how multiple actions are
choreographed
>>in
>>>>a simple sequence."
>>>>
>>>>An action is actually not a concept really different from operation
>>>>here, it is just a bag to add properties to an operation like
>>>>correlation and role performing that operation. It is not really an
>>>>action in the sense of event condition action, or WfMC actions, the
>>>>concept does not relate to "state" or "activity". Actually the best
>>>>proof of this is that they stop talking about Action and then talk
>>about
>>>>"WSCI describes the behavior of a Web service in terms of
>>choreographed
>>>>activities." and "The most common atomic activity is action." This
is
>>a
>>>>poor choice of word as activity and action have precise semantics in
>>>>this context. Also, I sense a design flaw here, do you support the
>>>>concept of using an action definition more than once within the
>>>>choreography (not part of a loop). BPSS supports the notion of a
usage
>>>>of a business transaction(~action), this is called
>>>>BusinessTransactionActivity which means that the same BT definition
>>can
>>>>be reused any number of time. This is a must, this is a very useful
>>>>concept. I don't think you have the same thing. Do you?
>>>>
>>>>We can see directly from the example that WSCI is "asymmetric" in
>>other
>>>>words, it is designed from the perspective of one side of the
>>>>collaboration. So that works well here because the user manages the
>>>>collaboration in his head. In a real scenario you need to map the
>>>>actions of one side to the one of the other.  Microsoft has
struggled
>>a
>>>>lot with this asymmetry in XLang, WSFL came out with a more elegant
>>>>approach and the concept of global model. I actually can't believe
my
>>>>eyes, after BPML being a plagiary of XLang (though better), they now
>>>>shamelessly "borrow" from WSFL, with the same concept of Global
>>models.
>>>>These guys are the champion of cut and peste. As usual, they don't
>>>>reference their sources. Your reference list is hilarious. W3C that,
>>W3C
>>>>this. How impressive, you guys must be smart to read all these
>>>>specifications. See, the worst thing that the web has brought to us
is
>>>>un-refereed publications. Anybody can publish anything and get away
>>with
>>>>it!
>>>>
>>>>In comparison, ebXML is designed in a totally symmetric manner, such
>>>>that the business service interfaces of each partner can be
configured
>>>>from the same collaboration definition. I think that this is a
>>>>fundamental flaw of the web services concept when use in
collaborative
>>>>applications (not in Stock quotes), because you deal with twice as
>>much
>>>>xml, plus you need to glue the pieces together. With that respect
>>ebXML
>>>>BPSS is far more elegant and efficient.
>>>>
>>>>The control flow is a "block-structured" control flow and is
specified
>>>>with the semantics:
>>>>Complex processes
>>>>Sequential execution
>>>>Parallel execution
>>>>Looping
>>>>Conditional execution
>>>>
>>>>I guess you would have guess by now ... guys this is sick, this is a
>>>>shameless cut and peste of BPML 0.4. Unfortunately, I think that
block
>>>>structured control flow is not the most appropriate choreography
model
>>>>here. You have definitely negotiation pattern that would be hard to
>>>>model with a block structured approach.
>>>>
>>>>Also could you explain me something? Just like ebXML you specify the
>>>>choreography of a collaboration, why is it within a <process>
element?
>>>>Would <collaboration> be more appropriate. It can't be that you read
>>>>BPSS too many times, since you have no idea about BPSS semantics.
>>>>
>>>>
>>>>2) Transaction boundaries and compensation
>>>>In BPSS, we did not find the notion of Roll-back appropriate. So yes
>>>>WSCI describes also compensating transaction, which is more the way
a
>>>>business operates (roll-back is more app-to-app kind of thing). BPSS
>>>>does not have that, but we did not find it a hurdle to model real
>>world
>>>>collaboration, as they can be modeled anyways, the only difference
is
>>>>that these business transactions are not tagged as compensating
>>>>transactions.
>>>>
>>>>3) Exception handling
>>>>The exception behavior is yet a copy/peste from BPML. ebXML BPSS is
>>able
>>>>to identity exceptions (technical or business) but let the designer
of
>>>>the collaboration specify the course of action. It looks more
>>>>appropriate to use the WSCI approach (as a java programmer),
however,
>>>>from a practical perspective, I don't think you gain much there.
There
>>>>is a key semantic that is missing in WSCI, which I think cannot be
>>>>added: BPSS:acceptanceAcknowledgement which signals that a message
was
>>>>correctly processed by the receiving application. In B2B this is
>>>>essential to synchronize the state of two companies. In our world,
>>PLM,
>>>>people exchange large CAD files (we have customer which ships a
whole
>>>>car !). As part of the exchange, you really want to know not only
that
>>>>your message got there (Via a web service), but that it correctly
>>loaded
>>>>in the receiving application whether it is a CAD system, or even if
it
>>>>is reviewed by a user !!
>>>>
>>>>4) Thread management
>>>>WSCI (like BPML) also uses the concept of "correlation" to identify
>>the
>>>>collaboration instance of a given message. I personally dislike this
>>>>approach and rather carry a cookie around to maintain context. I
think
>>>>this is more a matter or preference. I feel that the cookie is
cleaner
>>>>and more general. You don't get stock if the correlation is
ambiguous
>>or
>>>>need to span several elements of a document. The major advantage of
>>WSCI
>>>>approach is in multiparty collaboration as show in their example.
But
>>I
>>>>don't think they fully solve the multiparty collaboration problem
just
>>>>yet. BPSS does not either.
>>>>
>>>>5) Properties and Selectors
>>>>The property concept is good, as it decouples the choreography
>>>>specification from the document formats of the message exchange.
BPSS
>>>>should use that concept.
>>>>
>>>>6) Connectors
>>>>Did not find much about this
>>>>7) Operational context
>>>>Did not find much about this
>>>>8) Dynamic participation
>>>>Did not find much about this
>>>>
>>>>So in conclusion, I think they fall short of understanding the B2B
>>>>semantics that ebXML implements. I cannot find a customer that told
>>me,
>>>>no "I don't need the business semantics provided by ebXML (BPSS in
>>>>particular), I can live with XLang or WSFL, and now the new and
>>>>turbo-charged WSCI". (Va-va-voom)
>>>>
>>>>However, you do provide the missing piece for linking ebXML to
>>Business
>>>>Process Management Systems, which I was trying to introduce when I
was
>>>>working at BPMI. As I explained in chapter 6 of the book,
Professional
>>>>ebXML foundation, you need to wrap the ebXML business service
>>interface
>>>>into web services in order to let your enterprise systems use the
>>>>B2b/Ebxml infrastructure. WSCi represent the missing link which
allow
>>me
>>>>to strip the business semantics (once you are within your four
walls,
>>>>you don't need it anymore) and enable a business process management
>>>>system to take over and control the b2b collaboration message
exchange
>>>>with the appropriate interactions of your enterprise systems.
>>>>
>>>>Good work, could do better though. So how long did it take you to
>>write
>>>>it? A couple weeks? Maybe a week for the art work? Congratulations
on
>>>>the coloring scheme, I am sure the VCs will be impressed.
>>>>
>>>>Cheers !
>>>>
>>>>
>>>>Jean-Jacques Dubray____________________
>>>>Chief Architect
>>>>Eigner  Precision Lifecycle Management
>>>>200 Fifth Avenue
>>>>Waltham, MA 02451
>>>>781-472-6317
>>>>jjd@eigner.com
>>>>www.eigner.com
>>>>
>>>>
>>>>
>>>>>>-----Original Message-----
>>>>>>From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>>>>>>Sent: Thursday, June 13, 2002 11:18 AM
>>>>>>To: ebxml-dev@lists.ebxml.org
>>>>>>Subject: [ebxml-dev] New WSCI spec competes with BPSS....
>>>>>>
>>>>>>The new Web Service Choreography Interface spec has been developed
>>and
>>>>>>released by a consortium including Sun, BEA, Intalio, and SAP.
>>>>>>
>>>>>>The spec can be found here:
>>>>>>
>>>>>>	http://titan.intalio.com:8080/intalio/wsci/
>>>>>>
>>>>>>According to a contact at Intalio (prime movers behind BPMI), and
I
>>>>quote:
>>>>>>
>>>>>>> Think of wsci as an ebxml killer and the public interface to any
>>>>>>process,
>>>>>>> making it reusable and exposing it where needed since that
process
>>>>is a
>>>>>>> private implementation (BPML)
>>>>>>
>>>>>>Basically, it looks like WSCI is intended to supplant BPSS.  This
is
>>a
>>>>bit
>>>>>>strange,
>>>>>>given Sun's participation and support of ebXML initiatives.  WSCI
>>>>would be
>>>>>>used to
>>>>>>specify public processes, whereas BPML would be used to specify
>>>>private
>>>>>>(internal)
>>>>>>processes.
>>>>>>
>>>>>>It distresses me that the whole world of XML-dialect standards
seems
>>>>to be
>>>>>>splintering as soon as you try to get anywhere beyond the basic
>>specs
>>>>>>(XML, SOAP,
>>>>>>WSDL, UDDI) that the vendors have all agreed to.  Seems that
vendors
>>>>are
>>>>>>still
>>>>>>playing their usual games vying for proprietary lock-in higher up
in
>>>>the
>>>>>>protocol
>>>>>>stacks.
>>>>>>
>>>>>>It behooves the users/customers to loudly complain and demand
>>>>standards-
>>>>>>based,
>>>>>>interoperable solutions.  We've had a taste of the benefits that
>>such
>>>>an
>>>>>>approach
>>>>>>brings to the table....let's keep pounding the vendors till they
>>>>deliver
>>>>>>on such
>>>>>>promises higher in the stack as well.  This also leads me to
believe
>>>>that
>>>>>>there might
>>>>>>be market share gain opportunities available to software vendors
>>that
>>>>take
>>>>>>the high
>>>>>>road of global standards compliance (New Era/Sybase come to mind
>>>>here).
>>>>>>
>>>>>>I'ld be interested in hearing from Sun people that hang on this
list
>>>>as to
>>>>>>what their
>>>>>>intent is regarding ebXML standards (like BPSS) versus this new
WSCI
>>>>>>proposal.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>...Andrzej
>>>>>>
>>>>>>Chaeron Corporation
>>>>>>http://www.chaeron.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>----------------------------------------------------------------
>>>>>>The ebxml-dev list is sponsored by OASIS.
>>>>>>To subscribe or unsubscribe from this elist use the subscription
>>>>>>manager: <http://lists.ebxml.org/ob/adm.pl>
>>>>
>>>>
>>>>
>>>>----------------------------------------------------------------
>>>>The ebxml-dev list is sponsored by OASIS.
>>>>To subscribe or unsubscribe from this elist use the subscription
>>>>manager: <http://lists.ebxml.org/ob/adm.pl>
>>>>
>>>>----------------------------------------------------------------
>>>>The ebxml-dev list is sponsored by OASIS.
>>>>To subscribe or unsubscribe from this elist use the subscription
>>>>manager: <http://lists.ebxml.org/ob/adm.pl>
>>
>>
>>
>>----------------------------------------------------------------
>>The ebxml-dev list is sponsored by OASIS.
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.ebxml.org/ob/adm.pl>