RE: Subject: RE: eBTWG Proposal BPSS Revision Project 0.3 DRAFT

[LONJON Antoine <alonjon@mega.com>]

Tim,

A great thanks for your comments. The debate is reaching a very interesting
point.
I definitivly agree that there are two kinds of audience, BusinessAnalysist
and Technical engineer, and therefore that we need two views for the same
problem. At the same time, everybody recognizes that these two views have to
be related to each other. The BPSS project is that attemp.
On the business model side, I am not sure that the language of choice is the
state language.
Your sentence 
"...This is where problems like prohibiting transition to self force the
user of
the model to model their system in ways that are not in keeping with what is
really happening at the business level...."
tends to show the limits of such a language to express complex choreography
(Collaboration)
Most unfortunatly, the activity diagram of UML 1.3, which is basicaly an
action language, has been build on top of the state language. This has made
discussion about action language very difficult. This issue is recognized
inside the OMG itself.
Most of the troubles we are facing in BPSS now is the use of transition
semantics to express coordination of actions.

I apologize for developping in detail this point, but it hightlights how
modeling technics have an impact on both the ability to express business
requirements and the ability to transform the models into executable
statements.

As a temporary conclusion (there is no final statements), my thoughts are
the following:
1. New modeling technics are now emerging to take into account the new
requirements for designing complex environments. This is mainly going to
happen at the OMG.
2. Some constraints of the executable languages like pi-calculus also make
sense at the business level even if they do not apply at the same level of
granularity.
3. BPSS, as today, is meant to be used as an executable language on top on
the other ebXML specifications (TRP, CPP, ...). It has relationships with a
modeling methodology, the UMM, but it does not need to be one to one for the
reasons you mentionned in your email (two views)
4. As an executable language BPSS can't ignore what is happening is that
part of the market
5. As a business view BPSS can't ignore what is happening in the modeling
space
6. This is strictly my opinion: BPSS is mainly an action language

Regards,
Antoine


-----Original Message-----
From: Collier, Timothy R [mailto:timothy.r.collier@intel.com]
Sent: Wednesday, August 29, 2001 12:22 PM
To: 'ebxml-bp@lists.ebxml.org'; LONJON Antoine
Subject: Subject: RE: eBTWG Proposal BPSS Revision Project 0.3 DRAFT


Antoine,

	I think what is being discussed here is clearly a focal point for
determining the direction of BPSS, and possibly its future.  Who is the
intended user of BPSS?  Is it a business analyst, who wants to model their
activities in a manner close to the logical business process? Or, is the
user an implementer who needs to model a specific solution?  Their needs are
quite different.  For the analyst, they will want the ability to model more
of a state diagram approach, where the entire "manage purchase order" model
is depicted, for example.  Including request purchase order, some number of
optional modify purchase order, some number of optional query purchase
order, as well as ship, and cancel purchase order.  All of these activities
should be expressible as part of the same model, in a logical (but not
necessarily executable) model.    
	In an executable model approach, where the workflow specifications
are starting to crop up (WSFL, XLANG, ...), the user is constrained to an
edge directed, acyclic, pi-calculus based model.  You cannot in these
approaches model larger granularity activities like manage purchase order.
This is where problems like prohibiting transition to self force the user of
the model to model their system in ways that are not in keeping with what is
really happening at the business level.  They must think like a programmer,
and make sure all of the activities are deterministic.
	I am not saying one approach is right or wrong, what I am trying to
point out is - if BPSS is going to go down the path of being executable, and
compete head on with the web services specifications, it should do so only
after clearly understanding who their customer is and what need it is
addressing.

	Tim


-----Original Message-----
From: LONJON Antoine [mailto:alonjon@mega.com]
Sent: Tuesday, August 28, 2001 7:14 AM
To: 'Maarten Steen'; ebxml-bp@lists.ebxml.org
Subject: RE: eBTWG Proposal BPSS Revision Project 0.3 DRAFT


Marteen,

Thanks again Marteen for your clear position and statements.
I would also like to highlight that several points.

1. Executability is a major issue that can only be solved with clear
semantic defined at the XML layer.

2. There is going to be a big next step with UML in its 2.0 version. UML as
any specification needs to be improved. Lots of major issues are going to be
addressed in this revision. My guess is that this is also going to change
UMM.

3. There are outside ebXML a number of other XML specifications for
communication over the internet, especially the webService camp. Nobody can
ignore that the major vendors are investing in that direction. WSFL from IBM
is really a sign of that evolution (WSFL sits on top of webService
definition to define ....... choreography of services .....)
Without a focus the points (4, 5, and 6) highlighted by Marteen, the BPSS
project could become isolated from the implementation world without the
knowledge of people that can grant real executability and .... market
adoption. 

