Re: [regrep] ebXML Registry and Content Management (was Re: [regrep] Meeting agenda and reminder for ebXML Registry telecon December 18th, 2003)

["David RR Webber" <david@drrw.info>]

Zachary,

I believe this is strongly my point - an architecture that is based around
spider diagrams and lines and arrows - while intelletually stimulating -
is almost useless in helping real decision makers figure out why they
need to implement a solution in a particular way.  With web services
its even worse - since its completely ephemiral as noted in my rant
here:

 http://www.ecediinc.com/la/ebxml-mktg@lists.ebxml.org/0039.html

So its not just about ebXML anymore - people need a balanced
view that includes much more - all the components of an SOA.

Of course the BCM TC is providing a neutral set of methods and
tools to enable executives to figure out what they should be insisting
on in requirements - and how to apply rigorous methods to determine
how the business needs are going to be fulfilled.  Redressing the
balance between business experts and technology experts.

So where does that leave ebXML?  I'm strongly in favour of providing
at this stage - not more spider diagrams and reams of theory - but
focused information about real deployments and sets of configurations
that tackle real business problems.   In terms of effort over results -
I believe this is much more what the world needs right now.

Notice also that the ebXML architecture story is becoming
deeply intertwined with web services anyway - as you see from the
two articles on ebXMLforum.com - and therefore the real story is
how does ebXML fit with an SOA.

http://www.ebxmlforum.org/articles/ebFor_20031109.html

http://www.ebxmlforum.org/articles/ebFor_Art_20030708.html

Again the OASIS BCM TC has been addressing these topics
already.

Perhaps what we really want here is a team to address -
"Implementing SOA with ebXML components" - and the
challenge there is - no one size fits all - that is why we
arrived in BCM with our five step methods that enable
people to tailor the technology components to their own
needs.

Thanks, DW.

----- Original Message ----- 
From: "Zachary Alexander" <zack2003@ebtdesign.com>
To: "'Duane Nickull'" <dnickull@adobe.com>; "'Breininger, Kathryn R'"
<kathryn.r.breininger@boeing.com>
Cc: "'Farrukh Najmi'" <Farrukh.Najmi@Sun.COM>; "'Collins, Jeff'"
<jcollins@vignette.com>; "'ebXML Regrep (ebXML Regrep)'"
<regrep@lists.oasis-open.org>
Sent: Saturday, December 20, 2003 9:34 PM
Subject: RE: [regrep] ebXML Registry and Content Management (was Re:
[regrep] Meeting agenda and reminder for ebXML Registry telecon December
18th, 2003)


