OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [regrep] Reg/Rep 1/20/2005: Comments on ebRS v3.0 Draft




Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 

> -----Original Message-----
> From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
> Sent: Thursday, January 20, 2005 5:27 PM
> To: ebXML Regrep (ebXML Regrep)
> Subject: [regrep] Reg/Rep 1/20/2005: Comments on ebRS v3.0 Draft
> 
> [general] spell check carefully
> [general] Should we consider breaking out the SAML profile 
> similar to how WS-Security OASIS has approached the use of 
> token profiles? One editorial motivator for asking this is 
> the document is getting very long. Some of the specialized, 
> advanced functions could be held in separate documents/appendices/etc.
> [page 14, sections 1.4.1 or 1.4.2]
> [current] 1. Given we've defined WSDL for the registry, 
> should we also cite the WSDL v1.1 reference?
> [Section 5.6.14] ReferencesExistException
> 
>     is: "that is is"
>     should be: "that it is"
> 
> [page 51, Section 6.2-future] When we start to think about 
> how the registry may be used in support of actual business 
> processes, the importance of transactionality and state 
> alignment/assurance become more important. Should we consider 
> a constraint that transactionality capabilities may be 
> required if query functions are used under certain 
> circumstances (such as in the case of business content used 
> in a business message for a business transaction)?
> [general-future] As the use of the registry expands to 
> different functional areas, here are some thought areas: For 
> example, the registry may be used to notify a party Buyer 
> (such as a subscriber to a catalog) that a package of 
> application products have been updated with three new 
> components. That update could trigger a service that actually 
> creates a new product catalog sent to an existing customer. 
> In this case, the registry (roughly speaking) serves as a 
> subparty in the process.

I don't believe that anyone has yet responded to this comment...Monica,
these are good thoughts. In terms of transactionality (not state
alighnment), could we consider that covered by RS line 564 (or
thereabouts), which begins "Each registry request is atomic..."?

Regarding state alignment: I believe that this should apply only to
federated operations (assuming you mean state alignment as in the
WS-Choreography sense). If that is true, it would not apply to federated
lifecycle management operations, as these operations are performed
within the home registry (so atomic transactionality would take care of
this). So that would leave object replication and federated queries.
Regarding object replication, I believe Section 9.3.6 handles this
through transactional replication, per the reference on line 3364 to "in
a transactionally consistent manner", if we can consider "in a
transactionally consistent manner" to mean that there was state
alignment.

That leaves federated queries: In section 9.2.2.2 (line 3217) we
reference a "best-attempt" basis, and state that if a member is not
reachable for any reason than it may be skipped. This could be
interpreted as "violating" the notion of state alignment - does anyone
see it that way? If so, are updates necessary?

> Or, even more closely, the registry may be used in an actual 
> business transaction pattern. For example, in an ebBP 
> description, a Buyer queries a Seller via a service (which 
> can be done now with
> OperationMapping) if it has product A with X, Y, Z 
> capabilities. The query could actually be through the 
> registry. The notification may be the response with the 
> relevant data to the Buyer.  I've not actually though this 
> through so be kind in your response. In that case, specific 
> requirements may be levied on the BT pattern (query-response, 
> as such) that it is reliable, secure and received in xx time, 
> and whether SOAP can fulfill that requirement.

I like the idea of adding reliability to the spec in adition to the
security features - should this be done now, or for version 4.0? I
recall Matt mentioned something recently in one of his postings about
OASIS WS-Reliability.

BTW, for those interested in learning more about WS-Reliability, please
see the following overview article that I wrote when the spec was
approved in Nov 2004:

http://www.webservices.org/index.php/ws/content/view/full/47407
"Getting the Message Across: OASIS Web Services Reliability
(WS-Reliability)"

Cheers,
Joe
 
> [page 73, Section 8.1.1.2] On validation of Business 
> Processes, separate business content referenced in business 
> process, from business process instance structrure, from 
> business process instance itself, and the rules a partner 
> assumes that the business process instance itself adheres to 
> (which may be a business agreement, legal constraint, a 
> particular businesses corporate practices, etc). I am 
> uncertain how the registry would make the semantic checks 
> without other tooling. An explanation would be helpful. In 
> lieu of an explanation, here is change
> suggestion:
> 
>     from: Content validation may be used to enforce consistency rules
>     and semantic checks whenever a Business Process is 
> submitted to the
>     registry. This feature may be used by organizations such as
>     UN/CEFACT, OAGi, and RosettaNet.
>     to: Business process instance validation may be used to enforce
>     consistency rules and semantic checks whenever a Business 
> Process is
>     submitted to the registry. This feature may be used by 
> organizations
>     such as UN/CEFACT, OAGi, and RosettaNet.
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/le
> ave_workgroup.php.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]