1. Can you give us a list of pointers to these XML documents? If it is
the XML security specs, I believe that is well-defined, at least at
some useful version level from 2001. Is there ongoing work, though? Who
can tell us?
2. Performance must be considered in detail. If, at the end, the group
consensus is to go with XML, it must be an informed decision, with
the performance impact clearly understood. I assert that web caches will
be the baseline systems, and that is the only logical place to evaluate
performance.
3. We need to have all references to SOAP capabilities backed up by
references to a spec. Could someone provide pointers to the necessary
documents?
4. Are there IPR issues wrt to SOAP?
5. I need more detail about how web services can help with OPES. I
understand that there are directories, query/response protocols,
semantics for defining entries in the directories, etc. But can
someone elaborate to the next level and describe how OPES will use
them?
6. It looks like the original website that we used during the BOF stage
has been replaced. It would be really nice to have the contents of that
site restored to someplace convenient, because there was some excellent
information there. Markus, Abbie, have you got the content from the machine
Intel used for us?
More inline below:
Abbie Barbir, in replying to Hilarie Orman's messages:
> How can we keep track of this W3C work-in-progress from the
> IETF vantage point? I'm not a member of W3C, and I cannot
> judge the maturity of their drafts, the likelihood of
> standardization of any of the documents. Can you and others
> promise to serve as liasons, keeping us apprised of what's
> going on? Or perhaps there's already someone who does this
> for the XML security work, like Don Eastlake.
I acn do what I can, but a lot of the SOAP security work is done in OASIS
and they have a open process (I beilive), where u can get access to all the
doc.
>
> > I know off hand that performance issues will be used
> aginst adopting
> > SOAP. However, keep in mind that performance is only one
> factor and
> > it can be argued that with continous improvments in CPU speed and
> > Hardware acceleration, this will not (or should not) be a major
> > issue.
>
> I'm not objecting to examining performance vs. ease-of-use,
> but it is important to keep the whole picture in mind. If a
> single CPU with no special hardware enhancements can keep a 2
> Gbps line busy, carefully balancing CPU cycles and I/O, then
> you have to be very careful about adding extra per packet
> processing that multiplies the CPU cycles by a factor of 1000
> - this would mean that an organization would need many more
> CPU's to do the same job. So let's be very specific when we
> discuss performance and acceleration - the numbers are
> important because they determine the cost of the deployed systems.
>
--- abbie
Before u can do that, we need to know what we are comapring SOAP to.
I bet you, that whatever protocol will be developed there will be a need to
define a structured way of invoking RPC, which will involve some form of XML
or metadata.
Not an RPC, and not XML. Yes, some minimal metadata, but probably not on
every packet.
First, OPES must be compared to not-OPES.
My performance goal is to have OPES impose only a few instructions per
packet for packets which do not get OPES enhancements. For those that
do get OPES processing, my goal is to be close to line speed out-and-back
to the callout servers. Of course, this doubles the I/O load; that being
nearly unavoidable, unless there's a second bus, perhaps I'd accept a doubling
of the CPU load.
Even if you ICAP, you still need to know how to find services and how to
invoke them, which means some way must be developed to do that. Otherwise,
you will be binding the OPES architecture to a group of very limitted
services, and you will be forcing the service provider to get hooked on one
the services of one vendor.
> > There is a lot of work that is being done now on SOAP
> security that
> > can be very usefull to OPES.
>
> How can we know what that very useful work is?
>
---- abbie
SOAP security involves header extensions that allow for
Authorization/Authentication information to be exchaged (including info for
ppp> XML encryption/Sig)
There are also provision for Policy exchange, Privacy exchange, Trust and
routing.
In SOAP, you can use routing information to state which SOAP Actor can be
involved in the data path etc. This help OPES since, since it can define
which callout server can be used and it can also define what policy to use
etc.. (including privacy info...)
We have to have the spec and an expert in implementation in order
order to appreciate this.
> > For OPES to be usefull, I think it should be able to interoperate
> > with web services. At the end of the day, OPES provide a
> service to
> > the data provider/consumer application.
>
> Can you tell us what it means to interoperate with web
> services? I'm not against it, but I've got only the vaguest
> notion of what it might mean for OPES.
>
---- ABBIE
WHat I mean here, is that the service provider that deploy OPES, should be
able to offer services as they become avilable and as long as they make good
financial sence. Since off hand you do not know what a killer APP is, the
OPES platform should be extendale, meaning, the OPES provider should be able
to offer a service at a minimal cost. SO if SOAP ids the callout protocol,
and the new service ids a web service, implementiung it in OPES is quick and
strighat fwd. Otherwise, u need to customise the service at leat at the OPES
end.
WOrst case secnario, the actual provider of the service need to TALK OPES.
What does that mean?
> > I know that SOAP has been looked at before by OPES. As a
> start, do we
> > have a pointer on the previous work, if yes can someone
> please advice
> > where we can get it.
>
> My memory of this is that Lee Rafalow was a strong advocate
> of looking at SOAP, but there was no work beyond that
> advocacy. Perhaps others have done work since then, but have
> not reported it to OPES because we were concentrating only on
> the initial documents. We need to spread the word that we
> are now in a new WG phase and it is safe to come back to the
> mailing list.
>
> Hilarie
I have access to that info, but i thought that there was a talk about
comparing SOAP, ICAP etc.. that was presented in one of the BOFs meetings.
Don't remember it, but the original website has been consumed.
abbie
>