Matt,
I think we are seeing the same thing here - much
more real world - centric.
I'm not sure the word "Architecture" in the title
sends the right message.
People are overdosed on all that - theory side -
stuff - what we need is
healthy pragmatism and showing what can be built
and works.
Something like "ebXML Solution Configuration" would
be my preference.
DW.
p.s. French
perhaps - "Solution et XML avec ebXML (SEXAE) - sorry,
I have no idea what came over me then!?! Too
much architecture is
clearly not good for you...
----- Original Message -----
Sent: Saturday, December 20, 2003 9:16
AM
Subject: Re: [regrep] ebXML Registry and
Content Management (was Re: [regrep] Meeting agenda and reminder for ebXML
Registry telecon December 18th, 2003)
David,
I think an ebXML Architecture could be useful if
its goal is to define best practices, deployment patterns and general guidance
for technical committees. It would be quite helpful if an architecture group
could maintain the high level view of our ecosystem, so that interoperability
between specifications remains a key goal. United we stand, divided we fall,
right?
-Matt
On Dec 19, 2003, at 9:58 PM, David RR Webber
wrote:
Duane,
You raise some interesting points - and I agree
that the old ebXML architecture document did its job for 1.0 - but I'm
not sure that we necessarily need a new ebXML Architecture specification
and team.
Instead - I'm more interested in focusing on best-practices
and proven solution configurations - as we just saw with the CDC pilot
for XML2003.
And here in lies the rub - can anyone person/team create
an authoritative "ebXML Architecture?" Instead - ebXML has advanced to
where it can be used in multiple roles and deployments - and outgrown the
original limited (design time only) thinking - to become a fully fledged
set of technology components - where the key thing is the proven
integration and interoperability.
That's why I'm see at this point
- its much more useful for people to know how to use a suite of OASIS
specifications together - like CDC, like AutoTech, and many more real
implementations today are proving.
Perhaps the IIC or the TAB are
other possible venues - where such a sub-team can be initiated - to
manage and Q&A such solution sets - and then publish them as case
studies?
I think that would be much more productive at this stage -
for adopters and implementers of ebXML based solutions.
Thanks,
DW.
----- Original Message ----- From: "Duane Nickull"
<dnickull@adobe.com> To: "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: Friday, December
19, 2003 6:26 PM 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_workgroup.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.
___________________________/bigger>/color> Matthew
MacKenzie /bigger>Senior
Architect Intelligent Documents Business Unit Adobe Systems Canada
Inc. http://www.adobe.com/ 506
869.0175/smaller>/color>
|