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] | [Elist Home]


Subject: RE: [regrep] Describing ebXML Reg/Rep - observations from Santa Fe


I beg to disagree. Web services is one of the fastest growing technologies
ever. All recent surveys I've seen show that 70-80% of companies are now at
least experimenting with Web services, 15-20% have production services
deployed today, and >50% plan to deploy production services in 2003.
Although lots of folks talk about security being a concern, it's completely
trivial to use SSL-based security, which addresses the basic security
requirements for most people. WSS addresses application-level security,
which gives you much more security control, albeit it at a development and
complexity cost. I'd guess that most SOAP implementations will provide
integrated support for WSS by 2004, but lack of WSS support won't discourage
people from using Web services today.

Choreography is a pretty nasty can of worms at the moment. Too many
proposals, and no standards (yet). But I don't believe that lack of
choreography standards are interfering with Web services adoption.

I think RegRep's biggest issue is that it's so closely associated with
ebXML, and when most people think of Web services, they think of SOAP, not
ebXML. Likewise, when they think of a Web services registry, they think of
UDDI.

Even so, your basic point is valid -- people don't need a registry until
they reach critical mass of services. UDDI is definitely lagging behind SOAP
and WSDL. But it's being much more widely adopted for private use than ebXML
RegRep.

Anne

> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, January 30, 2003 9:26 AM
> To: Matthew MacKenzie
> Cc: Max Voskob; Still Erik R; OASIS regrep
> Subject: Re: [regrep] Describing ebXML Reg/Rep - observations from Santa
> Fe
>
>
> Regarding adoption:  I also believe part of the issue is the current
> lack of adoption of Web services, due to issues such as security.  A
> *loose* analogy might be that when the travel industry is suffering, the
> luggage makers suffer.
>
> I predict that with initiatives such as WS-Security and the new W3C Web
> Services Choreography Working Group underway, we will see in the coming
> years a spike in the adoption and use of Web services, which will lead
> to a increase in usage of registries not only for the storage and
> maintenance of Web service information, but also the artifacts (e.g.
> schemas) that describe/validate the Web service payload information, as
> well as the entities (CPP/A) that support the collaboration.
>
> Joe
>
> Matthew MacKenzie wrote:
> >
> > Max,
> >
> > You make some great points, but I think that a lot of our problem is a
> > general lack of people willing to roll up their sleeves and get all of
> > the work done.  Compare this group's roll call to UDDI's, and remember
> > that UDDI's scope is much more limited than ours.  UDDI has big
> > marketing bucks behind it (read: MSFT & IBM), supplying a very good
> > reason for people to step up and get it done.
> >
> > What did we learn from Betamax and VHS?  Beta was better technically,
> > but VHS machines are what you are replacing with DVD players today.  We
> > need to spend some serious time on evangelizing regrep to the developer
> > and vendor community, IMHO.
> >
> > Matt
> >
> > On Wednesday, Jan 29, 2003, at 18:47 America/Vancouver, Max Voskob
> > wrote:
> >
> > > Hello dear RegRep TC!
> > >
> > > Sorry for annoying you with my opinions, but here I just can't stay
> > > silent
> > > :)
> > >
> > > First of all, I support Erik in his observations.
> > > Second, why do u want everyone to be smart? I don't want to be smart -
> > > I
> > > want things around me to be smart, easy to operate and understand.
> > > Confused
> > > where I'm coming from? Read this book
> > > http://www.amazon.com/exec/obidos/tg/detail/-/0465067107/
> > > qid=1043893177/sr=1
> > > -1/ref=sr_1_1/102-5762810-0332102?v=glance&s=books
> > >
> > > To be closer to the point, I have to say that if one wants his
> > > creation to
> > > be used (adopted?) then one has to make it simple to use and
> > > understand.
> > > About a year ago I had an assignment to choose a Registry/Repository
> > > for one
> > > of our clients. That ultimately lead me to this TC. But think how an
> > > average
> > > busy IT specialist makes his research! I see a name "XML Registry". Do
> > > u
> > > expect me to go thru a 300 page manual to understand what it is and if
> > > it
> > > can work with any other object types? The average fellow would hardly
> > > move
> > > further than the executive summary.
> > >
> > > We had a very useful feedback from an outsider. Don't make him feel
> > > ashamed
> > > that he didn't read the spec - he doesn't have to!
> > >
> > > If I can't set up time for my alarm clock it's not my fault. It is a
> > > designers fault. They didn't make it easy to operate. Same thing
> > > applies
> > > here.
> > >
> > > If someone says that your creation is hard to use/understand then I'd
> > > think
> > > twice and seek another opinion to make sure that that someone is an
> > > exception, not a rule, unless I don't care.
> > >
> > > Cheers,
> > > Max Voskob
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> > > To: "Still Erik R" <erik.r.still@boeing.com>
> > > Cc: "OASIS regrep" <regrep@lists.oasis-open.org>
> > > Sent: Thursday, January 30, 2003 2:35 PM
> > > Subject: Re: [regrep] Describing ebXML Reg/Rep - observations from
> > > Santa Fe
> > >
> > >
> > >> Erik,
> > >>
> > >> Thank you for your feedback (you must be a colleague of Kathyrn's).
> > >> Some comments:
> > >>
> > >> #1 below:
> > >> <Excerpt>
> > >> It seemed helpful to clarify that an ebXML Registry does not
> > >> necessarily
> > >> use XML in its implementation, and that its contents do not
> need to be
> > >> restricted to XML artifacts.
> > >> </Excerpt>
> > >>
> > >>> From the RIM spec:
> > >>
> > >> "The registry provides a stable store where information
> submitted by a
> > >> Submitting Organization is made persistent. Such information is used
> > >> to
> > >> facilitate ebXML-based Business to Business (B2B) partnerships and
> > >> transactions. Submitted content may be XML schema and documents,
> > >> process
> > >> descriptions, ebXML Core Components, context descriptions,
> UML models,
> > >> information about parties and even software components."
> > >>
> > >> This is made quite clear in the spec - are you suggesting
> then that we
> > >> emphasize it whenever we present the Registry specification in
> > >> presentations?  If this was not emphasized at the conference, I can
> > >> definitely understand as the *main focus* of the Registry
> architecture
> > >> is, after all, XML.
> > >>
> > >> #2 below:
> > >> <Excerpt>
> > >> 2.  Some people seemed to have the impression that the RIM was
> > >> essentially a software package that could be simply installed.  It
> > >> seems
> > >> important to be clear that the RIM is a model and a standard
> - a level
> > >> of abstraction above any actual implementation of the standard.
> > >> </Excerpt>
> > >>
> > >> I don't doubt even for a picosecond your impression of the attendees'
> > >> reaction, but it does surprise me given that the "M" in "RIM" should
> > >> really speak for itself (i.e. it is a "M"odel).  Would you be willing
> > >> to
> > >> elaborate as to why you feel that people had this very incorrect
> > >> impression?
> > >>
> > >> Thanks,
> > >> Joe
> > >>
> > >> "Still, Erik R" wrote:
> > >>>
> > >>> Having attended the Open Metadata Registries conference in Santa Fe,
> > >>> I
> > > have some observations regarding
> > >>> the presentation and description of ebXML Reg/Rep and RIM that might
> > > have some bearing on the understanding
> > >>> and acceptance of these standards and specifications among the
> > >>> broader
> > > metadata community:
> > >>>
> > >>> 1.  For the people not familiar with an ebXML Registry, there seemed
> > >>> to
> > > be some confusion about the relationship
> > >>> between XML and the Registry.  It seemed helpful to clarify that an
> > > ebXML Registry does not necessarily
> > >>> use XML in its implementation, and that its contents do not need to
> > >>> be
> > > restricted to XML artifacts.  The ebXML
> > >>> label suggests things about the Registry that are not true, and may
> > > cause some people to dismiss an ebXML
> > >>> Registry because they are "interested in metadata, but not XML".  In
> > > presenting the ebXML Registry spec,
> > >>> it is important to explain what ebXML is, and it's relation to the
> > >>> spec.
> > >>>
> > >>> 2.  Some people seemed to have the impression that the RIM was
> > > essentially a software package that
> > >>> could be simply installed.  It seems important to be clear that the
> > >>> RIM
> > > is a model and a standard - a level of
> > >>> abstraction above any actual implementation of the standard.
> > >>>
> > >>> I expect that it is not necessary to reiterate such points within
> > >>> this
> > > community.  But when presenting the
> > >>> ebXML Reg/Rep to others, making these issues clear up front
> will go a
> > > long way in reducing confusion and
> > >>> gaining understanding and acceptance.
> > >>>
> > >>>         - Erik
> > >>>
> > >>> Erik Still
> > >>> erik.r.still@boeing.com
> > >>> CENTRAL Registry
> > >>> Boeing Library Services
> > >>>
> > >>> ----------------------------------------------------------------
> > >>> To subscribe or unsubscribe from this elist use the subscription
> > >>> manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC