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

David,

Where I work, Architecture is pretty concrete.  Developers actually implement the architecture that is given to them, and if the architecture is not implementable, the architects have to fix it before implementation can start.  All this means in the ebXML context is that our quality level has to be higher than the CEFACT process permitted/supported.  

The CEFACT idea of Architecture was in line with CEFACT's overall approach -- Top Down from Confused User's Perspective (TD-CUP).  In my view, that sort of top down focus should end at the requirements gathering phase, then the technical architects go to work.  This parallels successful professional software development patterns:

user->product management->architect->implementer->user

CEFACT promoted an architecture that was driven by the consumer, and unfortunately the architecture was only consumable by the consumer and not the implementer.  This is a failing of the CEFACT process and orientation, not of the architecture concept.

-Matt

On 20-Dec-03, at 3:34 PM, David RR Webber wrote:

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 -----

From: Matthew MacKenzie 

To: David RR Webber 

Cc: Breininger, Kathryn R; Collins, Jeff ;Duane Nickull ;Farrukh Najmi ;ebXML Regrep (ebXML Regrep) 

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" <>

To: "Breininger, Kathryn R" <>

Cc: "Farrukh Najmi" <>; "Collins, Jeff"

<>; "ebXML Regrep (ebXML Regrep)"

<>

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:]

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.

___________________________

Matthew MacKenzie

Senior Architect

Intelligent Documents Business Unit

Adobe Systems Canada Inc.

http://www.adobe.com/

506 869.0175