W3C Workshop on Web of Services for Enterprise Computing

27–28 Feb 2007


Mark Baker, David Booth, Anthony Bradley, Glen Daniels, Paul Downey, Jacques Durand, Kinga Dziembowski, Christopher Ferris, Robert Freund, Hugo Haas, Marc Hadley, Chuck Hinson, Peter Lacey, Yves Lafon, Ken Laskey, Philippe Le Hégaret, Jonathan Marsh, Daniel McCue, Noah Mendelsohn, David Metz, Benjamin Moreland, Benjamin Carlyle, Karen Myers, Eric Newcomer, Gall Nick, Mark Nottingham, David Orchard, Kimberly Palko, Balaji Prasad, Shriram Revankar, Tom Rutt, Marwan Sabbouh, Rich Salz, Paul Sandoz, Salim Semy, Skip Snow, Davanum Srinivas, Kurt Stam, Steve Vinoski, Ravi Chander, Michael Versace, Thirunavukarasu Sivasubramanian, Steve Bratt
Ken Laskey, Eric Newcomer
Karen Myers, Paul Downey, Chris Ferris, Karen Myers (again), Shriram Revankar, Glen Daniels, Jonathan Marsh, Mark Baker


Welcome and opening overview

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

Toward a Hybrid Solution for the Web of Services, Eric Newcomer, IONA

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

Enabling Service Oriented Architectures for Disadvantaged Users, Semy Sabbouh, MITRE

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

Web of Services for Enterprise Computing: A Position Paper, Shriram Revankar, Xerox Corporation

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

An Insurance Industry Perspective: Making the Web of Services Real, Benjamin Moreland, Balaji Prasad, The Hartford

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.

The need for a general context definition in Web Services, Kurt Stam, Redhat

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]

Dynamic Service Discovery, Kinga Dziembowski, Gestalt, LLC

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

Increasing the Interoperability Basis for WS-*, Jonathan Marsh, WSO2

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

Financial Services Technology Consortium Position paper, Michael Versace, FSTC

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?


Points from the Day’s Discussions

<Benjamin Carlyle> My main points of the day:

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.

Open Discussion Points

[Second day starts]

Services on the Web and Web Services, Paul Downey, BT

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

Why the Web? Mark Baker, Coactus Consulting.

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

Web Services in a Web Company, Hugo Haas, Yahoo!

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/

RDF and SOA, David Booth, HP

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]

BEA Systems Position Paper for W3C Workshop on Web of Services for Enterprise Computing, David Orchard, BEA

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?

Why Can't We All Just Get Along?, Glen Daniels, Progress Software

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.

IBM Position for the W3C Workshop on Web of Services for Enterprise Computing, Christopher Ferris, IBM

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.

W3C Technical Architecture Group White Paper for the W3C Workshop on Web of Services for Enterprise Computing, Noah Mendelsohn, W3C Technical Architecture Group

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?


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:

What needs to be fixed?

Prioritization of recommendations to W3C

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

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/06/08 21:09:51 $