Eric Newcomer: Notes 17 years experience in
Enterprise Computing
... to solve "portability problem" of applications
... Has many consequences and benefits for business and society
... More economic benefits will come from standardization in the
Enterprise
... If Web Services are not the answer, then what is?
... Seven years ago when we began the WS discussion
... Henrik Nielsen suggested that WS were an extension of HTTP
... Today we see discussion divides discussion from HTTP
... What has caused all these arguments?
... A lack of understanding of differing points of view?
... Maybe there are technical shortcomings;
... Maybe an assumption of certain starting points, design centers;
... Maybe innovators' dilemma
... Add multiple requirements
... and ignore that these things were designed from HTTP to allow it to
scale
... Others accommodate HTTP based transactions
... Topics we'd like to dig into today
... We encourage a wide range of views and submissions
... And we're pleased by this
... Hope the discussion does not get bogged down by the SOAP
... disagreements
... But let's not do fruitless discussions
... References CORBA
... Stay away from matters of pure opinion
... Let's work toward positive conclusions
... Not find fault with the past or assign blame
... We are where we are; let's move forward
... Some of problem is that some disputes are rooted in commercial
disagreements
... Hearts and minds of JAVA and .net
... trying to please one development audience or another
... versus thinking of technology in its own right
... Could be a process vs. technology issue
... Way to solve disputes
... vs. commercial interests
... HTTP vs Web Services environments
... Some of large Web sites...
... Do vendors listen to requirements of the large vendors?
<Benjamin Moreland> Service interfaces should be technology/language independent.
<Skip Snow> Ben, We need bindings to some technology dependent languages, and even platforms. We need this in order to bind to our existing systems.
<Benjamin Moreland> Skip, From our perspective, the abstract portion of the WSDL should have no technology dependencies, only the impl part.
<Skip Snow> allow systems to connect better with one another. Sometimes using the web, sometimes using UDP, and or TCP and other protocols.
Eric Newcomer: Perhaps large part of IT spend
is based on IT systems pre-Web
... features that are excluded from HTTP
... cannot throw things out and start from scratch
... World's economy is impacted by lack of software standards for the
Enterprise
... Let's explore all the alternatives
... before coming to this conclusion
... SABRE system still uses TPF
... VISA uses this as well
... Why are these systems still in use?
... Special purpose systems to process large volumes of transactions
... Trend toward general purpose technologies exacerbates problem
... Windows clustering...
... Things will need to be done in a sensible, progressive way
... Doesn't have to be either or
... I'm in favor of a hybrid approach
... Web can be the Web
... Hide existing systems
... Allow systems to connect better to the Web
... I've been exploring issue for 18 months
... Conclusion that hybrid may be best way forward; look forward to
discussions
... over next two days
... More we can all contribute to solution of these problems, the better
Eric Newcomer: W3C POV as Web of Documents as a
success
... Web of Services is not a success
... Spaghetti diagram
... Companies invest in stovepipe applications
... whatever technology it ran on
... Not so much an architectural approach
... Each dept. given its own money
... When I think of Web of Services,
<Paul Downey> diagram was in common use, seven years ago
Eric Newcomer: I think of program to program
communication
... and the applications inside the Enterprise
... Is it specs, products, specs and products, design assumptions,
... methodology
... How I think about the answer: diagram
... Worked on initiative to standardize software; working with Japanese
factories
... That time when Japan was highly successful with manufacturing, but not
yet software
... Had laboratory such as Bell Labs
... They wanted to create specs to assure portability of applications
... Digital got involved
... Their vision was any application service should run on any underlying
platform
... They wanted to invest in multiple applications and take advantage of
platform capabilities
... and not worry about platform specific differences
... in a uniform way
... and connect any application to any other application in a common way
... We did demo at Telecom '95 in Geneva
... This was done on procedures
... Then EJBs came out
... Industry was changing
... still innovating
... It was too soon, or too early
... CORBA, JAVA, J2E
... are other examples
... Perhaps industry has matured today
... XML independence
... Would WSDL fit standard interface?
... Think about multiple things to bridge to each other
... It's possible multiple standards are the solution
... Celcius and Fahrenheit for example
... Is service abstraction the right approach?
... Controversy of COBAL at one point
... Purpose of software is to allow humans to interact with computers
... Abstraction is right way to go
... Greater point is whether it makes it easier for people to interact with
systems
<Glen Daniels> {agreement} that {symbol representing abstraction} is the way to go
Eric Newcomer: Should be easy for the user
... rather than the consumer user of service
... We could use WSDL...great abstraction layer
... It can do the job
... You can adapt it for multiple applications in the Enterprise
... Tied to shared persistent data
... WS specifications add Enterprise qualities back in
... I know we'll have other views...
... Capability is there to understand, represent these systems for quality of
service
... Enterprise software productivity
... No industrial methods for development
... because we don't have program standards that work across platforms and
technologies
... Competition drives the market
... JAVA and .net for example
... Solution through Web Services provides benefit
... Valid question is whether W3C is the right place for this
... W3C has a better chance to influence this area
... I know OASIS may not be happy for me to say this...but I could be
wrong
... Original era of Web Service, 2001
... We did work with large companies
... One company was thinking of using WS inside and outside the Enterprise
... Flowing XML documents across the Enterprise
... Why not do both
... SOAP, WSDL, XML across the Enterprise, Internet and Intranet
... We spent time on this direction
... Seemed to make sense
... But this idea seems to have fallen down
... Seem to gain adoption inside the Enterprise
... Let's look at hybrid
... This is also controversial within W3C
... because it brings up Web Architecture questions; one or two
... To have a hybrid
... where Web can be the Web based on REST principles
... evolve to Web 2.0, AJAX, let it grow
... Inside Enterprise is solution based on WSDL and SOAP
... I tend to think so
... To get to this point, what should we do?
... More clearly separate Web and Services architecture for the Enterprise
... Identify conversion or touch points that makes sense
... Discussion about best practices
... REST advocates...users may not understand benefits because it hasn't been
explained
... because suppliers want to continue their solutions
... the innovators' dilemma
... Can we also define multiprotocol data formats?
... Rather than propose a single data format?
... Can we abstract, layer them
... Mark Little and I worked on this
... made it a separate mechanism
... RESTful interface so it could live on the Web
<Paul Downey> why do you need to standardize such things?
Eric Newcomer: Can this provide this persistent
data sharing mechanism?
... What about SOAP server?
... alongside a Web Server
... instead of going through a single mechanism
... Graphic
... Can we have field in HTTP header
... Bridge into Enterprise environment
... Can we dereference the WS context structure
... and transform into SOAP message
... use multiple protocols
... just a suggestions
... Summary
... Existing systems will not go away
... TPF...bunker in Arizona...afraid of losing it
... Too hard to replace those things
... What millions of dollars did it cost to create?
... Need standards for Enterprise software to get productivity gains
... Too expensive to recreate Enterprise systems that pre-date the Web
... involve a lot of custom code
... PR about eBay's architecture
... spent millions of dollars to build custom code
... Presents a barrier to entry for anyone who wants to compete
... Even with HTTP based solution, it's expensive
... Abstractions are not just technology
... Also human interactions
... Design new systems with REST principles
... Compare REST and HTTP
... Explore custom interfaces in this context
... Eric invites questions and comments
Paul Downey: We've heard an interesting history of IT
... I'd like to understand what new things the W3C should do in this space
... much of this seems to be happening anyway
... Can't we build these bridges for ourselves using existing technologies?
Eric Newcomer: You mean everyone does their own things?
Paul Downey: We have the Web which is
standardized
... existing services are disparate, often by design
Eric Newcomer: You can do it today and custom
code it, but what's the cost of it?
... We do work with IONA; complaints is how long it takes to get new services
to market
... and the costs
Ken Laskey: The thrill of doing custom applications...you've done it enough
Eric Newcomer: Yes, I've done it; look for economic benefit
Skip Snow: We use SOAP to exchange with
business partners
... We need to have reliable secure transactions is a matter of course for
us
... We see that more robust protocol stack in SOAP vs. a more ad-hoc
architecture is significant to us
... Also need to have bindings into legacy languages and other systems such
as proprietary message oriented middlewares
... I won't take up whether W3C takes this up; hopefully they will
Eric Newcomer: Thanks Skip for compliment
... Get requirements from customer side is also key objective of this
Workshop
Mark Nottingham: Lots of questions I could
ask
... Why do we think this is a good fit for W3C?
... .What about the culture and the context
... vs. IETF, other consortia
... Why W3C to talk about Enterprise software?
Eric Newcomer: Refers to slide...is W3C more
academic rather than industry-focused?
... W3C has a good policy for IP
... good process for spec development, excellent staff and industry
reputation
... could argue not as strong as a few years ago,
... but it's in the lead in these categories; this is why I think it's a good
place
Nicholas Gall: Leaving binding of Web open and
unstandardized doesn't seem like a bad idea to me
... We let different technology vendors do this
... Perhaps it's premature; we don't know the way to map legacy systems onto
Web architecture
Eric Newcomer: That's why I raised question of
how to do binding between the two
... Why do we need standards?
... Our customers say big issue is connecting systems to the Web; takes time,
effort
... If someone is going to solve it, it should be standardized; perhaps it's
too early
Nicholas Gall: On one slide you show a number
of legacy systems
... All of those are now Web-enabled
... we didn't need standards to bind the Web to those
... Maybe the same is true of Services
... Why for Services?
Skip Snow: We do it, but extremely painfully
... We refuse to do many projects due to prohibitive costs
... Our rate of change and innovation and serve our customers is seriously
inhibited
... Getting System A to B is difficult
... We need it to allow us to innovate more rapidly
Shriram Revankar: Our experience, we are using
Semantic Web technologies for day to day production offerings
... SW may be one of ways to solve Web Services problems
Eric Newcomer: Yes, I should not have left this
out
... Others have made that suggestion before
last comment
Noah Mendelsohn: What's difficult...is to frame
these issues
... I will be talking tomorrow
... Getting at same resource through a single access point; an HTTP proxy
... From my POV, the Web was not designed to primarily integrate a bunch of
new content for REST
... Content that works for that works on Web
... Integrates services...because of value of having things in a single
network
... Behind slide is a question...
... When is it valuable to have a resource,
... when you access from a browser,
... or when you need other services; I don't want to know late in the game
... How do you name resources?
... If people are happy with separate architectures, then that's a different
discussion
<Glen Daniels> +1 to Noah
Eric Newcomer: yes, that's a fundamental question
Ken Laskey: Whether there is something to
standardize is a key question
... and what additional experience is needed
Salim Semy: Commercial sector has to address,
not just government
... We're looking for partnership
... Think of SOAs
... See focus on data center environments
<Benjamin Carlyle> It would seem that standardizing a bridge requires a "HTTP" WSDL to be defined for use by the back end SOAP system. This would line up with the kinds of things Westinghouse Rail Systems Australia have been doing in adding HTTP/REST support. The bridge problem doesn't go away, but is solved at the endpoint rather than in the bridge itself.
Salim Semy: Lots of bandwidth, storage,
connectivity to networks
... What about disadvantages...battlefield, disasters
... Issues of connectivity
... Latency may be high
... Other issues are localized resources
... May have minimal or no storage capability
... How to move data closer to them?
... Look at heterogeneous devices...laptops, PDAs
... interoperability for devices to share data
... Questions: How can SOAs improve quality of service
... What considerations to support these disadvantaged users
... Not just a government problem
... For example, parcel delivery services
... Challenges in delivering packages thousands of miles away
... service centers, transport vehicles, delivery personnel
... Person may not have connectivity to network
... ANother example is healthcare EMTs
... How do you support collaboration in near real-time fashion
... when they are disadvantaged in one of more ways?
... DOD...constrained environments; pilot ejects in unknown territory; how to
get communications to them?
... Some risk of being discovered
... Big impact for getting it wrong
... Bigger scale and less controlled
... DOD thought of as a network of enterprises
... Lots to coordinate
... MITRE is addressing these issues
... Basic approach is to collect use cases as to what it means to be
disadvantaged
... Use a common vocabulary and framework; common classes
... align classes with appropriate design patterns
... What are implementation choices you can make
... Validate in experimentation venues
... that emulates tactical environment
... how to support services and make them available to disadvantaged users
... Graphic
... Small set of issues to consider:
... Network
... Bandwidth...minimal as you use mobile
... Latency
... Storage
... Traffic patterns; way data is exchanged, frequency
... Periodic data exchange
... Minimal to no exchange with disadvantaged users
... We identified four classes
... Align with design decisions and how to support user
... Use metrics as way to identify support
... Align tools, technologies, and architectures
... For example, caching, data synchronization
... Compression technology
... Rich Internet applications
... Offline Web Apps
... How do you synchronize across a Web App that's disconnected for a length
of time
... DOD needs to leverage commercial solutions
<Steve Vinoski> Yes Benjamin, pushing integration into the endpoint is generally superior to driving it all through a centralized integrator. IONA's web services integration products, for example, have precisely this design center. The key question here, though, is whether the W3C is the right place to define standards for such endpoint integration. I think it is, because it falls into the category of web integration.
Salim Semy: How can these be applied in the DOD
space?
... Recommendations to W3C...we're early in our thought process
... Evolving thoughts
... Look at protocols to support synchronization to support cached
browsers
... So when they are reconnected, backend processes are streamlined
... AJAX for example
... Markup languages that can be used in off-line mode
... Support synch. across host of users
... Standards to embed metadata
... critical...need smart algorithms to disseminate data
... Don't want to traverse through lots of data
... So metadata is a big push at DOD; embed in Web pages
... Architectures to formalize role of proxy servers
... Subscription based information
... Look for feedback, partnership in commercial sector for best ways to
proceed
Ken invites comments
Chris Ferris: Go back to chart eight
... What is it that you think is missing?
... I look at this list
... There are de-facto standards; IETF, W3C that address just about
everything in this list
... Is it about standards or how they are applied?
... There is proxy caching available
... You can take that to the edge device, it's a matter of doing it
... My Akamai colleague may speak to this...
... You have caching at the edge device; just not being exploited
... It's not a lack of standards or design and architecture
Salim Semy: Supporting off-line Web
applications
... Off-line Web browsing...what DOD wants is guidance to support
interoperability across the applications
... There may be some standards; we'll look into it
... We're looking for ops to leverage what has been done
David Orchard: Ask about protocols to
systematize
... Are you asking for more caching for SOAP messages;
... or are you doing HTTP in human readable formats and finding that way HTTP
is built isn't sufficient?
... What do you mean by caching various things?
Salim Semy: First point; looking at how SOAP
can support users with real time tech needs
... How to bring those services closer to edge environments
... while maintain real time data need
David Orchard: Follow-up question
... Is it a mixed document and update mode
... Two ways to look
... Document vs. RPC
... do updates, operations
... and do classic cache and read
... no unified infrastructure for those modes at the edge
Skip Snow: In terms of caching there is some
degree of support for whether things are cached within HTTP
... beyond that I don't know of any standardized manner
... What's significant to us is bullet on caching, routing
... Significant deficiency in WS architecture in addressing multitiered
aspects of architecture
... How to act as proxies
... To degree that some protocols...reliabilty...almost disable proxies from
acting in a functional matter
... an area of grave concern to us
... I like DOD's request on this
Salim Semy: Proxies are essential for disadvantaged users
Benjamin Moreland: This is big problem for
Insurance industry as well
... For example in disasters such as Hurricane Katrina
... our agents needed access to information
... I second this area of work; difficult to do customized solutions
Mark Nottingham: Listening to discussion, it
feels like deja vue
... Web caching community...was in a bubble at one point...said we need to
standardize and federate networks
... A lot of people were working on this; but it all came to naught
... There were requirements around functionalities.
... Vendors wanted standardization, but couldn't come to agreement on
functionality
... do widespread protocols right; do it in the Enterprise
... ICP, ...Cache Digest, there are a lot of protocols
... After Prague meeting, I'll put out a new protocol, there is existing
stuff in caching
<Glen Daniels> when functional intermediaries are involved, source routing as poor man's orchestration is a highly scalable and quite functional technique, tho...
Shriram Revankar: Web of Services for
Enterprise Applications
... I'd like to address question of is W3C best place?
... I don't know, I don't care
... If any organ. can solve my problem, then it's the right forum
... Looking at our business
... Not building different infrastructures...doesn't make us money
... We have 60 different vendor offerings embedded
... I have to make things production ready 24/7
... Well defined, understood interoperability is a big advantage for us
... I was surprised by Yahoo! comments; like to learn more...
... I'd like to see primary areas for Web standardization
... Hear about best practices
... We want to see our space with four parameters
... Documents, Data, Control, Web Services
... To set context
... Documents: we have very high end complex software/hardware solutions that
cater to B2C scenarios
... Much of our offerings center on manufacturing of electronic or paper
documents
... Control is even more critical
... True in our standard large scale printers and in our Enterprise
services
... Offerings cater to today's knowledge workers
... Interoperability between Enterprise services and vendor offerings is
critical
... In this case, data...how do we manage it
... Leverage W3C standards to deal with this
... We have our own infrastructure for Web Services
... If W3C did better in each of these areas, more of our services would
leverage the Web
... Web and Documents
... Web has had profound impact on way we deal with documents today
... Makes document management lifecycle difficult
... Views need to be managed differently
... As a document company, lifecycle management of document is more
challenging
... To do more of our services doing Web, if there were best practices,
... that are agreed to, we could leverage the stack to manage more of the
document lifecycle
... I have no easy way to manage the state of a document
... I would like to see W3C venture into Web standards in small perimeters
... for better management of document lifecycle
... Web and Data
... I participated in XML Schema Working Group
... We had interesting conversations between "docuheads" and "dataheads"
... Data management continues to be complex, less interoperable in spite of
name spaces
... One of advantages of Namespaces and Schema,
... I could define schema for my data
... in a very platform independent way
... but that increased risk of proliferation of name spaces and overlapping
schemas
... We do believe there may be standards and best practices; I'd like to hear
about them
... Walk through history when this was perceived as issue
... Define a name space authority
... So any of data or interfaces would be exposed across organ.
... Define XML schemas
... Not have namespaces proliferate; use a methodical way
... We tried creating that authority
... We got buy-in from IT and business groups
... to go through namespace process
... We didn't go further with it
... Difficulty was
... the developer community didn't have enough easy tools
... Hard to figure out how much overlap
... I would like to hear about best practices
... If there are plans to make transformation; management of namespaces
easier
... Introduce Dan, Xerox colleague
Daniel McCue: Add some concerns we have
... in customer and internal environments
... Control issue
... A lot of deployments involve dozens of components from diff. vendors to
produce workflow and automate work process
... WS Choreography, BPL
... We struggle; need for service composition
... Hard to compose higher level services from existing workflows
... For example, prepress for production printing
... then they produce other elements for post press; they need to compose
those
... We need another model
... Assert that perhaps we need a merged standard
... Service to a customer; or customer offers service,
... It's not a single API call
... has some defined sequence
... Define conversations, not just point to point interactions
... We use WS internally and externally
... WS are not well standardized in how they are developed
... Not an overall architecture; silos of development
... It's related to our inability to express these constructs
... the data and document issues that Shriram mentioned
... We'd like to see a stronger service model
... rather than point to point message exchange; higher levels of
interaction
... A services stack that defines services above level of WSDL
... that defines service types, quality of services
... reliability across that stack
... Employ more complex services through custom integration
David Booth: I was intrigued by comment about
namespace management
... It sounds like a problem of managing vocabularies
... W3C has done work there in RDF and Semantic Web technology
Shriram Revankar: yes, as the complexity of WS
management increases, we should leverage SW
... When a new interface comes in, when is it new?
... We hope to better manage diverse groups of software
... Wanted to leverage tools to define the interfaces themselves
... We hoped to achieve it by defining namespaces
David Booth: My talk tomorrow attempts to
address problem of lock step versioning and problem of vocabularies
... and use of RDF in service oriented architecture
Chris Ferris: problem of data dictionaries is
an ever present problem
... since we started communicating
... Seems that socialization is the best way to solve this
... The Web 2.0 approach is solving problems
... that were once deemed insurmountable
... Contrast this with the "data dictionary" approach
<Benjamin Carlyle> Just stop the technology getting in the way, and let the people sort the rest out. If they can't, they can't. If they can, they can.
Chris Ferris: So people don't agree and add
other terms
... Get this through lack of knowledge
... or, intransigence
... Always comes about; vocabulary explosion
... Web 2.0 is bringing together communities that didn't know they existed
... These lighter weight technologies
... are helping forward things, connect the dots
Shriram Revankar: I mostly agree with your
comments
... But I do believe in the newer technologies
... the "not exactly" part...we can develop some tools
Ken Laskey: I'd like to see...example of 40page
and 60 page schemas
... How do you build modular vocabularies?
... If we ID a small set of names
... if we need to expand, it's easier to map to an existing one
... What does it mean to build modular vocabularies
... Which brings up issue of versioning
... Over time, vocabularies evolve
... 20 years from now, if we have vocab. captured,
... this would be useful
... So how to do this?
... Map, modularize schemas?
Paul Downey: general theme from discussion
... Have things be more controlled, control vocabularies; I hate this!
... The Web is loose, and that's a good thing
... Vocabularies are hard; getting agreements, even within a single company is hard
<Benjamin Carlyle> XML seems to be better at evolving vocabulary and modular vocabulary than RDF at the moment.
Paul Downey: A while back we tried to merge several existing billing systems ... We ended up with a "super billing system" of a union, rather than an intersection of everyone's features
<Mark Nottingham> Benjamin: I disagree.
Paul Downey: the question is: how do we manage this disjoint between a controlled environment and the loose world of the Web?
Shriram Revankar: Controlling is not the right
way
... Previous tools we had to makes sure two divisions could use same
tools...
... I'm looking for...
... freedom to work together and be different where we want to be
... learn where to do then when needed
Paul Downey: Need more than technology, you need social change
Ken Laskey: You have organizations that wanted
control
... but as they get into new tech, go into "lock down' mode
... Some things cannot be locked down
Jonathan Marsh: Enterprise is a social
organization, Web 2.0 social paradigms are in direct conflict with top-down
policy enforcement
... I wonder about the long-term
Daniel McCue: transforming social interaction is what's required; hear more from David tomorrow
Jonathan Marsh: At MS we ended up with a simple
solution, a Web site with namespaces
... Wiki is what we need rather than a committee
... Find what you have out there
Ken Laskey: So we need a statement out of this workshop...."It's not our problem, it's yours."
Anthony Bradley: I spent time in DOD
... Some best practice...I shiver when you talk about social
... The more social, the longer it takes, the less chance of success
... Need people who can collectively represent the 800 pound gorilla
... but then you get so many different opinions; for example, get Air Force
and Army to agree on a core set and share information
... Then others will work their way into it
... Bringing everyone together at once was too hard
Glen Daniels: I don't think there is a boil the
ocean solution
... There are always going to be overlapping contexts where different
approaches apply
... We need how to plumb it, not look for single solution; keep aware of
what's on in the environment
Skip Snow: Add some requirements context
... We have business cases for top-down and bottom-up policy
... An infrastructure to negotiate policy...framework has to be robust
... to be extended if necessary
... so that proprietary negotiation engines can do decision making
... No ability in most large enterprises to have every stakeholder make a
decision regarding policy
... Rather policy tooling
... so it can be a human process when it's an anomaly
... Tooling has not offered enterprise ways to meet cultural challenge
... to tell people who don't want to reuse that they have no choice
... Primitive tooling...is not economically efficient
... Force cultural changes within enterprises
<Paul Downey> automated policy negotiation === wiki
Skip Snow: to ensure agility
Chris Ferris: Problems are a social process; both of them; cultural aspects of organ.
<Paul Downey> I'm in total agreement with Chris Ferris
Chris Ferris: Look at old SABRE system for
American Airlines
... it ensured you a seat reservation
... It controlled transaction processing
... It's cheaper to give someone $100 to overbook; not worth effort to
control it too tightly
... Yes, there may be certain circumstances where everyone uses same
vocabulary
... That may need to be top down
... You'll get some pushback from those who disagree
... Other times it may not be all that important depending upon the level of
interaction
... A matter of understanding what you need to do and a matter of risk
Ken Laskey: We'll take break until 11:15am
<Benjamin Carlyle> I know this isn't something that can be effectively covered over IRC, but I just want to jump back to the XML vs RDF point. Namespace-free or minimal-namespace XML is good at being able to deal with core vocabulary and extensions without introducing namespace-related document complexity. You can have your core vocabulary with special extensions that are understood in various contexts. A single namespace for core and extensions also acts as a conflict point
<Benjamin Carlyle> In short, I would rather be dealing with atom+xml in the service-to-service interoperability space than atom+rdf+anything, and I suspect that it is easier to form communities around atom+xml development and extension than around atom+rdf development and extension.
<Mark Nottingham> I agree that standard vocabularies are always preferable to frameworks for building arbitrary languages...
Balaji Prasad: we agree with the premise of the
workshop
... information centric business - about transfer of risks
... need to gather lots of information about individuals
... highly regulated business
... lots of different partners, agents, reinsurance, etc
... not a technical problem - but there may be some standard issues
... if the W3C want's to go after the enterprise, they need to understand
higher levels in the "stack"
... rules are important to us
... as is the user interface, XForms useful in the insurance space
... discussion of complex diagram
... beyond technical issues, we have scenarios where push-back is the norm
... converse is also true, the tangle prevents innovation
... lines of business used to be independent, which led to the tangle
... BPM, rules are now seen as foundation blocks in the center of the
business
... but that means the old has to co-exist with the new
... rationalization work needs to be done, and much of that is bottom up
... SOA may allow us to carve the business up, but that hasn't happened
yet
... impedance mismatch between business innovation and technical
innovation
... allocation issues, who pays for what
... this may not be the right body to solve these problems:
... SOA has been bottom up, technology isn't the issue, but planning,
governance and organizational issues
Benjamin Moreland: shows slide, integration of
backends via SEMCI orchestration/SOAP/UDDI SOAP via XML Security Appl to
ACORD exchanged outside
... WSM figures large
... much of this isn't IP (intellectual property) based, or core business
... rules allows us to make an advantage over our competitors providing
agility
... SOA is a philosophy within Enterprise Architecture, they're just tools.
In 5 years we'll be talking about the systems, not the technologies
... we have event rules, syntax rules conditional rules relational rules
business rules
... rules for schema, data, and underwriting exposed as SOAP services
... driving towards consistency for our rules engines, currently disparate
... we use BPEL as well as rules in code
... dynamic data capture, only asking questions based upon previous answers -
rules acting as a screen flow
... why use one form in the UI and another in the processing model?
... XForms, XSLT, XML
... but also using JCP, etc we'd like to see a tighter integration
... diagramClient, Presentation, Service, Resource
Nicholas Gall: liked your comment on the low
level plumbing not giving differentiation
... not much sharing on a peer-to-peer basis.
... what about having commercial enterprises open up the komono a little more
and publish their architectures, there might not be a need to go to a
standards body
Benjamin Moreland: difficult to participate in
an open organization, much easier behind closed doors - we can't mention
vendors, but can at least discuss our architecture
... not had a lot of reception for talking with peers
Jacques Durand: the term "rules" can be very
deceptive, the only common thing is a notion of contract, but behind that on
the processing side they can be very different
... do you want to expose these as a contract to external parties?
Benjamin Moreland: I would say yes, look at the contract, but we don't want to be locked to a Hartford specific implementation. A shared taxonomy may help. XForms and XPath may provide a common basis. We'd like a common standard, akin to BPEL.
Kurt Stam: a session concept common to CORBA,
Transactions HTTP Servers MOM message groups
... HTTP sessions at the heart of how the Web works, HTTP provides cookies
... opaque, owned by the server
... Web services business functions modeled as networked services,
repurposable
... focus on exchange of self describing XML business documents
... reuse protocols of the Web
... two models: WS-Addressing and WS-Context
... WS-Addressing - all done in the header, session info in the EPR, need to
dig inside EPR to understand session model
... shows an example EPR
... shows ObjectKey directly appearing in a SOAP header (following EPR
explosion)
... WS-Context scoping for arbitrary units of work context is a UID (URI) for
correlation
... can do anything in an activity, and within an activity you can have more
than one context
... context is a first class element, contains URI to identify a resource
Unique activity ID and a timeout
... can dynamically add to your context as it flows
... can propagate context in SOAP header you can add a mustUndersand flag
... lots of examples of use (list of WS-* specs)
... implications: loosely coupled systems - WS-Addressing is not scalable or
fault tolerant
... Do not expose implementation details - we think WS-Addressing does so
... no current W3C TC [sic] in this domain
... insufficient vendor backing
Paul Downey: are there plans to make this a W3C member submission?
Eric Newcomer: it's soon to become an OASIS standard. we'd like to see the spec recognized by the W3C
Paul Downey: didn't understand why this is being presented here - seemed like a lot of overlap with WS-Addressing, why would I use it if it has little adoption and competes with W3C specs?
Eric Newcomer: handles state management in a better way (scribe fails to capture eric's response)
<Rich Salz> Are you supposed to use the EPR every time you contact a service, or only the 'first time'?
David Orchard: TAG working on a finding for state management.
It's a difficult problem, but each spec wants to handle state in a specific
way, very little reuse
... state is usually about performance, and tuned to the spec in play
<Rich Salz> Why not define SetCookie and Cookie SOAP headers?
<Philippe Le Hégaret> rich, how are cookies different from reference parameters?
<Rich Salz> Reference param's don't have anything like SetCookie
<David Orchard> rich, one of the problems with a setCookie header is who is setting the state? You need some kind of ref for the thing to echo the state back.
<Rich Salz> Dave, I don't disagree, I was just pointing out what's missing from EPR refparams
Eric Newcomer: securitycontext isn't usually handled differently to a transaction context
David Orchard: picks up on the addressing not being scalable or fault tolerant. I really disagree. BEA WLS is an extremely scalable and fault tolerant implementation of WS-Addressing. ergo is possible
David Orchard: you have to have back up from state and id and have to keep them in sync
Kurt Stam: and if the power goes out?
David Orchard: we've had state survive catastrophes such as 911
Nicholas Gall: WS-Addressing is no more or less stateful, point I want to make, I thought it would be a Kumbya [sp?] it works for SOAP and REST, so surprised at lack of adoption
Eric Newcomer: yes, I listened to Mark Baker during WS-Addressing discussions :)
Nicholas Gall: yes it can do both, but
unfortunately isn't seen that way
... Simple Queuing service for Amazon is a similar approach - SOAP WS-*
community could do more of this work to close the gap between messaging and
resource ways
Glen Daniels: found the last few minutes of discussion useful. State management is really important. This is something the workshop should examine. Cookies, WS-Addressing, WS-Context can be used in both good RESTful ways, and bad ways. World is crying out for best practices. That's something the W3C could be thinking about
Skip Snow: hearing that things are mature
enough if only goofy users knew how to use them.
... important to understand requirements, WS-Arch was a stab in the dark.
Despite what the tools offer, they're not good enough.
Robert Freund: would it have helped at all if RefPs were called "cookies"?
Ken Laskey: sounds like a lunch topic, pudding even
[lunch break]
Kinga Dziembowski: Currently work with Gestalt
LLC — primarily work with defense and energy markets
... ARCES Project: models are developed for analysis
... POSITION: service discovery in commercial or std. organization is not
enough
... Discovery: make something available and visible when needed
... Dry Cleaner Sotry: << Use Case>> I would like to get my new
clothes dry cleaned — I need one day service with delivery — good price,
quality-highly available— etc.
... Given the requirements of the service — How do I go about finding a
service??
... Open Yellow pages — make a sequence of calls — one is not there,
other does one and not other requirements —- so on and on... so I am
totally frustrated by now
... So I call a <<clearing house>> type services and request for
service for discovering the appropriate dry cleaning service
... They take the request in and give four dry-cleaning services that meet
your need — they also gave ranking of the services based on
customer-satisfaction
... Then I wanted to check if I could be informed if any of these services
are going to have problem fulfilling my request —- the <<clearing
house>> said yes to that too!
... Then I had additional request for getting a similar clearing house
service for another location — and the answer was yes
... Then the speaker summarized this length scenario in the form of generic
discovery service
Kinga Dziembowski: slide 10: services discovery
appears to be under control
... mostly concerned with the service type
... slide 11: everyone has seen this slide
... publish/discover/bind
... stable systems... once deployed, stay operational
... another assumption, consumer runs in stable environment
<Eric Newcomer> but do current discovery mechanisms meet all consumer requirements?
Kinga Dziembowski: slide 12: think that these assumptions are not always valid
<Eric Newcomer> i think is the question
Kinga Dziembowski: one such environment is us
military
... ... much more dynamic
... slide 13:
... core: services assumed to be operational 7x24
... edge: everything is pretty much unpredictable
... consumer and provider are subject to changes
... needs to adapt to the environment
... slide 14:
... even in the scenario I gave, could not satisfy my discovery needs using
the phone book
... triangle for services discovery not adequate for discovery in dynamic
environment
... service instances are my concern
... slide 15:
... some use cases
... mobile clients... they connect and reconnect and need to painlessly find
the services they need
... printer example
... mobile providers move from point to point in the network
... changing population
... slide 16:
... move visualization of mobile client
... when you change from one jurisdiction to reconfigure to talk to same
provider but in different environment
... slide 18:
... initial discovery pattern
... discovery fronts metadata repository
... services publish to repository and update as they change
... dynamic, not static
... extension to existing design-time discovery
... slide 19:
... updated picture looks different
... would like to add discovery engine and recognition that there are two
separate registries
... logical separation
... two types of metadata
... separate service type from service instance metadata
... something that consumer consults before
... slide 20:
... service type established at design time
... can be uniquely identified
... consists of interface definition (WSDL), semantic information, also
metadata (context)
... some static parts
... established at design time
... never change
... another set that is established post-design time but also doesn't change
much
... third part is dynamic metadata
... slide 21
... service instance
... running instance of service defined by type
... implementation
... something with which consumer actually interacts
... slide 22:
... everything is beautiful
... need something that has consistent interface that can always be
queried
... slide 23: summary
... require extra runtime instance discovery
... instance has dynamic context
... all to be part of the service definition
... need to make sure that an instance has presence
... conclusion: if this problem is not solved at the architecture and
standards level, the main benefit of SOA (interoperability) will be
compromised
Glen Daniels: where do you see actionable items
for w3c
... do you find the other side of the spectrum (e.g. web services and "the
web"
... how do you see moving forward with this
Kinga Dziembowski: if we agree that something
like discoverable services as a concept... that this could be defined as part
of the definition
... by contact, I have obligation to implement
... will help every one to find me
Glen Daniels: in the context of wsdl?
Kinga Dziembowski: can be one, yes
... if you want to make sense of this, you need higher level of
aggregation
... in this case, talking about a bank being able to be discovered
Michael Versace: do you see an extension beyond service discovery that can negotiate on the part of the consumer?
Kinga Dziembowski: can be provider from one
side and consumer of another
... describes a broker model...
Benjamin Moreland: assume that the
responsibility will be on the provider
... need to be sure that the provider will meet its SLA
... if looking for the lowest cost and fastest performing, maybe can see
that
Kinga Dziembowski: if things are done properly,
shouldn't matter... same concepts
... you trust, you don't need to negotiate
... when you talk about SLA think you are still in design mode
Benjamin Moreland: when UDDI first came out,
the vision was you could ask for specific provider meeting some criteria
... but I am talking about a contracted provider
Ken Laskey: this is a pain point I am dealing
with
... service description goes far beyond wsdl
... if web accessible, ok. but we need to agree on what is a services
description
Jonathan Marsh: right now the greatest
challenge is not building more layers, but getting these implemented in a
much more seamless manner than what we have today
... want to focus on what w3c can do in short term... work on
interoperability problem
... slide 1:
... about half way up the adoption curve
... a lot finishing this year
... slide 2 intersect with the hype curve
... hype curve has dropped off a lot
... may represent a backlash because of the interop issues
... slide 3 blends in the interop curve
<Eric Newcomer> but then WS-I "took over" from SOAPBuilders
Jonathan Marsh: have been working on this
within and without standards orgs
... gives examples such as interop workshops, ws-i
... need to improve interoperability
... stick to ws-i basic profile
... basically soap and wsdl
... next chart
... new "Vista" profile emerging
... soap1.2, MTOM, addressing, security, rm, wsdl, ws-policy
... this is turning out to be the de-facto profile
... how do we get to the same level of confidence w/r/t interop with this new
profile as we have with the ws-i basic profile
... challenge; building interop
... XML paradigm
... REC-> test suites, deployment issues, authority for disputes, official
test suite, ongoing maintenance
... eventually oasis group recognized that a more centralized location for
the test suite would be beneficial
... almost all the errata that the XML Core WG came from implementer
experience
... W3C WS-Core WG
... more and more of these specs start to intersect with wsdl
... ongoing interop events
... cross specification interop
... often the same folk
... maybe we can get the critical mass to take over maintenance
... think we made a mistake in wsdl, stopped having quarterly meetings..
slowed down progress
... can we bring policy and wsdl experts together to make it an easier
task
... think it would be valuable (from our perspective as vendor) to have
quarterly events that would promote interop
Eric Newcomer: think you are hosting an interop event
Jonathan Marsh: yes, we are hosting an event
Glen Daniels: do you see this group as being
able to manage a sort of nexus for other specs that aren't w3c specs?
... would that group be a place where documents could be generated on best
practices?
Jonathan Marsh: ideally, yes be good to have a
place where you could do more comprehensive tests
... politically, this might be a challenge
... xml core did publish some notes even in conjunction with other groups
... did things like xinclude, xml linking, c14n (but that went back and forth
between security
Shriram Revankar: think this is a great idea
... the basic premise relates to the stack
... with regards to soap and wsdl, not such a big argument
... who is going to define this stack
Jonathan Marsh: specifically chose not to
discuss profiles
... in the end, ws-i bp served its purpose, but was painful to achieve
... our goal is to interop with vista
Hugo Haas: think this is a good idea
... however, express some skepticism as to writing things like best
practices
... points to databinding
... four people in a room doing good wrk but getting very little attention
... think it is right direction
... hope that there is more participation than the work going on around data
binding
Jonathan Marsh: think about ways to provide
incentives
... whole lot of interop stuff going on... just no center of gravity
Chris Ferris: This is a good idea, but I have to question.... Profile aside, the hardest thing in WS-I is getting the members to step up to the plate to develop test suites or scenarios or get together 3 times/year to do this.
Jonathan Marsh: all the excitable people drifted off
Noah Mendelsohn: big believer in putting specs
in maintenance mode
... think that the w3c process is not well suited to this
... back off from proposal to have all of this in a single group
... or, we have to run this group in a way that we can get the right people
together to sort out issues... may need rotating group to address these
bugs
Philippe Le Hégaret: we have started
discussion about this in the Web Services CG
... we looked into patent policy issues
Jonathan Marsh: but in cg, we have not discussed interop testing and such
Philippe Le Hégaret: that is true
Noah Mendelsohn: this seems to be ws-i BP2.0
... you might be implicitly saying that w3c should be doing the profile work,
which makes a fair amount of sense
Jonathan Marsh: not talking about a new profile
David Orchard: how is this different?
Jonathan Marsh: this is just like xml core
David Orchard: one of the things that the ws-i bpwg did was effectively errata
Jonathan Marsh: ws-i bp said don't do this, that and the other thing
David Orchard: probably get to a better interop
framework
... what I saw was more reuse of interop frameworks
... common testing framework
Eric Newcomer: thanks jonathan for keeping
presentation short so we can have discussion
... we will have more discussion
Mark Nottingham: experience of moving from a
vendor to a consumer has been incredibly eye opening experience
... just seems completely removed from the problems that developers are
facing on a daily basis
... the databinding problems that paul's wg is trying to address...very
discouraging to see it get so little attention from vendors
... from a standards maintenance perspective, this makes sense
... from an end-user perspective... not sure it really addresses the
issues
Chris Ferris: You mentioned that you were not
proposing profiles, but you know that these specs
... were developed with compromises made, meaning that there are parts of
these specs that nobody
... will ever implement. Which means that it is important to identify
which
... parts will or will not be implemented and tested together
Nicholas Gall: think that a ws-i like profile is absolutely necessary
Skip Snow: as chair of ws-i rgwg that
governance of ws-i must be changed
... vendors should not compromise on things that they have no intention to
implement
Ken Laskey: noah mentioned as to whether something could be done with the w3c process, tell the AB and we will make it happen
Michael Versace: been with FSTC for 12 years
... fstc been involved in web technologies for a number of years
... FSML used to mark up payment instrument
... pilot program run with US Treasure (e-check)
... number of large banks, Sun Micro and MSFT...
... large corporations bank with large banks... ran pilot based on wsdl and
soap extensions for the discovery and transmission into a wsrp portal
... slide 2: background
... focus on driving interoperability
... most recently, FSTC has issued a paper to the w3c
Skip Snow: within http and https there is good
sense of interop, very pleased with that
... slide 4: other protocols and needs
... paper was contributed by and approved by a bunch of really important
companies...
... how do we map the legacy system implementations to the new environment...
dealing with broadcast and reliability and deal with gaps in traditional
messaging systems
Michael Versace: within financial services, we
are seeing this used inside firewalls
... when dealing outside the enterprise, we have different set of
requirements
... being able to address negotiation of security requirements, etc. needs to
be addressed
... common requirements, but not all the time
... establish these is a fundamental requirement
... slide 5:
... have relationships with a bunch of other three and four (and even five)
letter acronym groups
Skip Snow: need to bridge wire level
protocols... bridge between http and jms, etc.
... we think that the work that the ws-arch group did needs to go a level
down
... need the same levels of services as you get from traditional messaging
middleware
... slide 7
... need ws-rm and ws-tx
... establish bindings to ftp
... establish reference arch
... establish policy languages for functional and non-functional
capabilities
Michael Versace: these qos policy languages are
all a function of risk
... slide 8:
Skip Snow: need establish behavior for
intermediaries
... ensure backward compatibility
... compatibility between ws-* and rest
... establish audits with compliance with teeth
... interoperability certification
Michael Versace: we hold these soa telcons
monthly
... calendar on the web site
... slide 9: contacts
... what is the process to engage this dialog?
Skip Snow: obviously, FSTC wants to stay involved
Eric Newcomer: thanks
Jonathan Marsh: one question about teeth in
technical audit?
... is that really an expansion of 3rd party certification?
Skip Snow: big teeth come with our purse
... if we have test suites we can point to as procurement rfc requirement...
then what occurs is that when a vendor solution that claims conformance is
not conformant, we can raise a bug
... without the provable interop test that establishes that compliance, it
then falls to judgement
... we need test suites that can ensure compliance
Jonathan Marsh: so there would be a 3rd party
that does certification but you would recommend to your members to use
products that pass that suite?
... and you would make sure that products actually passed them?
Skip Snow: what fstc is asking for is that the ws-* community create these benchmarks such that we can procure against that benchmark
Michael Versace: that is the first step, to create this compliance validation standard
Ken Laskey: we keep coming back to whether the
w3c should do certification... question is always who will pay... if it has
teeth, then if you are saying the product doesn't pass, want to know where
the $$$ is coming from when we get sued
... ws-i does this, they give you a test suite and nothing more
Michael Versace: what can or should be validated?
Ken Laskey: some of these test cases are
connected
... the part that has me (and others on AB) cringing is the certification
with teeth part
<Rich Salz> A common way to do the with-teeth is to allow/withhold some desirable TM'd logo
Paul Downey: when BT procures something, we can
require WS-I BP compliance, and if it is not, we are the ones that have the
teeth
... the problem when you put up a service that is WS-I BP compliant and a
customer using another vendor's tool doesn't interoperate with it. Who has the teeth then? Who gets bitten?
Michael Versace: is there a group that can mature these specs towards such test suites
Paul Downey: The hard part is that BT customers use tools from their own vendors, and we have no control over that. When their software doesn't work with our software, that's the tricky part, and where test suites and standards come into play.
Glen Daniels: soapbuilders, we had social
commitment from all the vendors
... as part of the process, we put up public endpoints that would always be
there
... that you could test against
... vendors should keep their stuff up and tested
Mark Nottingham: to previous discussion, if you
want tests, you are coming to the wrong place... if the vendors don't show
up, then no one will listen
... another point, to ensure compatibility between rest and ws-*
<Paul Downey> reference implementations and conformance test suites comes with maturity and we ain't there yet
Mark Nottingham: have a problem with that... as
someone who is developing rest services... these are just getting these off
the ground... one of the benefits is that they are simple
... almost see the two as fundamentally incompatible
... problem with putting them in the same track is the problem
Skip Snow: we are not calling for a rest/ws-* integration, we are calling for well defined bridges between the two
<Paul Downey> there is a well defined bridge between the Web and Web services: http://www.w3.org/TR/webarch/
Philippe Le Hégaret: we talked about best
practices for ws-* but you cannot expect vendors to participate in a wg
because they think that they can talk to their customers themselves
... they don't want fingers pointing back to them because they are not
compliant
... for databinding, this would not be possible without BT
Paul Downey: <blushes>
David Orchard: agree with the first point about
the need for definition for intermediary processing
... we have largely ignored intermediaries
... problem is that it gets very complicated very quickly, but this is an
obvious next step
... problem I have is with the rest and ws-* stack is that they are coming
from very different areas
Skip Snow: the issue of intermediary has come up in customer situations
Ken Laskey: we have dealt with testing and
certification... would like to back up
... what does it mean to test it?
... dod will build a system and then test the heck out of it
... what does it mean to test a service? what is your test environment,
runtime? all these are questions that we need to answer
<Paul Downey> who tests the testers?
<Benjamin Carlyle> My main points of the day:
What I really want are higher-level semantics: Application-level. WS-* interoperability does me no good. I want application-level interoperability. REST offers me that interoperability by defining appropriate document types only, but HTTP needs:
Does HTTP also need MOM features to avoid the inexorable duplication of its architecture on the WS-* side of the fence?
Eric Newcomer: points from today's discussion
David Booth: Process question, should we defer discussion on one Web or Two to tomorrow
David Orchard: Suggest put Noah on spot...do
TAG presentation now
... Have 45 minutes of extra discussion tomorrow
The REST vs. SOAP is crucial subject for longer discussion
Eric Newcomer: What does group think?
Skip Snow: Propose solution on FTP bindings
Eric Newcomer: Maybe we wait
Noah Mendelsohn: Nothing in presentation that
isn't in the white paper
... I'm fine either way
<Paul Downey> skip should write a spec for his FTP binding and submit it to the W3C
Noah Mendelsohn: Discussion would be tomorrow
Benjamin Carlyle: Suggests clearing issues today
Chris Ferris: I don't know about easy...
... I think most interesting discussion today, that also strikes a chord, is
interoperability testing
... or a maintenance working group
... WS Core
... What it would do
... Question is would people step up?
Glen Daniels: Is it people in this room, or the companies they represent?
Ken Laskey: Service description beyond WSDL?
David Orchard: Discussion around description
languages, or WADL
... Given a use case, working on a REST based service, they may want a
machine readable description language
... a standard like that
... No such thing currently
... yes, this is one Web or two; one Web description language or two
... A Web description language would be useful
... How useful is it really? We've been getting by with it so far
... What limits REST is the lack of scalability
... At Enterprise level...
... people may want more metadata than that
... one use case from Enterprise perspective
... we make recommendation for straight up REST description language
... that works, how does it relate to WSDL 2.0?
... or should WSDL 2.0 be looked at knowing that work would be going on
... what are the use cases there?
... a straight up REST description language would be useful
Ken Laskey: people I deal with, assume there is
a service interface
... and a specific definition
... and everything else involved in describing service
... final policy agreements...[Ken lists several things]
<Chris Ferris> isn't what Ken is describing what SAWSDL is intended to address?
Ken Laskey: Do others see that?
Eric Newcomer: suggestion for discussion
... Focus on description, extensions for now
Ken Laskey: What is a service description?
Eric Newcomer: one of our customers asked us to
validate their descriptions in Word
... I've seen evidence of that
Jonathan Marsh: I'd like to approach extensions
to description in a different way
... may not be right for REST based services
... what I read, is more like WSDL 2.0 extensions
... quality of service, not what you necessarily need to interact with
service
... additional metadata to tell me if I want to interact
... WSDL 2.0 evolving; core is frozen for foreseeable future
... we'll extend it with bindings
... some additional quality service stuff
Nicholas Gall: Agree we need it
... if it's informally described, good to go; doing 20 years
... at that level of documentation
... most clients spend 80% of time, in the XML payload itself
... getting the customer document right
... that info. arch. is where they spend time
... and the nuances of moving it back and forth
... ok to leave to documentation
Ken Laskey: So is the question that once you
have the service, you know what you're trying to do, and you just want to use
it well;
... or, do we want a world where service discovery is a big part?
Nicholas Gall: ...depository
Eric Newcomer: We look at simple Web pages; now requirements for discovery
Paul Downey: One of things I hear
... where is description for WS
... asking for some obligation for me to honor some type of contract
... people don't trust Web Forms
... WSDL does over Web Form, is indication of what you may get in response
... you do like to know what you'll get back in return before you get it
... application state
... doesn't stick in brain
... hard to build machines around that
Paul Downey: Web Description vs Form; you could
build machinery around that
... Mark's WADL language
Marc Hadley: I haven't prepared
... I'd like to address first point
... look at WSDL, it's very function oriented; you specify methods and that's
your interface
... I wanted to invert that [URIs]
... invert WSDL into diff. description language onto what's on Web vs. an
IDL
... Other thing is that Web Forms get you some of the way
... they get you some input to a resource
... you cannot select what type of output to expect; like some SVG, XML, or a
Gif
... they don't offer enough information
... not all info. that's available for who's publishing a resource
... also pull out inter-relationships to resources
... like that link will have a link to this resource; so you build tooling to
parse those things
... progress from one representation to another
... I've written code that works with WADL
Ken Laskey: what are your plans for WADL?
Marc Hadley: A good question
... Sun has plans to release various codes that will have WADL supporting
... hoping to point; stay tuned
... WADL the language is at a fairly stable place
... once more people start using it; let's get some development experience
before doing anything else to it
Peter Lacey: Add two things
... to pre WADL discussion
... issue of Feature +1
... if it's more than interface, you'll use WS-Policy
... capture breadth of domain
... WS Security capture every security aspect and map it into WSDL and UDI
... what I hear from vendors
... come up with feature that's not in Policy
... so that there won't be a time to capture a complete description of a
service
... always capabilities that have not been expressed in formal description
language
Ken Laskey: does that tell us something about a
standard description language; reference from other places?
... Add extensibility; with English
... I've been toying with framework where I point to current authoritative
English
... and if I have that mechanism
... and someone else is good with RDF, OWL, or formal semantics
... and point to that...
... or replace it
... what would a description language look like that gave you that power?
... RDDL
[Pete in dialogue with Ken above]
Eric Newcomer: Quick question...I have frustrating discussions; English is not compilable
Peter Lacey: no, what I'm getting at
... Seems to be tendency among vendors and enterprise users to impose top
down command, control structure
... .boil the ocean
... but it doesn't solve problems
... too much churn
... need to recognize that world is in constant flux
... move more important balls further down the court
<Chris Ferris> +1
Marc Hadley: Return to WADL
... I've been excited; alternatives suck
... pain around WSDL
... that's not Web
... Forms don't describe URIs
... Our first case was generating documentation
... always write down wrong things
... instead of what methods you support
... we use WADL to document what they're doing
... Require it for services deployed inside Yahoo!
... I had skepticism on client side
... using hypertext for certain state, for example
... the wrong approach from a REST standpoint
... or maybe look to SW
... Now I'm considering alternatives; and more excited than WADL
David Booth: Comment on describing the
semantics of an interface
... it's not an all or nothing proposition
... computer science tries to describe what a program does
... but if you fully describe a program you have written the program
... semantic descriptions are useful
... but you need a graceful way of describing semantics; up to more and
more
... that's an aspect of WSDL and XML Schema
... Semantic Annotation of WSDL Schema
... the use of URIs as extensibility points to attach semantics that is
inherently extensible is powerful
Glen Daniels: THis is what SOAP does, what WSDL
does
... this is what program languages do
... I don't know code associated, but if it's my universe, I'll use it
... symbol is in this nice space of symbols I can reason about
... there is value to that
... I agree with what DavidB said
... there is a middle ground for Policy
... to point to human readable documentation
... and make an assertion of compliance
... I can still have code that makes the agreement check work
... this is powerful to build systems to talk to new kinds of partners
... at machine processable level
... things in Axis called modules
... WS Security support
... when you plug in that code
... it has the implementation
... it knows the Policy assertions
... the new plug-in, that you get the new capability
... to recognize that symbol that you didn't recognize before
... allow for that connection gives you more value
... reflected in schema
... WS world can take this value from REST world and vice versa without
mushing all together
Chris Ferris: I want to +1 Pete and Dave's
points
... and also Glen
... address aspect of what may be missing
... Web Services standards we have; WSDL and Schema
... and with WS as they're deployed
... we've taken it off the Web
... some implementations do this
... expose it at a URI
... augment the service description with structured or unstructured data or
English prose, we don't do that
... we don't have the ability to do it
... to annotate it
... to bookmark it and talk about that service
... When we think about discovery and governance
... if we exposed it at the URI, then we could expose services
... and indicate the authorized services.
... you need a Web page
... we overbake the solutions
... external annotations
... are more applicable
... WSDL serves a purpose; to generate the code
... are we putting too much emphasis on this?
... like a namespace document; annotate with metadata
Mark Baker: Service description from WS
space
... my POV, constraints of REST are an advance beyond that
... it removes the need for services to be described
... why do they need to be described? because they are diff. and do diff.
things
... one code cannot do code of another
... in REST world, one service is identical to another
... or RC2616
... a REST service is like writing code with RS2616
... WADL is something diff.
<Glen Daniels> Except for understanding the particular data type.....
Mark Baker: a hybrid in the RESTful camp
... sense that it's competitor is not WSDL, rather XForms
... it's a forms language that describes state transitions
... happy to see WADL
... expectations about REST need to be tempered; focus on commonality not
difference
<Glen Daniels> My code to machine-process amazon.com resources is NOT going to work to process google.com resources, in all likelihood. This argument seems to just push the same problem up the stack one layer.
<Rich Salz> It's not worth describing the XSD for a POST ?
Noah Mendelsohn: Briefly about what Mark
said
... may be good use for WADL whether thru REST or WS
... diff. ways to interact in common sense of services
... whether HTTP or SOAP
... to write code to write a book, it will be diff. code to write book rather
than access bank account
... I want to talk about comment Skip made
... the before, during, after of descriptions
... another dimension of what you do in resource vs. stand off
... I have this service in the moment, and here's how you deal with it
... usually you have a family of services
... description lang. tells you how to parameterize that
... ten years from now, I may ask differently, but old URI may still be
there
... how do we live in a world with lots of services
... where some are written to current or older versions of the spec
... Dave is doing work on things that vary over time
... relates to what Chris says about pointing to description services
... level to be self describing
... what tends to happen; volume of resources
... they answer question by pointing to common description
... tells you how to do parametrized request for the weather
... all in constellation together
... how do you do this; evolve tech. as it changes over time
... if they didn't change their interface?
... get descriptions to ones you need and see if code is compatible with
both
Ken Laskey: DOD example
... think of way of describing something
... some general wonders what level of service
... LSIs running say we're service oriented
... he has no idea what this means
... then two months later, he said, "show me your WSDL"
... It's not just show me your documentation
... If it were WSDL, he could turn to MITRE and see if it's service
oriented
... we cannot say how good, but could say if they have WSDL interfaces
... you can use families to associate in catalogs
... WSDL doesn't have to encompass all of it
... but have that kernel that communicates
... How do WSDLs and WADLs work together
... versus saying where is your documentation
... so the 2-star doesn't know how to generate worthless WSDLs...
... at a meeting, group had legacy application
... pressed magic button in tool kit to turn JAVA objects into WSDLs
... turn a big ship into a Web Service
... they have 2,700 Web Services; does anyone know what they do and care?
... what do people mean when they say this?
... Chris, about semantic annotations in WSDL
... is valuable when people pass WSDL parameters; like colors
... where I see is disambiguating vocabulary
... have URIs point to them
... SA WSDL is dealing with another important problem that has been
ignored
Chris Ferris: I wasn't focusing on that nec.
Ken Laskey: reiterates he was talking that it
was embedded in the WSDL
... I think it should be embedded
... I think a REST service still needs a description; post tells me what real
world effect will be
David Orchard: Respond to REST description
language
... sufficiency of 2616 in terms of describing a service
... where I disagree with Roy
... haven't concluded
... taking an HTML page and saying, 'put these things into URI'
... and put these parameters, you'll get these schema documents
... we give you the schemas
... that is a description; you describe input and output parameters
... REST says...constrained
... WSDL allows you to define operations
... action headers
... utility of input parameters and return types
... an interesting philosophical point
... to what extent to build systems that take into account that metadata
... the less you specify, or describe, the more tightly you will couple the
systems
... I don't buy that much
... There is disagreement whether to describe or not
... diff. inputs will produce diff. outputs and the bindings are useful
Jonathan Marsh: Capture on our list
... external ?
... problems using semantic annotation framework
... embed in schema
Ken Laskey: embed what's external
... they point at things; external reference to semantic model or mapping
Jonathan Marsh: semantic annotation link
base
... more syntactical
Eric Newcomer: point is reference to the WSDL spec
Ken Laskey: so what do I put down as bullet point?
Jonathan Marsh: Another point is developing a framework for applying semantic annotations externally
Chris Ferris: clarify Jonathan's point
... we cannot talk because we don't have identifiers for them
... mumbo jumbo
... it's not an identifier; we use Q names
... it would be nice
Mark Baker: REspond to Ken
... If you submit a doc. to a service
... and you know what it's doing; then you are tightly coupled to it
Ken Laskey: but if I don't know
<Chris Ferris> component designators are no substitute for an identifier
Ken Laskey: I don't want to know what
processing
... for example, if I have a post such as credit card info,
... I want to know they'll purchase the book I indicated and not a trip to
Bahamas
... Post just says what's happening with information
... I want to know if I do post to a service, I want to know the real world
effect; I don't care how they do it
... what the effect of giving credit card
Mark Baker: in document format you put in your
credit card; that's defined
... provides a container for that doc.
Ken Laskey: yes, for payment; but I want to
know what I'm paying for
... whether a REST or WS Service
... what they'll do with payment, rather than an airline ticket
Eric Newcomer: close it out
Mark Baker: when format is standardized, credit card info. with trip description; comes from standardizing document format, not HTTP
Nicholas Gall: Follow up
... WSDL doesn't assure that operation describes service description
... you'd have to have a complete semantic description language to describe
the behaviors
Ken Laskey: I want to point to a word document that says what you do when you do this service
Nicholas Gall: So a controlled vocabulary?
Ken Laskey: What David mentioned before;
textual descriptions of what you read
... then move to more machine processable content
Nicholas Gall: keep clear machine readable vs.
semantic fidelity
... put a position out there, not time well spent
... to improve semantic fidelity of WS
... just get basics done
Ken Laskey: Agreed
Hugo Haas: I'm trying to understand last
point
... W3C work on annotations is based on RDF
... WSDL 2.0 has identifiers and RDF mapping
... there is a spec for each component; XML
... everything in hand with RDF to do this
... but does not apply to WSDL 1.0; will need to move
<Benjamin Carlyle> REST architectures are built around the idea that clients don't write code every time a new service is added. The client is configured (rather than coded) to point to a particular URL starting point, and knows what request to send and how to handle responses. Likewise, the server knows how to deal with the standard requests that its clients send it. How the starting resource is found is the AI part of the picture. Someone needs to choose it wisely.
Eric Newcomer: some confusion about what Chris
said; he wants WSDL on the Web to dereference a namespace
... then link you onto other things
Chris Ferris: yes
Philippe Le Hégaret: quick comment; semantic
annotation gives you nothing
... a building stone
... something about this that might be relevant to this XML element; that's
all it says.
<Chris Ferris> +1 to Philippe's comment
Philippe Le Hégaret: a lot more work needs to
be done to make it useful; some work has been done in Web Services
... This could be useful to attach MTOSI descriptions
Noah Mendelsohn: If I understand, you can use
REST to be self describing in the moment; and make clear what it's for
... post word document onto page and point to it
... why we don't post spec doc for the interaction even though we could
... they are long
... many interactions are identical except for a few parameters
... do what Chris says; put it out in share space and point to it
... I understand what Mark says, but don't agree
... not a bad thing to write code that is narrowly specialized
... doing some of that is natural
... analogue device drivers
... drive with commands, seek, reset
... or memory mapped
... do a store to location 35; disc arm will move; what's software
structure?
... sometimes generic code
... because memory mapping is uniform
... don't need to know if disc or
... kicking page out of printer, have code common
... comes a time when code is not general purpose; it's specific
... make the tradeoff carefully
... parameterized
... bake in a dependency on the description language
Jeffrey Denecke: This is a fascinating
discourse...but as a user
... why we like WS is because where CORBA failed
... vendors have adopted it as a programming interface
... all those ugly legacy transactions; I have a consistent coding
interface
... Put in there what vendors will adopt so we can build things
... it's not JAVA
... I have BAL language from IBM
... back to 1960s
... I have 16 systems that say issue a policy or book a payment
... I need a facade and connect it to the back end
... I don't see this discussion where we can produce code in a uniform way
... can we get back to finding, and translating services back to these old
legacy systems
... not get hung up on ontologies
Ken Laskey: does my bullet capture point:
Jeffrey Denecke: yes, get back to reality
David Orchard: I think there is some slight
confusion
... talking about things in WSDL
... it has component designators
... element identifiers
... take 1.1 or 2.0 and have URIs for them
... wanted to clarify
Skip Snow: Going back to earlier conversation
<Chris Ferris> only with a processor that can understand the wsdl1.1 element identifier schema and do something meaningful with it
Skip Snow: practical sense, what W3C should do
is nuts and bolts stuff
... in Enterprise the run time discovery of service is less interesting than
binding it
... creation of work 5-10 years ahead of us; we're not addressing today's
needs
... or nuts and bolts to address ways to make things work better
... things that will be felt in the Enterprise two years from now
Benjamin Carlyle: Interesting WS interop
thing
... it doesn' solve my problem; I need services that interoperate
... I don't think REST vs. SOAP is entirely academic
... if I can define my services as data, resource
... I write less code; makes it easier to integrate
... It's not a simple academic matter
... What you're saying to have things recorded
... benefit in SOAP
... I want a Web architecture that is ?? down
... where Web interactions are sufficient so we can interact and
interoperate
... smaller arch. with new methods and new content types if nec.
... that's the structure to build interop. services
... the former is more important than latter
<Paul Downey> +1 to Benjamin
<Chris Ferris> +1
Benjamin Moreland: Run time discovery
... .50% of our services are run time discoverable, so that's interesting to
us
... want SLA information
... if I publish from registry
... automatically set
... less duplication the better
Skip Snow: Citigroup +1 for that
<Benjamin Carlyle> My clarifications: I want a web architecture that is subsetted down to smaller architectures.... in smaller architectures we define special methods and content types, but use the standard interactions wherever possible. That means I don't have to write unnecessary code. It means that interactions are easier with the systems that I need to integrate.
[Second day starts]
Paul Downey: If you attended the AC meeting in Edinburgh, then you're in for something of a repeat performance, except if anything my position has strengthened since then following talking to a variety of folks from around our business. Like I said then, speaking for the whole of a big, vibrant, disparate organisation is tricky, and it's that issue that goes to the heart of what I'm about to say.
Paul Downey: I'd like to thank the Chairs and W3C for inviting me to talk about something so retro-chique as "Enterprise Computing", I've a strong personal interest in the history of computing, but I'd hope it's the future the W3C is looking towards, not enshrining some idealised version of the past.
Paul Downey: It seems we're talking about a lot of "80s" - we're all stuck in the 80s: 80s systems, 80s architectures, 80s thinking. 80% of all IT spend happens behind the firewall, which was one of the motivations for Web services. You see vendors eye that money greedily and want you to buy in their services, whatever "services" might mean. 80% of all IT spend goes on maintenance and suppport I've heard it said the cost of integrating a bought in package to an existing infrastucture is typically 80x the original package price, though 80% of all statistics are made up on the spot, so don't quote me on that one :) So we'd like to simplify systems integration with a spot of standardisation, and to do that we aim for some magical 80/20 point.
Paul Downey:
Video on the screen - conference calling
... business changing rapidly - most of which can be summed up by "deperimiterisation"
... standards can help shape the business offer better access to market and reduce the cost of integration
... EoI: equivalence of service inside and out side is required by regulation
... 'Web services' and 'services on the web' are quite different
... web services: is a eco systems of specs that enable ubiquitous messaging
on lowest common denominator
... Web services: (contd) messages are not self describing - need metadata, policy etc.
... KEY PAIN POINTS: databinding, message contents, versioning, description of asynchronous transports
... I do not really understand what SLA means in terms of WS-Policy - but we talk about it a lot
... NOW web: most on the web hate SOAP, love the web
... WEB (Contd): GET is safe - knowning when somthing is safe is challenge for web-services
... at least generate message IDS to identify messages to resources hence could use WEB
... The Web services stack does is looking at many things, but doesn't solve many problems for 'me'
... kind of things we do 'publish subscribe', delayed notifications, Amazon transactions etc. involve the web and Email
... W3C should concentrate on leading the Web to its full potential and go into
maintenance mode for Web services
... W3C could consider collecting 'best practices' and 'patterns-of-use' for services on the Web
Peter Lacey: I agree with best practices team any suggested HTTP extensions be considered?
Paul Downey: We should consider both
Question: How about authentication?
Paul Downey: W3C doesn't have a good track record for protocols
Eric Newcomer: How to deal with existing or legacy systems
Paul Downey: plain Web server is all that you need. Historically we (BT) built our own middleware, and that worked well. Now we have Apache and the Web.
TR: OSI had an hour-glass — nice transport abstration — gets wider at the top for application — we should consider the OSI's concept of associations (i.e. grouping of applications or service element) — OSI provided the agreement — presentation layer provided negotiation capability — that flexibility of OSI may be useful here — I think you hit upon one of weak point of web-services
Paul Downey: stack is powerful, but it is also weak because SOAP ignores everything including the transport
Jonathan Marsh: Can we do something in mapping SON and XML - do you see something in there?
Paul Downey: it is too early to predict how people use JSON, and the security concerns aren't yet well understood - most people avoid "eval" now. Let's wait and see.
Noah Mendelsohn: (Question): Nice talk — SOAP headers — soap does not impose order — do you believe this be worked ?
Paul Downey: There is a difference between SOAP as written and as practiced.
Noah Mendelsohn: different user wanted different ordering — however this forces the implementers to buffer the headers
Eric Newcomer: Question of headers is interesting to us too. The requirement for what in which order is not very clear.
David Orchard: Order in soap is different from OSI — OSI had encapsulation — we flattened it in SOAP — we do not know whether this will scale for all the different things
Noah Mendelsohn: The order, if important, then we can cover it in the specification of the header — eg. security header, transaction initiation here — etc.
??: another: at the time spec were developed we considered very wide set of scenarios from toy scenarios to very complex scenarios
Mark Baker: we treated HTTP as transport
protocol and not the application protocol
... Reality is: web is a superset of Web services and beyond. Theoretically
you could create a superior solution that can be solved by Web services but
not by web — I have not seen it.
... ERP, EAI, B2B etc. are solved both by Web services
... B2C for example webservice solutions does not exist
... REST however is not a strict subset of WEB
... WEB is a more loosely couple SOA — interface and implementation is
separated
... Implementation is more that language, OS etc. it is also type of
service
... WSDL is not run time architecture of the system — if you delete all
WSDLS system still works — so it does not really separates the
implementation from interface
Mark Baker: I used to be CORBA-head — now I am WEB developer with REST as guide
Eric Newcomer: we got more papers than we could create slot so some overlapping paper were not put in a slot
Chris Ferris: you can certainly use WSDL to
generate code that hardwires the interface — however you could write a
loosely coupled system
... Agree that 'GET' is the key — as long as URI was used, you are all
set
... However I do not agree that webservices is strict subset of the web
... You can use WEB to integrate legacy to some extent — however we need
webservices is needed for that — and hence webservices is not a strict
subset of WEB
<Benjamin Carlyle> I think you could have made the same arguments about the Internet Protocol many years back. We couldn't hope that it would displace the network protocols of its day. I think we are in a similar place with the Enterprise today. Time will give us a solution. We just have to make steady progress with it.
Mark Baker: comments about legacy may be valid — but I have not seen one
Glen Daniels: web does not really allows late binding — you need some infrastructure at some level — webservice provides that — REST simply pushes it up
<Paul Downey> Mark's diagram answers this: http://www.markbaker.ca/blog/2004/10/29/protocol-independence/
Mark Baker: REST does not push it up — but delays the binding
<Benjamin Carlyle> It's actually about evolution. REST organizes the message structure in a particular way, and you still need to understand the whole thing... but REST offers a better evolution picture. Methods and content types evolve at different rates.
Benjamin Moreland: we are transport agnostic wrt to services — based on our customers we bind to HTTP or anything else
Mark Baker: HTTP is not a transport — sorry
<Paul Downey> we touched on this yesterday with "how does hypertext is the engine of application state" surface in a programming language?"
Nicholas Gall: I agree with the presentation
— WS* could use more REST full approach
... uniformity drives architecture — eg. salesforce.com use only 17
operations — shows we do not need much more complexity
... Question to Mark Nottingham: How to make it easier for others to see
your(our) point of view — we should strive to eliminate specificity
Mark Baker: I have tried everything — I have not tried "make friends and influence people" way
Skip Snow: Social complexity of SW development:
we would like to rely on non-function aspects to computing — we would not
like to invent mechanisms for all of the -ilities
... we would like the vendor community to take care of it — we want vendors
to build the pipes and we want to focus on the liquid inside the pipes
... I think we need to be very cautious about not continuing our current
direction
Mark Baker: Give individual bits of data URI may be one answer — however we may have to bite the bullet and may be build a facade to webservices to be on web
David Booth: Web was designed for legacy data — if we decide to make your legacy play a larger role — how do you do it.
Mark Nottingham: We build it ourselves — if it works — then we push it out. This webservices is not defined by market forces, but by politics
Eric Newcomer: Citicorp for example built on their own for a while — then they started buying from vendor a few years later
Mark Nottingham: Webservices is time wasted for politics — how do we get REST accepted? we need tools and best practices.
Peter Lacey: Comment is for Nick — our companies can play big role there — tutorials/gartners publications etc.
Nicholas Gall: Gartner is trying to publish an analysis of webservices and REST
Steve Vinoski: workshop is required to recommend what to do
Mark Baker: I am not suggesting any answers — This is my attempt to educate webservices community so they could decide what can be done
Hugo Haas: We use opensource heavily
... when people talk about webservices — they mean several things
... SOAP based webservices: we do advertiser services; yahoo ! mail
... Yahoo!mail is currently more that 2Billion SOAP messages a week
... Why SOAP: code generation; customer usage; historical — acquisitions
and mergers
... issues with SOAP: interoperability — code generation dream becomes a
night mare when we tried opening a API to other people
... WSDL problems
... data binding became another issue
... The ease of development associated with SOAP then bites us later as we
expand
... poor support for WS-* and not really used at Yahoo
... HTTP based service — second class of web services
... yahoo shopping; myweb etc. and most services are http based
... Why people are doing this: familiarity; no special tools needed
... we(Yahoo) looking for easy documentation for code and services
... another issue: Authentication — scenario: web application —> cache
—> service1 —>service2
... let us say application is supported by a partner — then yahoo has to
authenticate both partner and the user and inside we have to authenticate
cache, service1 and service2 — five authentication
... Currently web infrastructure does not support this — one authentication
is there then you are on your own.
... no cross host authentication;limitation of number of entities;poor
security; very chatty in case of Apache; and hence people use cookies, and
custom authentications
... no common tool to do this and caching is still a problem
... some requirements (slide 16) verbatim
Paul Downey: thanks for presenting BT position better than I did!
Philippe Le Hégaret: what can W3C do beyond cookies?
Hugo Haas: better authentication may be — but IETF may be better forum
Philippe Le Hégaret: yes, how can we make this cookie idea useful? A profile?
Mark/Hugo: may be w3c recognizes cookies as legitimate primitives — may be that will help
<David Orchard> An example of client side session id in cookies:
<David Orchard> http://www.w3.org/2001/tag/doc/state#cookiesessionidexample
Nicholas Gall: what you meant about 'big draw towards soap'?
Hugo Haas: autogeneration of code
??: if it is federated security? is it the same as existing effort?
Hugo Haas: Federated Security is loaded term — we are after n-entity authentication
?? : Code generation draws people to SOAP — what can W3C do to make REST more appealing. (Mark Yahoo: We(Yahoo) working on that)
??: Question: Tool makers dilemma: We can produce tool — then we get dinged for creating tight binding — on the other hand without tool developers are not going to feel comfortable about it.
Hugo Haas: we have not given too much thought about how to achieve both. (loose binding and useful tool)
<Benjamin Carlyle> Remind me to talk about ContentParser with Mark Nottingham sometime :)
Paul Downey: Security — authentication is key
issue... what can w3c do here? may be question is to the audience
... one of the problem with cookies is no repudiation — we may need better
solution
<Paul Downey> sorry rambling point, but W3C can help with authentication, and evaluating "good enough" cookies (v) certificates
Chris Ferris: Interoperability — is the most important thing we could address. Databinding — IBM was interested, however certain other party did not participate
Eric Newcomer: W3C has difficulty in getting people's commitment
Paul Downey: (explains W3C Databinding
WG) how do we publish a schema inside a WSDL to reach broad
marketplace? schema is complex
... basic patterns reach toools;
advanced patterns document what is in current use "in the wild"
Mark Nottingham: W3C cannot force vendors to follow a standard; they cannot drive the architecture if vendors do not come to the table.
Noah Mendelsohn: I am here to represent w3c: Now from IBM perspective, we listen to our users and I think other do as well. As people understand value of REST then the IBM investment go up.
Philippe Le Hégaret: so, when is Yahoo! going to join the databinding Working Group?
Ken Laskey: We need to educate users
<Paul Downey> uploads pictures to flickr: http://www.flickr.com/photos/psd/
David Booth: I'm not going to suggest any
changes to WS stack. Rather, want to look at the foundations of WS (XML) and
consider new problems.
... (Dave skips validation section, now speaking about efficiency per the
slides)
... (Dave describes how to bridge RDF to/from XML)
Peter Lacey: Lots of questions... Looking for clarity on some things. First, are you implying that RDF can be a better XML schema if you assume XML serialization?
David Booth: RDF is a better basis for data models than XML schema.
Peter Lacey: Picture on slide 44 looks like an ESB/JBI container... does RDF give me anything different?
David Booth: You could certainly stick these
two normalization boxes in an ESB. RDF would be great tool for implementing
an ESB. Doesn't give you semantic clarity without RDF.
... can have common semantics with XML - but nothing in the specifications
actually says that the same QNames MUST mean the same thing.
... harder to get XML reuse than RDF reuse.
Peter Lacey: Relationship between this and XML infoset?
David Booth: When I say "XML" I really mean XML infoset.
Nicholas Gall: Sounds to me like you're proposing instead of being concerned about data binding, we should be doing RDF binding. Apps should map into RDF not native data structures. Right?
David Booth: 100% correct, thanks for bringing that up.
Nicholas Gall: Sounds great, but I can't imagine users taking this step any time soon... they're barely keeping up as is, let alone adding another layer....
David Booth: This is more a bridge than another layer.
Noah Mendelsohn: As research work this is very
appealing. Be interesting to see what it could do in practice.
... XML mixes documents and data... but RDF doesn't seem to have a simple
mapping for the document stuff.
... I think two things are being mixed here. First, I have a gradually
evolving language....
David Booth: Can I respond to first point first?
Noah Mendelsohn: Sure. Mixed content for instance?
David Booth: I have another talk which talks
specifically about that... lexical ordering of elements, for instance, is
both a plus and a minus. XML doesn't tell you whether order is
significant.
... Big difference - in RDF it's explicit and named.
... Another example - what does nesting mean in XML? What's the
relationship?
Noah Mendelsohn: That's pretty close to syntax
David Booth: All relationships in RDF have names and they're reusable.
Noah Mendelsohn: You're saying you can use RDF
to bridge gaps between people who have fairly similar ways of dealing
(customer/client etc).
... Incremental changes also - RDF solves a big piece of that problem.
... There's a bigger problem which involves the cases where there are REALLY
different models, and there's an open question as to whether they're even
really mappable at the abstract level...
... How do you imagine dealing with this kind of thing?
David Booth: You're right - notice there's only
one SameAs element in the example, where you use two terms to mean the same
thing.
... This stuff doesn't come for free, and you need to manually figure out
what the relationships are.
... Although this example is just "isA"/"hasA", typically you'd have
application defined relationships.
Paul Downey: Good job describing the problem
space really well. Now that I've pumped you up, let me bring you down. :) Lot
of modeling going on inside BT with tools.... when they want artifacts, they
generate schema, and the tools process schemas.
... you want us to interop at the abstract model level and not the concrete XML level... but why
isn't it already happening?
David Booth: It is already happening... it's
slow, but there's definitely more uptake.
... The world of UML is a lot closer to the OOP world - that's a closed-world
assumption, not an open-world assumption.
Benjamin Carlyle: populating an internal data structure from the tree structure of XML requires fundamentally simpler algorithms than populating an internal data structure from the graph structure of RDF. Most message end-points are not going to use RDF or an XML Infoset as their internal data structure in my limited experience, so this is important. Moving to RDF as the metamodel for information exchange may make it easier to aggregate data (though this has an obvious counter-example in blog aggregation happening at a higher level of abstraction), but even if that is so it imposes a significan additional burden on the apps that are actually going to drive the expansion of the semantic web. Those are the apps that pass and interpret messages for direct processing. Those apps require standard message types, not just standard message type metamodels. Once you have standard message types, the intrinsic value of standard message type metamodels can be questioned.
David Booth: Transformations are about going from XML to RDF
Benjamin Carlyle: But also model transformations/mappings - isn't this an insoluble problem, shouldn't we be working on getting people to agree on the right model
David Booth: Use case is for pre-existing apps, though, which can't change...
Benjamin Carlyle: I'd try to figure out the semantics of the real problem, and get all the authors together to build the real solution.
David Booth: Sure, that's great, but it only works in the micro. The following week, there's a change or a new partner, and you're back in the same situation again
Mark Baker: Been talking with Ben about this
for a little while. I used RDF on one project to great success.
... RDF is to XML as HTTP is to SOAP. Both SOAP and XML kind of punt on the
hard problems - low level infrastructure which don't standardize on
additional things like HTTP and RDF do.
... XML requires app-specific data models, and RDF has the graph of triples.
A lot of the success of my project came purely from extensibility and
versioning, less from the data format mappings.
... could look at this as "red customer year X" and "red customer year Y" -
time is just as much a differentiator as organization or space.
[lunch break]
David Orchard: The CFP was interesting - where
are we wrt to web services?
... brief look at past.
... WS Workshop in 2001 "spin up lots of groups"
... 6 years ago. We're about half way there.
... See what the specs are and have initial implementations.
... Don't have complete standards + profiles + interoperability across the
board yet.
... We seem to have a process in place to fast-track tightly-scoped
specifications based on member submissions.
... WG moves quickly to Last Call based on the submitted specs.
... OASIS as well as W3C.
... Has this process and architecture really worked?
... When will we get interop? Was fast-tracking good for a coherent
architecture?
... Is WS-A Rec better than the submission? Concerns about architectural
consistency in usage.
... What about WS-Policy? E.g. the WS-RM MakeConnection proposal interactions
with WS-A Metadata spec.
... Complicated interactions going on.
... Multi-party discussion, while groups are under time pressure.
... Pete's S stands for Simple article resonate.
... So what does the W3C bring to the table.
... Architectural coherence isn't compatible with fast-tracking.
... Ongoing debates about REST vs. WS-* (forward pointer to Noah's talk.)
... A use case:
... Thin Client Banking
... classic WS-*, SOAP, WSDL, enrichment through headers. Need very high
perf.
... Need to reach more clients. How to reach Ruby, Python, OSS clients?
... Stacks don't publish as REST services easily.
... Not sure what kind of customer demand would drive dual deployment.
... Is it cost-effective?
... Second use case:
... Client-Side REST Validation
David Orchard: XML over HTTP Music search.
... specify query details, get back a fairly complex structure of XML
data.
... Using XML Schema to describe responses and URIs to specify inputs works
well at a certain scale.
... medium size deployment.
... I deployed such a client and found this kind of sucked - missed WSDL and
client-side validation of the returned data.
... Works well where there is a medium number of combinations.
... WSDL 2.0 however is too complicated for a REST developer.
... Has interface with operations, bind each of those operations, then deploy
them at an endpoint.
... Tradeoff in architecture between many operations vs. generic
operations.
... Want to have some client-side validation. How about create
language-specific libraries?
... Imagine that for the Enterprise!
... Ack!!
... Versioning will kill the cat.
... REST Description Language is the answer to increasing productivity.
... Would lower the bar for entry for large DotComs.
... Scales to a large number of services or resources, i.e. enterprise.
... Third set of use cases - Widgets, Portals, Discovery.
... Next gen UI seems to be based around widgets.
... Do integration of the widgets on the screen.
... Need state management, security, cross-widget communication.
... No machine processable information about these interactions.
... Think a declarative description would be good.
... How do you get the description of the widget? e.g. ?wsdl
... How do you find the widgets supported?
... How do you integrate the widgets into the search engines.
... REST description language would help these three use cases.
... Enterprise aspects.
... What's different between Internet and Enterprise?
... state? security? performance?
... Does this affect specifications?
... WS-AtomicTransactions over the internet makes no sense.
... Enterprise it does make sense.
... Recommendations:
... W3C should be the place for Web-centric stuff - descriptions, protocols,
formats.
... HTML, Forms, etc. is good, but we need a better description language for
REST services than WSDL 2.0.
... Perhaps afterwards better discovery of this language.
... Missing some technology allowing SOAP clients to consume REST and vice
versa.
... Need to talk more about fast-tracking.
... Building block specifications with errors have fairly serious
ramifications.
... Regrets Reference Parameters in WS-A.
... These are what W3C should consider.
Glen Daniels: comment: removal of reference
properties in WS-A. Huge kerfuffle about EPRs being used to identify
things.
... The URI in the EPR plus Ref Props (like cookies but used explicitly for
identification), were being used by toolkits coming out.
... Felt to be against the Web architectures.
... One thing that happened is that Ref Props were pulled as explicit
identifiers, but left Ref Params as cookie-like.
... Problem is that they are still being used as identifiers. Harming the
architecture.
... The problem isn't the removal, it's the abuse of them. Good we removed
them, but people are still able to undermine the architecture.
David Orchard: We could talk about history.
... We effectively said to the TAG, we'll be good. But many of us knew we
needed different technologies, e.g. mapping the ref params into the URI.
Nicholas Gall: I agree we need a better
description language, but there is still an issue of descriptions being
tool-centric.
... I think we need more emphasis on generic protocols that are out there.
... You could enrich a message through SOAP headers, but you can enrich
Atom.
... You see Google GData enriching Atom.
... What do you think about W3C saying there are some general-purpose
application protocols that you should consider first.
David Orchard: Disappointed we didn't get Atom
into the W3C.
... Applies to SOAP protocols.
... W3C should have gone after that more aggressively.
Shriram Revankar: I agree 100% that we need
better description languages.
... But if I correlate that with your other statements we need interface
description for REST.
... If we simply stop at IDL for REST we still need service binding and
deployment.
David Orchard: We could provide hooks to layer
on QoS, we could layer on choreography, data that contains links to other
services.
... Like the WSDL 2.0 HTTP binding URI templates is nice.
... WADL shows this is a tractable problem.
Mark Nottingham: One of the biggest problems we
have is interface and format proliferation.
... We're a decentralized company, each part working in isolation.
... Every interface is different.
... Risks: need to enforce good practice, which would be helped by
standards,.
... Second problem is learning curve. 10000 new formats makes it hard to
integrate within my enterprise.
... When I see things like Yahoo Pipes I got excited, ESB vendors should be
shaking in their boots.
<Paul Downey> yes. Pipes rocks
Mark Nottingham: WADL and so forth, plus tools around that, would help.
David Orchard: Atom is still a container format.
Mark Nottingham: Agree, still need to agree on the contents.
David Orchard: Yahoo would switch to Google
stock quote format?
... Not sure that would have happened as well in W3C.
... Atom wasn't a fast-track spec. People met to work on the spec. Would have
been a success for W3C.
... Perhaps Atom flew under the radar by staying out of W3C.
... But how do we get stuff like Atom into W3C that will make a difference
later?
<Rich Salz> Disparaging W3C for being vendor driven while praising IETF for being otherwise is naive.
<Rich Salz> You think Cisco, for example, doesn't "work the room" for routing protocols?
Glen Daniels: I'll touch on pain points.
Progress does a lot of stuff and has a lot of views on the world. Sonic,
which I come from, makes the Sonic ESB. It's message centric, not resource
centric. It deals with async behavior a lot. lots of legacy stuff.
... This requires being able to deal with data formats, etc. Need to adapt to
changing environments.
... We live in a multiprotocol world. We love XML, that's what flows across
our bus even though on the back end it may be something else WE think of it
as an XML infoset, it's a powerful commonality.
... important to be able to bridge across protocols.
... Should there be two different solutions, external and internal? That
division is not a good idea because it so easily changes.
... REgulatory requirements may require this. Also if you require a new
company or merge business units you suddenly need to move them internal.
... But one thing that helps is shared models. WSDL does this, then you bind
it to an underlying tech. IT dept can build the binding specific stuff for
particular implementations.
... So WS seemed great as a stack of solutions to make lots of things talk to
lots of other things. Lots of vendors raised the flag and said they would
make it work. The promise was also a composable set of specs, and tooling.
This sounds fantastic, but it didn't work out that way.
Glen Daniels: So the problems were that there
was a lack of architectural consistency.
... Woudln't it be great to have a foundation of protocols that work within
the context of the web.
... Had a notion there would be architectural consistency.
... Hope the WS-Arch WG would help - didn't happen.
... Found there were interop problems.
... SOAP Builders had some great success, then WS-I BP helped, but since then
not as much as happened.
... We do see use out there that's moving forward, but we have work to do.
... WRT W3C, we see that we want to use common identifiers, URIs, inside and
outside the Web.
... You also need metadata though.
... What's the format, what can it do for me. Even in the REST world.
... Content-type is great for telling you what the document is, but that
doesn't seem to be enough.
... You shouldn't require an EPR in order to talk to your "thing".
... The concept of using a single URI to talk to a single resource seems
really important.
... That spans not just the web, but the universe of interesting things.
... Vendors should be paying attention that their code doesn't undermine this
principle.
... Bindings are important - we want to see more bindings, continue to work
on existing bindings.
... The binding model of an abstract service with concrete bindings gives you
useful stuff.
... Even if at the wire level it looks different I can reason, register,
provide metadata, etc.
... The WSDL-level descriptions is great for that. URIs plus service
descriptions allows you to do orchestrations.
... Does WSDL handle Web and WS?
... Did we succeed in WSDL 2.0?
... WRT REST vs. WS-*:
... There need not be only one.
... Just as legacy software isn't going away, neither is WS-*.
... The Web isn't going to be replaced.
... Need to evolve together.
... In particular, can -ility enabled apps gain from what we know works with
the Web? Or do they need to turn into the Web?
... Or is there a middle ground where we keep value and ease of integration
of WS, but use the power of URIs.
... Caching, proxying, uniform interfaces.
... Standardized operations for common functionality can be important.
... GET/PUT/DELETE on the WS side.
... Plus a way to recognize at the binding level how to bind this into true
HTTP GET at the binding level (and something else in the JMS binding)
... Where do we go from here?
... Both sides don't fully understand what each side is talking about.
... How do you build the kinds of things that we're seeing WS used
for>?
... W3C could develop some examples, build with both REST and WS so we can
see how they each work.
... Help people figure out which tool is right for the job.
... Pushing harder for architectural coherence would be a good thing.
... The URI/EPR thing needs to be fixed. Need to encourage communities not to
identify things using RefParams.
... Is there a framework we can use to make these specs work better
together.
... Need to work on Versioning as well.
... And of course more interop work is good!
... Even if it doesn't centralize at the W3C, we could be involved.
David Booth: What's the destination between common service models and REST.
Glen Daniels: I wasn't saying "uniform protocols" I was saying something that binds to a URI on the Web, but also spans the ability to use non-Web protocols.
Skip Snow: Like the idea about composability
and complexity of WS-* as being a factor to further the reference
architecture.
... Encourage W3C to further that.
Glen Daniels: Yes, but what's it look like?
... Beating a dead horse - features and properties in WSDL would have helped
ground concepts in URIs and Web/Semantic technologies.
Skip Snow: What concerns me is that Financial
institutions have invested in a lot of vendor promises, turned large ships,
we don't want to see that trust turned to ash and start over.
... Carrying forward with work to figure out the reference architecture would
be invaluable.
David Orchard: Mentioned ResourceTransfer
stuff: Don't have a way to convert an EPR into an HTTP GET.
... Not in Grid's remit to invent that technology.
... Touches on the missing pieces of the architecture.
Noah Mendelsohn: Dave mentioned mapping EPRs to
URIs.
... Have mixed feelings. People will at times need EPRs to identify things
it's valuable to have a two-way mapping.
... On the other hand, from Web arch that's a compromise.
... Crucial thing is where EPRs are used. When they were raised to the TAG
they were promoted like cookies.
... Used in relatively private p2p contacts.
... they aren't just opaque, they are pretty private.
... Problem is where are they going to be used.
... When they aren't transitory there are problems.
... When I email you an EPR the chance that software will map it into a URI
is lower than just handling a URI.
... We need to ask carefully in each case when you need to use an EPR.
Paul Downey: Similar position to mine - two
things.
... But I'd rather keep them separate, you seem to want to evolve them more
tightly together.
... Seems like WS wants the Web, because we keep seeing WS-* based resource
specs like WSDM.
... Trying to span email and JMS and so forth.
... But why can't you just use the web? Haven't seen a place where RefPs
are really necessary.
Glen Daniels: Thinks there is a need for a machine-readable spec tying an address with metadata.
Paul Downey: Were talking about
WS-MetadataExchange.
... Don't like the idea of "the one true WSDL".
... Making an observation that Web Services can learn more from the Web than
the Web can learn from Web Services.
<Rich Salz> If webdav PROPFIND had GET idempotency...
David Orchard: Can see why people would use
reference properties for things. One cool thing about RefParams is that they
enable QName dispatch, etc.
... Much harder to do that in a URI.
... Battle between developers and admins.
... Allows developers to endrun namespace owners.
... When there are a lot of distributed headers, you don't have the same ease
of use with URIs.
Chris Ferris: Perhaps overlaps with David
Orchard, Glen Daniels.
... There's a myth that SOAP and REST are somehow incompatible with each
other.
... SOAP 1.2 Response MEP and Web Method
... WSDL 2.0 HTTP binding, wsdlx:safe.
... Not perfect, but we get the issues.
... Problem isn't with this work, it's with the execution of these specs by
the vendors, in not making this stuff available.
... SOAP 1.2 has been out for a long while, but not many offerings of SOAP
Response.
... BP hasn't even profiled SOAP 1.2 yet.
... The original vision was for a single thing that scaled from Web, beyond
it to provide additional qualities of service beyond HTTP.
... And transcend just using HTTP as the transfer medium.
... First point of contention is URI vs. EPR, which was sort of ignored.
... A URI is a name. An EPR isn't an identifier, except sometimes we treat it
as if we could.
... I like to think of these like cookies. In some cases a necessary evil.
Not always a bad thing.
... Yahoo talked about the need to use cookies for sessions,
authentication.
... Roy disagrees, yet the web stumbles along.
... WS-Addressing doesn't define equivalence of EPRs.
... No canonicalization, whitespace, anything else.
... Can't tell if two EPRs are the same.
... If I pass two URIs, there are rules that allow you to tell whether they
are the same.
... Notion of a subordinate resource which may be used as a subordinate
identifier.
... Problem is that some uses of EPRs treat RefParams as identifiers.
... Grid apparently published WS-Naming, which says you SHOULD use RefParams
as identifiers.
<Paul Downey> points steve at http://www.tbray.org/ongoing/When/200x/2007/02/27/Udell-Vinowski
Chris Ferris: Don't think we should be using
RefParams for naming resources.
... Second Point - uniform interface.
... This is changing somewhat.
... I have felt that the real value is in GET.
... Don't need a separate GET for HTML, PDF, SVG, etc. Can use content
negotiation if I need to as well.
... WS-ResourceTransfer and WS-Metadata Exchange start to define consistent
interfaces for Web Services.
... If you could invoke WS-MetadataExchange on any service, it's equivalent
to HTTP HEAD.
... Good to have consistent interface. In many cases it could be bound to
HTTP HEAD, eg.
... In most cases one designs a service to interact with a specific service,
so description is good.
<DBooth> That google maps / craigslist mashup was an RDF app, BTW.
Chris Ferris: Some cool mashups like Google
Maps/CraigsList and Google Maps/USGS earthquake are easily enabled by the
Web.
... We've come across some examples where you need both Web and WS.
... RosettaNet example - PDF forms for some users, WS-* for others.
... Need to scale access from momNpop to large enterprises.
... Automotive example: huge supply-chains. For smaller suppliers without
fancy IT, they need a web-based solution.
... Using faxes today, with manual conversion into bits.
... Many of these suppliers are in emerging economies, with lower IT
infrastructure.
... Financial example: one path to HR data is by the employee via web site to
enroll etc. But management of the system will use high-availability WS
systems.
... many other examples.
... There really are times when it makes sense to use something other than WS
for some task or other.
... e.g. REST/Web.
... If you need scalability, insurance against transient failures, large data
sets, etc. maybe WS is better.
... (correction) sometimes with moving large datasets around, WS is not the
answer.
... But it still makes sense in circumstances to use WS.
... When you need secure, reliable, async messaging to interact with business
partners.
... Sometimes there are multi-protocol exchanges.
... Transition from HTTP to JMS or MQ within the enterprise.
... Intermediation of messages beyond caching.
... Additional QoS.
<Paul Downey> my WS-RX spec: "HTTP GET", sequencing? "HTTP GET, Accepts Atom"
Chris Ferris: We could apply HTTP to some of these problems (e.g. HTTPR)
David Orchard: You mentioned generic interfaces
and need for generic reads.
... Disagree with generic operations. Generic reads are good, because you can
get reuse of software.
... But on the update side of the house is where REST falls down.
Chris Ferris: Not what I was trying to say.
David Orchard: Need a middle ground. Need a
generic READ operation, but a specific set of update operations.
... You don't have any reuse of update operations - purchase order is too
different than stock quote.
... Like the model of generic READ, specific UPDATEs.
... WebDAV found this out.
... Too many side-effects.
... Need both generic and specific protocols.
<David Orchard> http://www.pacificspirit.com/blog/2004/09/28/web_services_needs_transfer_protocols_and_specific_protocols
Chris Ferris: In agreement.
... Where we can we should leverage HTTP GET (or non-HTTP equivalent)
Mark Baker: Think things have moved forward in these presentations.
Chris Ferris: Takes a long time to turn a big ship.
Mark Baker: My presentation was on why REST was
an improvement on SOA, so we're not done yet.
... Eric's diagram with the message being routed to either a WS or Web
stack.
... I don't see it that way.
... See it going into the Web stack, then into WS if you need, and then into
legacy, or directly from the Web stack to the legacy.
Nicholas Gall: Push back on the distinction
between generic READ and UPDATE.
... Seems like there was some agreement about generic interfaces, yet maybe
we're talking past each other.
... We POST forms generically all the time.
... We only know what "UPDATE purchase order" really means because of English
documentation.
... Don't think you're losing anything to use UPDATE, but you proliferate
lots of similar operations.
David Orchard: The issue that comes up is that
developers will have to use 1500 different UPDATE operations.
... That's right - you need to learn all the ways each of those UPDATEs could
fail.
Nicholas Gall: Unique return codes are fine.
... When you need to be specific, be specific.
... Need to think creatively about when we can be generic. Web is generic.
Chris Ferris: The real value of the generic
operation is when you don't need to know anything about it.
... PUT is a little less generic than GET.
... Many cases don't want to know what it is (spiders, crawlers, search
engines)
... When you're POSTing you need to know what you're posting. Web form tells
you what you're posting. All the details are there regardless of whether you
call it UPDATE or UPDATE PURCHASE ORDER.
Noah Mendelsohn: Glen guessed I'd talk about
WS-Transfer.
... I'm not - avoiding controversy.
... But there are real risks to reinventing GET, as well as maybe some
benefits.
... Lots of infrastructure built around HTTP GET.
... Introduce a new GET, we need to ask whether it will leverage the existing
infrastructure when it can.
... How much infrastructure will need to be re-deployed?
... Is there some generic value out of generic operations? Think there is in
both POST and GET.
Chris Ferris: Isn't our position we should go
do a parallel GET.
... Think it should indeed map to an HTTP GET.
Paul Downey: Puzzled - the point is using GET inside SOAP is that you can go beyond HTTP to JMS, etc. It of course doesn' t leverage that infrastructure.
Chris Ferris: I said the opposite. Most people are using SOAP over HTTP.
(several hands indicate non-HTTP SOAP use.)
Skip Snow: We use many different transport.
David Booth: I've heard the assertion that the
benefit of uniform interface is reuse.
... I think it's about loose coupling.
... Not about how much work, but where and when you do it.
Nicholas Gall: in the printer example, are you only getting status information? you wouldn't enable the printer to be cleared, etc?
Noah Mendelsohn: the diagram could include POST support
Nicholas Gall: is this not then a "Two Web" scenario? HTML Web & SOAP Web?
Noah Mendelsohn: it's another media type off
the same URI
... if SOAP's adding value for you, do it both ways, otherwise don't
Shriram Revankar: is the goal to support 2 different clients?
Noah Mendelsohn: there's one Web server here
... just serving another media type
Chris Ferris: need to choose between layered (Web server -> SOAP -> printer) vs Eric Newcomer's approach (routing choice to either Web server or SOAP stack)
Noah Mendelsohn: once you buy into URI naming, you can go either way
Mark Nottingham: i recall lots of gopher servers long ago, then they went away. the market will pick a winner
<Paul Downey> +1 to Mark Nottingham. SOAP will live or die in the marketplace
Noah Mendelsohn: SOAP will be around as long as it adds value
Marc Hadley: are some of the advantages you mention attributable to protocol independence?
Noah Mendelsohn: somewhat. hope to be able to use http URIs with JMS. [lots missed]
Mark Baker: does the SOAP envelope in your SOAP printer example have an operation?
Noah Mendelsohn: could do. probably does.
<Paul Downey> also blogged how URIs are identifiers, and don't dictate the protocol: http://blog.whatfettle.com/2005/02/07/uris-identify-stuff/
Mark Baker: so if the queue had its own URI and we DELETEd it to clear it with the Web approach, would the Web services equivalent have an operation on the printer URI or the queue URI?
<Benjamin Carlyle> * REST has a number of different facets. Mark Nottingham's low-hanging REST fruit was vertical scalability. I don't really care about scalability. I care about REST's evolvable interoperability
Noah Mendelsohn: i see your point. there's some messiness there. but i maintain that using URIs provides a lot of benefit
<Benjamin Carlyle >
David Booth: Regarding the desire to use a non-http protocol when an http URI is used, I wrote up how to convert any kind of URN to using http URIs: http://dbooth.org/2006/urn2http/ This is relevant in the Semantic Web for Life Sciences interest group, because some of them have defined an LSID URN with special non-http resolution characteristics. But you can still use http URIs while also using the LSID protocol. Here's more on how to do that: http://lists.w3.org/Archives/Public/public-semweb-lifesci/2007Feb/0126
Benjamin Carlyle: I want to see more investment in HTTP to solve problems of the enterprise
<Ken Laskey:> … assembles list of issues, Ben added a few there ... do we want to be more proactive about what people shouldn't do?
Benjamin Moreland: do we want to be more proactive about documenting things we shouldn't do?
Nicholas Gall: design your app-to-app
architecture as Web only, then backoff incrementally when you need to
... thing not to do is to start with HTTP as transport
Glen Daniels: don't want to jump to that right away
Noah Mendelsohn: should call out naming things
with URIs. can stand on its own.
... i think it's the 95% case, not the 100% case
Balaji Prasad: need an end-to-end architecture for Web and Web services, putting it in the context of enterprise needs (which goes well beyond Web/WS)
Tom Rutt: not even sure what "Web services" means anymore [scribe missed some]
Shriram Revankar: don't care whether it's Web
services or REST, we need to know how to manage it
... technologies within W3C could be leveraged, e.g. RDF
... need tools to manage proliferation of services
Chris Ferris: IBM, HP, Intel doing unified
management
... going to take a while to get higher up in food chain (DMTF)
... reiterate Hugo/Paul's earlier point; STOP and get what we've done already
to interoperate
Paul Downey: stop writing specs, start writing
code
... BT doesn't really care how it puts a service up, so long as it interoperates
... soapbuilders did good work
... then we had a standards fest and things went wrong
... WSDM is one of a number of specs reinventing the Web
David Orchard: I suggested W3C investigate REST DL, e.g. WADL
Hugo Haas: want authentication solutions
Paul Downey: identity
Jonathan Marsh: WS-Core! And interoperability.
Chris Ferris: maybe they could be together
Mark Nottingham: let's not do to HTTP what was done to Web services
<Paul Downey> +1 to Mark Nottingham
Mark Nottingham: W3C is a vendor driven organization, and that gives certain results
Nicholas Gall: did I hear that every Web services should support GET?
Skip Snow: no consensus
... are you saying all Web services should support an HTTP interface?
Nicholas Gall: [scribe summarizes] pretty much
Ken Laskey: should we make CRD operations easily accessible from underlying protocols?
silence
David Orchard: need better binding of SOAP
based services to the Web
... goal of workshop is to provide recommendations to W3C
... e.g. REST DL
Noah Mendelsohn: I wasn't saying all services
should support GET
... every time we say "don't do", risk turning people off
<Paul Downey> "SHOULD" sounds about right. "MUST" would turn people off.
Noah Mendelsohn: people should ask themselves what the tradeoffs are
Skip Snow: if W3C wants to help finance
industry, need practical "tomorrow" help ... to bind to FTP, to bind to
JMS
... all the other stuff we talked about today is great, but it doesn't
provide us the low hanging fruit
<Paul Downey> suggests Skip writes an FTP binding and submits it to the W3C as a member submission
Shriram Revankar: how do we manage creation,
query of services?
... discovery
Chris Ferris: related to what I was trying to describe earlier about management
<Paul Downey> that's only because his experience is there are many ways to pass messages using FTP, it's not as constrained as MQSeries or JMS
Chris Ferris: discovery too
Shriram Revankar: W3C should provide document management construct that can be specialized to multiple verticals
Nicholas Gall: soften my stance. change to;
have W3C reminds users that Web services are more valuable when accessible
from the Web.
... don't have to do it. just more valuable if you do.
Noah Mendelsohn, Nicholas Gall: at the same URI
Tom Rutt: re create, PUT may not be suitable for some creations
Ken Laskey: nothing works 100% of the time
Mark Nottingham: if it doesn't get built into products, it doesn't matter; standards organisations don't solve the problems themselves, they're a venue where people need to agree upon solutions and follow through.
Ken Laskey: can we get the users together to gather requirements for vendors?
Mark Nottingham: don't know. didn't work in
WS-I
... worth a try
Paul Downey: process question: what are we doing with the list Ken's building?
Ken Laskey: working up to suggestions for W3C
Hugo Haas: tools to generate documentation and code
<Paul Downey> hears more WADL love
Ken Laskey: can we get users together?
Chris Ferris: big believer in user input. they
can't always get agreement.
... bigger need for WS-Core
<Paul Downey> yeah, we want one number to call
Ken Laskey: what would the output of such a group be?
Jonathan Marsh: errata, maintaining a forum for questions, test suite maintenance, interop events
Chris Ferris: +1
Glen Daniels: could also do public endpoints, automated testing tools
Tom Rutt: standardize other protocol bindings
Jonathan Marsh: define a profile of XML
schema?
... probably don't want to do profiles, but who knows
Noah Mendelsohn: lots of people saying databinding is their pain point
Tom Rutt: need to ensure W3C has adequate resources to do what needs to be done
Ken Laskey: can we do a subset?
Tom Rutt: need success model
... why bother if we can't meet it
Skip Snow: need reference architecture
Shriram Revankar: best practices, bad practices
Ken Laskey: should WS-Core be top priority?
Chris Ferris: needs to be IP free
... should be #1 priority
Robert Freund: need a place to push specs when they're done
Hugo Haas: interop around XML schema helps both REST and WS services
<Paul Downey> WADL also uses XSD to describe message contents
Noah Mendelsohn: need for schema profile coming out of this meeting is unmotivated
Robert Freund: interested in Web/Web services
for W3C, resources for each, etc..
... does W3C want to be associated with Web services?
Note: the following list was constructed during the discussion:
Note: The numbers in paranthesis indicates the numbers of individuals who voted for an item and the number of individuals who voted against an item. Each individual had the choice of voting for a maximum of two items and of vetoing a maximum of one item.
Ken Laskey: report will ask for strategic direction from W3C at next AC meeting
Eric Newcomer: thanks to MITRE and Ken for hosting