I am Stefan Tilkov at QCon and I am talking with Paul Downey. Paul, can you start by telling us a little bit about yourself and what you do?

My name is Paul Downey, I am a chief web services architect at BT. Over the past few years I have been involved in the standardization around web services, and I am also quite passionate about the web. I also have another role at BT which is to expose some of our services in a way that excites developers.

I guess we are starting with the standard side of things. Why do you think these are important, why is BT involved in these type of things?

Standards are really important to BT because we are not really selling tools and technology, we are selling services. We want our services to be exposed in a way which reaches a very wide market place, and can be used by lots of different people in a lot of different ways. And also we have a large cost involved in the integration of systems, so standards really help us to a cheaper, faster, better integration.

Can you give us an example of pain points that standards address or should address?

There are lots of pain points, but in the web services world we are still struggling with some very basic things. The way Web services is based on meta data, in particular WSDL, and inside of of the WSDL there is the schema which describes the content of the messages, that's very difficult for us, especially in a data binding context. And we are also having problems with involving services. So having published a service you want to make subtle and small changes, we find that breaks interactions we have with customers. And finally, we have a lot of existing infrastructure based on MQ technology, message queue technology and we would like to be able to use SOAP over those technologies and we are not seeing a lot of help in that area for standards at the moment.

Do you see some standards and some activities addressing this?

The trouble with standards is there are just so many to choose from. The WS-* stack maps to how we thought about services within BT, in particular the message queuing stuff; there is a really good marriage between SOAP and message queuing based infrastructure. Of those SOAP has been quite useful, XML obviously is very useful, we also like to describe things in a way programmers have abstracted from ... programmers don't like XML, they want it abstracted so we thought WSDL was quite useful. Bits of WS-Addressing are being very useful to us as well.

You have been involved with something called the XML data binding activity. Can you tell us a little bit about that?

Sure, our first pain point is this notion of metadata that you want to describe, the contents and messages which can be exchanged. And the idea of that is you can build an abstraction, so data binding is all about taking a description in an XML schema and using that to map from one XML format to something else, a model. And that model can be a new XML format, something like JSON or it can be something more programmatical in terms of an object model oriented in Java or C#. We found quite quickly the tools only support different parts of Schema or small subsets of Schema. And the problem is not as much that they all support the same subset, but they all support different subsets. We quickly realized that if we published a Schema, that different people have a very different experience about Schema in different environments so we really wanted to get that standardized, or that problem space well understood and improved. We have been working hard for a couple of years trying to get the industry to look at the Schema and make sure that they all at least implement a bit of it in the same way that works well for us.

What is the actual result or this working group, what are its deliverables?

The way we are working is we are identifying patterns of use of Schema, and those can be very simple, we say "ok you use an element and it is an access type of string" and maybe they are composed in a list of things, a collection, or it's a repeated list, like an array. And those patterns are very simple. And the simple ones which work everywhere that we know about, we classify them as being basic. So if you just use schema with basic patterns you are likely to work well with large arrays of toolkits. And also we are looking at those patterns which you might call advanced, we are looking at schemas in the wild and think what is the typical use of XML Schema across schemas published by people like OASIS and Health Level 7 they say "ok, how are people actually using Schema?". And if we can collect those patterns and identify them, then at least we can have a conversation about which ones work well with tools and which ones don't work well with tools. And we are classifying those as "advanced".

Some people say that the idea of mapping XML to objects and back is the wrong thing to do in the first place. What do you say about that?

It's not something I ever do, I love XML and XSLT, I think it's great so I personally would not do that. But by and large programmers and developers want to use tools and tools by and large use WSDL an XML schema to abstract the XML that is being exchanged, into a model. I would say don't use those tools if you don't want to, but it is problematic to me to publish a WSDL if my audience wants to do that.

You mentioned that one of the reasons that BT gets into this standards things is that you want to reach the widest possible audience. Do you think that the web services stack does a good job supporting that?

It's hard to say, I think it's maybe too late to bang the nails into the coffin of WS-*. I think the WCF implementation which is being shipped with Vista could be a very interesting experiment to see how well that works in the market place. Also vendors want to work with that one particular implementation. I think we have been conservative about which parts of WS-* we use because it is still very fluid. And even within WCF there are all sorts of profiles of use. And we may find that this is going to take a long time to shake out. My personal view is I love the web and I think there's a lot you can do with web technologies. Just using the web can reach a very wide market place. But there are reasons why we are looking at SOAP in particular. They are not all technical reasons, or even market reach, they are really based on what works well with our existing message infrastructure. When we buy a product and see what they support well and often we want to not be able to place with what vendors are thinking.