Regards,
Antoine

Antoine Lonjon
Chief Architect
MEGA International
Tel   : 1 781 890 3442 ext 18
Cell  : 1 781 983 1536
email: alonjon@mega.com


-----Original Message-----
From: Maarten Steen [mailto:maarten.steen@telin.nl]
Sent: Tuesday, August 28, 2001 5:17 AM
To: ebxml-bp@lists.ebxml.org
Subject: Re: eBTWG Proposal BPSS Revision Project 0.3 DRAFT


I think all three proposals (Brian's, Karsten's and David's) are close
enough to allow
for a compromise that keeps everyone happy. As I said before, I would
support either
proposal, but I'd like to see the following points addressed in the
final proposal.

In his submission Karsten makes a few very valid points (4, 5, and 6)
that need to be
addressed by the BPSS or the BCSS project:

4. Focus on run-time interoperability, not on modelling.
5. Focus on XML not on UML
6. Focus on executability, not on business modelling.

We have already enough modelling languages, not only for internal
business processes
but also for defining collaborations. What we really need from ebXML is
an exchange
format for collaboration specs. Moreover, this exchange format should be
based on a
sound meta-model for business collaborations and have proper semantics.

Therefore, I'd like to see a work item on defining the semantics of
business
collaborations.

Unlike Karsten, I believe alignment with the UMM metamodel is important.
It defines our
vocabulary, but it does not necessarily have to be the law. Let's put
the UMM
meta-model to the (executability) test. Is it possible to define a
proper operational
semantics for it?

Regards,
Maarten Steen


"Hayes, Brian" wrote:

> Dear Collegues:
>
>      I am submitting for further review the proposal I emailed last
> Friday, Aug 24th (subject: eBTWG BPSS Project Proposal).  The comments and
> Karsten Riemer's alternative proposal have been good input.  I was asked
at
> today's BP teleconference to review Karsten's proposal and see if I could
> come up with a compromise proposal.  There was a good deal of similarity
> between the two proposals.  However found it difficult to envision a
> compromise proposal since the nature of the proposals are significantly
> different.
>
>      Here is a summary of the changes that I made to the version 0.2, Aug
> 24th proposal:
>
> + 1.2 Scope - Changed "and implment in the BPSS the substantive changes
> developed by other projects..." to "and implement limited changes to the
> BPSS recommended by other projects..."
>    [This addresses John Yunker's concern about substantive changes.  The
> limitation on changes is also addressed in the description of the first
> deliverable.]
>
> + 2 Deliverables
>   + Changed schema version in the first bullet to "1.0.1+" from "1.1".
>      [Aligns with Karsten Riemer's proposal, first bullet of Deliverables]
>
>   + Added deliverable
>      - Consideration of renaming of the Business Process Specification
> Schema
>        to the Business Collaboration Specification Schema
>        (This is to differentiate the schema with specifications and
> implementations
>         that address internal "business process," EAI, and workflow)
>     [Addresses Todd Boyle's concern]
>
>   + Changed deliverable "Business Process Specification Schema 1.x and
2.0"
> to
>     "Requirements for Business Process Specification Schema 2.0"
>       (Document requirements for the future version of the specification;
>       the requirements include incorporating other ebXML and related
> standards
>      work and improving its related model and objects)
>     [This captures the stuff that is out of scope for the project but will
> likely be discussed in the course of the project.]
>
>   + Added explaination to deliverable "Identify opportunities to
coordinate
> with other relevant standards"
>      (Includes, but is not limited to, web services standards and
>      internal process flow/language standards)
>     [This captures the web services, XML runtime process languages, and
> other eBusiness standards aspects of Karsten Riemer's proposal.  I think
> this "deliverable" gives the project significant leeway to address
various,
> but relevant, standards.]
>
> + 3 Functional Membership
>    Changed opening paragraph and bullets to
>      "The project team is a group of experts with broad knowledge and
> experience in the areas of national and international business processes
> and
> information exchanges crossing multiple vertical industry and service
> sectors, as well as representation from the technical development and
> implement ion community."
>     [Per suggestion from Klaus-Dieter Naujok]
>
> I hope my changes capture everyone's input.  My new plan is to submit this
> the eBTWG chair on Wednesday, Aug 29th, end-of-business-day.
>
> Best Regards,
> Brian Hayes
> +1 (925) 520-4498
>  <<BPSS-Revision-Project-WIP-O.3.htm>>
>

--
Dr. ir. Maarten W.A. Steen - Scientific Researcher
Telematica Instituut, Postbus 589, 7500 AN  Enschede, The Netherlands
http://www.telin.nl/
phone: +31(0)53 4850 321
fax: +31(0)53 4850 400

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>