> Duane,
>
> If the ebXML Architecture team is reconstituted, count me in. I know
> what it's like to start an architecture development effort when the
> standard group that owns the spec doesn't either create a reference
> architecture description or doesn't maintain it. I have used
> Architecture Analysis to maintain transparency in the decision making
> process which leads to better governance in the IT Acquisition process.
> I've killed a lot of expensive and/or bad projects after doing the
> architecture analysis.
>
> As an industry, we are getting killed because of cost over runs due to
> poor planning and undifferentiated me-to-products. Anecdote: Poor up
> front planning can routinely result in 40-80% cost over runs.
>
>
> Zachary Alexander
> The IT Investment Architect
> ebTDesign LLC, (703) 283-4325
> http://www.ebTDesign.com
> http://www.p2peconomy.com
> http://www.itinvestmentvehicle.com
>
>
>
>
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Friday, December 19, 2003 6:27 PM
> To: Breininger, Kathryn R
> Cc: Farrukh Najmi; Collins, Jeff; ebXML Regrep (ebXML Regrep)
> Subject: Re: [regrep] ebXML Registry and Content Management (was Re:
> [regrep] Meeting agenda and reminder for ebXML Registry telecon December
> 18th, 2003)
>
> To add to Kathryn's email, I must also express the architectural
> viewpoint from ebXML.
>
> The ebXML Technical Architecture team had a responsibility to map the
> user requirements to an architecture that could be implemented using
> several components.  The Service Oriented architecture uses the ebXML
> Registry as one of its' components to facilitate a set of functional
> requirements described in normative sections of the ebXML TA v 1.04.
>  ebXML Registry currently meets all of those functional requirements
> plus has started adding in functionality that is needed, yet was never
> specified within the TA 1.04.  This is a byproduct of two items:
>
> 1. The ebXML Technical Architecture v 1.0 is out of date and needs to be
>
> revised and be reconciled with advances made by all ebXML groups and
> also needs to include certain web service standards (WSDL and SOAP as
> well as optionally UDDI - the latter being a point for discussion).
>
> 2. Advances in implementors requirements that are not part of the ebXML
> Requirements document v 1.06.  As time changes, so do the requirements
> of users.  The ebXMl Requirements document could be updated too.
>
> To rectify this, I am proposing a new ebXML Technical Architecture team
> be established and a new revision of the architecture be written.  I
> would also like to suggest that a revision to the ebXML Requirements
> document be done to update that documents.
>
> I would also like to see the following for ebXML as a whole:
>
> 1. Coordinated meetings between all ebXML and relevant WS branded TC's
> 2. Tighter control over versioning of the specifications and a
> architecture/versioning scheme that can be implemented.  (I am thinking
> that if everyone aims at making version 3.0 the gold / real copy, we can
>
> achieve this based on lessons learned).
> 3. Integration of Web services standards formally within ebXML (Registry
>
> already has WSDL and SOAP, ebXML MS has SOAP but we can also use UDDI
> optionally to facilitate dynamic discovery of other web service within
> an ebXML architecture instance.)
> 4. Implementation profiles and an implementation guide published
> (perhaps by IIC?).
> 5. Inclusion of UBL as a start payload format for ebXML.  One thing that
>
> many implementors found annoying was the lack of a specific payload.
>  While we cannot constrain ebXMl to use only UBL, it may be good to have
>
> it as a starting point.
> 6. Someone to set up and maintain a production registry as a Registry
> Zero, to start the federation.
> 7. World peace
> (The latter one I personally added since I am already asking for so much
>
> and I figured it was best to ask for everything in one go)
>
> I'm sure this will invoke some other opinions.  I wouldn't mind moving
> this thread to the ebXML Dev list under the title "ebXML Future"
>
> Duane Nickull
> Breininger, Kathryn R wrote:
>
> >I would like to insert a brief clarification here.  In a couple of the
> >recent e-mails in this string there have been references to ebXML
> >Registry specs as Content Management Standards.  As I stated in our
> >telecon yesterday, I believe our intention (ebXML Registry TC) is that
> >the ebXML Registry specs and standards support and enable content
> >management, not that the ebXML Registry specs become the definitive
> >Content Management System standards.  Generally speaking, a Content
> >Management System includes authoring, check-in/check-out, workflow,
> >versioning, etc.  An ebXML Registry has broader application in its
> >enabling of ebusiness, federation features, classification support,
> >interoperation with other OASIS and ebXML standards, and additional
> >services, most of which can compliment a CMS.
> >
> >We need to bear in mind our charter
> >http://www.oasis-open.org/committees/regrep/charter.php and how
> >functionality we add affects our interoperability as well as the
> >requirements for core components, BP, CPPA, etc.  There are areas of
> >overlap it is true: an ebXML Registry manages metadata about the
> >registered objects, and a CMS manages metadata as well.  However, an
> >ebXML Registry has a larger and slightly different scope and as such it
> >can support and enable content management, but is not a standard
> >developed specifically for CMS.
> >
> >Kathryn
> >
> >-----Original Message-----
> >From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> >Sent: Thursday, December 18, 2003 12:34 PM
> >To: Collins, Jeff
> >Cc: ebXML Regrep (ebXML Regrep)
> >Subject: [regrep] ebXML Registry and Content Management (was Re:
> >[regrep] Meeting agenda and reminder for ebXML Registry telecon
> December
> >18th, 2003)
> >
> >
> >Collins, Jeff wrote:
> >
> >
> >
> >>Ok, so i guess i'll follow up with a few more questions:
> >>
> >>- What industry vendors have agreed to support this spec so far?
> >>
> >>
> >>
> >I assume by "support" you mean implementors of the ebXML registry (as
> >opposed to users of ebXML registry)?
> >Until recently I used to say that ebXML Registry spec is weak on vendor
>
> >adoption and strong on end-user adoption.
> >This changed last month when Adobe acquired Yellow Dragon Software to
> >leverage their ebXML Registry within their eForms products. Peter,
> Duane
> >
> >and Matt represent Adobe on our TC and can give more details.
> >
> >Sun has an implementation in open source (see my signature).
> >
> >In addition there are several other implementations listed on our TC
> >page:
> >
> >http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
> >
> >Finally, there are those that we keep discovering. At XML 2003 I
> >discovered that the
> >Australian company MSI ( http://www.msi.com.au ) had an ebXMl Registry
> >implementation.
> >
> >But where we are doing even better is in actual end-user adoption and
> >deployment. Again see the first link in my signature for a small
> >example.
> >
> >
> >
> >>- Has there been any consideration of Portal Server integration use
> >>cases with the CM API?
> >>
> >>
> >>
> >As you know Portals and CM have a close relationship with portals being
>
> >the front end and ECM systems being the backend.
> >
> >Naturally, I see a close relationship between WSRP as a portal standard
>
> >and ebXML Registry as CM standard.
> >Recognizing that, we have recently formed a liaison with WSRP TC where
> >Joe Chiusano and I work in the Publish/Bind/Discover SC under Alan
> Kropp
> >
> >of Vignette. Based on initial discussion we feel that ebXMl Registry
> >brings a strong value to WSRP and portals.
> >
> >
> >
> >>- What would a CM vendor use ebXML for today if it doesn't support
> >>versioning as defined by the CM products on the market today?  Would
> it
> >>
> >>
> >
> >
> >
> >>be read only?
> >>
> >>
> >>
> >ebXML Registry supports tracking of versions today. It allows for
> >implementation specific extensions to support the missing check
> >in/checkout type functions. Until we support full versioning this
> aspect
> >
> >of CM would not be interoperable. Some interop is better than none in
> >the interim.
> >
> >
> >
> >>- How does ebXML interoperate with WebDAV?
> >>
> >>
> >>
> >ebXML Registry defines an abstract API in UML and then defines
> normative
> >
> >bindings to SOAP, HTML and ebXML Messaging. a binding to WebDav has not
>
> >been defined yet. If we see a demand for it we could consider it.
> >
> >
> >
> >>Overall, are there plans for reference ECM applications?
> >>
> >>
> >>
> >The reference application is the one that was defined in the ebXML
> >Architecture as an eBusiness artifacts registry for CPP/A, BPSS and CC.
>
> >Another reference application is Web Service publish/discovery. These
> >applications are deployed at Sun and other places. I would love to see
> a
> >
> >WSRP publish/bind/discover use case as a reference application.
> >
> >The killer application for ebXML Registry in my opinion is eForms.
> >
> >
> >
> >>Plans for application support or integration from Portal Vendors or
> >>Apache in something like Cocoon?
> >>
> >>
> >>
> >The freebXML Registry project under freebxml.org is where a grassroots
> >group of vendor and user companies are working together on ebXML
> >Registry.
> >
> >
> >
> >>How would a vendor achieve benefit from committing resources to this
> >>specification?
> >>
> >>
> >>
> >>
> >Like any other standards work, a vendor should only get involved if
> they
> >
> >feel the standard is important to their future. By getting involved
> they
> >
> >make sure that their customer/product needs are met within the standard
>
> >and that they are not stuck with a lot of baggage that they do not wish
>
> >to implement in their products.
> >
> >
> >
>
> -- 
> Senior Standards Strategist
> Adobe Systems, Inc.
> http://www.adobe.com
>
>
>
>
> 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/leave_workgr
> oup.php.
>
>
>
> 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/leave_workgroup.php.
>
>