So when you say that you love the web, are you talking about REST? What do you think about REST?

REST worries me, because if you use the R word, REST has a posse, as they say, and they're out to get you. If you dilute the brand then they will come and get you. I do worry about that, I would say I am more passionate about the architecture of the WWW which is a document written by the W3C TAG than I am about an architectural style which seems very rigid, which was written by Roy Fielding , a really nice document. But it's very rigid. And I think the beauty of the web is being fluid. I do think at REST as an architectural style, I don't feel very comfortable about pointing a building and say "now that's gothic, that's classical", in the same way that I sometimes look at peoples' use of the web and say "ok, is that REST or not?". Then does it matter?

Looking at the other part of your work, what are you actually doing when you are not working on standards for BT?

I work for a great team, we have this thing called Web21C and our customers are developers and we are trying to excite a market place of developers, and to do that we are exposing some boring old stuff but in a new way which programmers can make use of. So we have a website, sdk.bt.com, and from there you can download little blobs of code in Python, Java, PHP or C# and you can make phone calls and you can send text messages and receive text messages and set up confernces. One of the interesting services is locating mobile phones, give me a phone number and with a degree of trust which is established I can locate the mobile phone and put you on the map. With those things I think we can do some really exciting stuff. And the team I work with is great, we are working in an Agile fashion and we are very motivated and it is a great place to work.

What type of technology do you use when you say you deliver client applications and libraries? Do you actually use SOAP or the web internally?

I thought of saying how a job with "chief" in the title which means nothing because the environment I working is very egoless. There are some very young people who I have to convince to do things the right way. And the first audience we went for was the C# audience. It became quite apparent that a good way to get things working was to ship in a SOAP way because they have a good story there. But as we go on I'm trying to get them to understand that there are some audiences we are not going to reach with SOAP. For example Ajax, it's not so difficult to call SOAP from an Ajax environment but to use WS-Security which is what we base our security module on from an Ajax environment it's very hard. I am having a conversation with them and sometimes it is conducted in public, but just trying to explain to them the value of the web.

If you do things like locating mobile phones how do you actually handle the security and the trust aspect?

What we are selling there is a trust model, we have a service called "white label authentication". Maybe an important thing to mention is that this services are white label, if you as a developer build an application the BT brand does not bleed through your application. You can use our services and authenticate your users, you are using our authentication store or your own authentication store if we trust it, and a user of your application can then request your application to track a mobile phone. The way that's dealt with you as the user of the mobile phone is to say "Stefan wants to track you. Is this ok? Yes or no" and I can text back and say "yes". And then periodically afterwards I will be reminded that you are tracking me if you still you are tracking me. There is a large number of risks involved in that, if you think about children or do I want Stefan to know where I am half the time. We have a number of things which would reduce the worry. There's a code of practice in the industry that we are going to follow, and also we allow you to pin your location, and lie and cheat of your location if you want to. So it's really you the user that's getting the value from it. And the kind of example application might be you want a taxi, being not sure where you are, and so you text your taxi service and then they will locate you and send you a cab. It's really empowering the user of the phone not so much the user or the person tracking you.

Is this based on WS-Security?

Yes, that's one area where the web has got a little way to go over the WS-* stack. In WS-* the power of the trust model is based on certificates. That could be the same for both SOAP and the web, web can use certificates as well, but it's hard to use certificates within a browser programatically. That's one area where I would find it hard to come up with convincing arguments now, just to open things up and be more web like. One of the exciting things about these services is they entered people's lives. If I can ring you on a phone or send you a text message or locate your mobile phone, that's dealing with you as a person, in a way that a web application doesn't. So we have to be very careful in order to build our trust model on real solid foundations.

What do you see in the future of web services in the broadest sense? What do you see the web heading?

That's the beauty of the web, it just goes off in strange directions that you can never predict and it is a live thing. The web 2.0 thing, I don't like the term of 2.0 I don't think many people do. But it does capture a notion that it's people, the web is a community of people, expressing themselves and how they interact, trying to predict how a crowd is going to move, it's impossible.