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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

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


Subject: Scope of TC (was SOA and Shared Semantics / Editors Action Item, et al)


Dear ebSOA:

A number of points strike me, looking back over the posts in the last few
days. I'd like to give my tuppence worth as someone trying to drive
implementation from a management and not a technology perspective...

One of the great attractions of the ebXML - and particularly CCTS, RIM and
BPSS - has been its generic approach to solving a series of related
problems. It has been a breath of fresh air to those, like me, who warned
from early days that XML was not going to solve the world's semantics with
some carefully crafted Schema and tag names. The emphasis on syntax
neutrality in particular has allowed us to concentrate on defining semantics
upstream of any implementation, and yet have a rich, powerful, and reliable
framework to give developers/implementers, whatever the hell they build
with.

Going beyond the SOA hype, I am certainly expecting something similar from
ebSOA, and the more I look at it, the more I realise that there are strong
echoes in the initiative that I have flagged up with the eGov TC and the
European standards body, CEN, that I christened "semantic interoperability
business implementation guidelines" (or SIBIG). Keep a focus on the generic,
high-level, *service-oriented* issues and let the technical specs follow
naturally...

CCTS offers a standardised method to define business semantics. I would
expect ebSOA similarly to offer a standardised approach to:
- identifying semantic interoperability nodes,
- managing connections between these nodes on different systems,
- developing SOAs that promote this.

Managing ontologies, the information sets that sustain them (incl metadata
stores/registries), and other association/assertion mechanisms (tuple
stores, Topic Maps, OWL, etc), would therefore seem to be entirely within
scope.

On the down side, however, I'm not so happy with the emphasis on updating
the *technical* architecture of ebXML: this can only (and will) follow once
the semantics and service level stuff is properly addressed.

To answer Jo's question: If someone did not - for whatever reason -
"subscribe" to the "ebXML way of doing things", the committee's output
*should* IMO be useful whatever: just as CCTS is very valuable even if you
don't buy into the rest (ebMS, BPSS, or UBL, etc).

The value proposition is it's generic adoptability.

Peter Brown

Head of Information Resources Management
European Parliament
++++++++++++++++++++++++++++++++++++
I am currently on sabbatical leave, and affiliation is given for information
purposes only. Any correspondence with my former service or the Parliament
should be addressed to gri@europarl.eu.it

Author of "Information Architecture with XML", published by John Wiley &
Sons, see special offer at: www.XMLbyStealth.net
++++++++++++++++++++++++++++++++++++




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