Transcript of BriefingsDirect Podcast on Open Source Web Services Stacks and WSO2's Latest ESB

Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded June 5, 2007.

Listen to the podcast here. Sponsor: WSO2.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to a sponsored BriefingsDirect podcast. Today, a discussion about an energized entrant into the open-source Web services stack and Services Oriented Architecture (SOA) infrastructure field.

We’ll be talking to WSO2. They’ve been putting together a talented team with backing from Intel Capital to create a robust, lightweight and purely services- and standards-based stack and infrastructure offerings.

With us today to discuss their approach and philosophy to open-source and Web services support -- as well as a new product from WSO2 in the enterprise service bus (ESB) market -- is Paul Fremantle, vice president of technology at WSO2. Welcome to the show, Paul.

Paul Fremantle: Hi, Dana, nice to meet you.

Gardner: Glad you could be with us. Also joining us, a senior analyst from ZapThink, Ron Schmelzer. Welcome to the show, Ron.

Ron Schmelzer: Thank you for having me, Dana.

Gardner: Ron, you cover the field of SOA very closely. You’ve seen how both the commercial and open-source approaches have been churning over the past months and years. I wonder if we could just start the discussion with a level-set about open source and SOA.

I’ve been impressed with the fact that SOA is creating early-on an environment, in which open-source products are, in a sense, defining feature sets and approaches. In the past, we saw commercial products establish niches and define infrastructure areas that then became areas that open-source products might pursue.

Do you agree with that? Do you think that there is something new and different going on with open source and SOA?

Schmelzer: Well, there’s certainly a role for commercial software vendors, which are obviously having a huge impact on the space. It’s very hard to ignore what IBM, BEA, Microsoft, Oracle, Sun, SAP, and all those guys are doing in the space, as well as legions of smaller vendors and niche-focused vendors who are commercial.

One of the things that makes SOA different from CRM, ERP, or even traditional enterprise-application integration is that SOA is architecture. It’s a style, an approach, or a methodology for building loosely coupled, composable services that meet the needs of the businesses. So it doesn’t really demand a particular technology stack.

As a matter of fact, people can implement SOA using a very wide variety of technologies, which they probably already own. There are a lot of case studies on SOA for legacy and mainframe implementations.

So there is a significant role for open source to play in this market, given that one of the major roles that open source plays in general in IT is as an equalizing or commoditizing force for various technologies that have already made their way, and where people already understand the technology's capabilities or requirements. Open source has, to a certain extent, made that technology a lot more accessible.

Of course, the other part of open source is that it has rapidly accelerated the pace of software development through much more iterative, short-development cycles, [and] some large vendors simply can't keep up with that pace. So there is a certain role for that.

Gardner: SOA, by definition, is inclusive and supports heterogeneity, and those also are foundational notions for open source.

Let’s go to Paul Fremantle. First, give us a little bit of background for those listeners who aren't familiar with WSO2. Give us a quick rundown on the company. You’ve come from a background of standards development and a long heritage at IBM Research and product support. Tell us the story of WSO2.

Fremantle: Certainly. WSO2 was founded in August 2005. The three founders were myself, Sanjiva Weerawarana, and Davanum Srinivas. We’d all worked very much on the Web services stack.

Sanjiva was one of the leads on all the standards on Web services at IBM, and his name is on many of the documents.

I was one of the product development leads at IBM where I integrated the first SOAP support into the WebSphere platform. I built a key component of some of the WebSphere features known as the Web Services Invocation Framework, which was used heavily in the BPEL orchestrator and other parts of the stack, and which had a lot of influence on the SCA and JBI specifications. Also, I led the team that built IBM’s Web Services Gateway, and was one of the key members of the ESB development team there. So we had a very strong background.

The third partner, Davanum Srinivas, was in the CIO's office at Computer Associates and was very involved in Computer Associates' Web services stack. The other thing that tied us all together was that we all had a strong involvement at Apache Foundation.

Gardner: You’ve developed a philosophy of approaching this from a "pure" perspective. That’s to say, you don’t have a legacy to support or preserve. You’ve looked for a clean, simple, lightweight, REST-full approach, supporting AJAX-based Web applications. How did you switch from a commercial and proprietary mentality? And what drove you to this current philosophy that you’re supporting?

Fremantle: One of the things you see again and again in the computer industry is that people get to a point where they layer technologies on top of each other, and then it just gets too heavyweight. The benefits of reusing that old stuff are outweighed by the disadvantages. And the point at which that happens depends on the technology.

We were very involved in open standards and in writing and implementing the specifications, but many of those implementations were layered on top of the Java EE enterprise runtime. We found that there was a whole new middleware based on XML and self-describing messages based on simple HTTP communications that didn’t need the existing EJB/Servlet runtime -- that didn’t need to have all those existing layers.

So our philosophy when founding the company was to look at stuff afresh, and to build things with the simplest, most-lightweight combination possible. We tried to target users' requirements, rather than target an existing code base and legacy solution than we might have if we were working for a large company.

Our motivation was to do exactly what’s needed. There is a little synergy there with most open-source projects. Open-source projects tend to be small, componentized, and to try and solve specific needs. They work best when there is that lightweight aspect to them.

Gardner: Yet, at the same time, you’re being ambitious. You’re integrating widely with your stack, integrating to Microsoft .NET and the Windows Communications Foundation, formerly Indigo, with also full connectivity to the Java EE environment, even back to CICS, SAP, other Web services standards, and IBM WebSphere. It seems like you want to be neutral as well.

Fremantle: Certainly. This comes back to what Ron was just saying, which is that SOA is about working with everyone equally. It’s not about having a proprietary stack. As we talk about an ESB approach, you will see that one of our key tenets is that we’re not layering interoperability at the edges as adapters onto our stack, which is what you see a lot of people doing. We’re building interoperability into the heart of all our code. So naturally we want to have as wide an interoperability as possible.

We also think there is a critical mass here -- that we need to be ambitious. We need to cover not just the Java platform but also the C, Perl, and PHP -- the full gamut of platforms. SOA is not just a Java story. It’s really a cross-platform, cross-technology standard.

Gardner: Many of us are familiar with blogging and we know what can happen in the comments fields when we post things. I want to get this upfront right away. Many times when I blog around open source and SOA and how they relate to one another, there’s inevitably the comment about, "Well, how do you make a living at this? There are an awful lot of resources being devoted to something that is not your intellectual property."

Let’s go right to that and address your business model, and perhaps the role that systems integrators and support will play in how this is driven successfully into the market.

Fremantle: Absolutely. First, we’re a completely open-source company. We do everything under the Apache license. We don’t have any kind of "gotchas," different versions, relicensing and so forth. Our revenue stream is made out of our support to customers, selling support contracts, and providing a highly professional, enterprise-class support for both the Apache open source [Synapse ESB, for example] offerings and our own products.

Secondly, it’s made out of services and training, consultancy training, and custom development.

Finally, we also have partnerships, mostly with other technology companies who embed our technology and also with system integrators and ISVs who then use our technology to build solutions for their customers.

Having worked in a highly commercial proprietary software development shop, we know that support, services, and getting code that works is actually what really counts in the software industry.

Gardner: That’s the long-term play. You look to lose some revenues upfront on licensing, but [rely instead] on what’s going to sustain the company over time. It's that long tail, if you will, of support and maintenance.

Fremantle: Absolutely, and I see the software industry moving in this direction. What you used to see was that companies would put together a kind of magic package, which was intellectual property, plus support, plus training, plus everything. And somehow they’d value all of this at some astronomical figure.

You’d see middleware sales of multimillion dollars. What we’re saying is that the software industry can’t maintain those levels of cost. Better value, open-source software is the way to go. Obviously, open-source companies have to make money, both for our own livelihoods and also because the users of open source need that commercial infrastructure there to make sure this works for them in the long term.

Gardner: Another thing that you are taking advantage of is globalization. You have a distributed company. You’re taking advantage of development resources where they are, rather than where you’d like them to be, and you’re using Apache and open source as the governance over this development process. Tell us quickly a little bit about what that means in terms of efficiency and depth.

Fremantle: Well this is a very interesting story because we're a company that has offices in the U.S., here in Europe where I'm located, and also in Sri Lanka. These locations all actually came out of a growth of open-source developers in Sri Lanka. So in many ways I feel like I’m the outsourced guy because I’m the European offshoot for a bunch of smart developers based in Sri Lanka who are really driving the direction and the quality of this product. It’s not your traditional outsourcing operation at all, it’s very much globalization.

We found that the open-source model that Apache pioneered with open mailing lists, open-source code repositories, and free and open exchange of ideas on the mailing list, have shown us a way of operating a loosely coupled and distributed development team that actually works in practice. That means that I can participate in projects with people based in the U.S. and in Sri Lanka through that structure and process. That works just as effectively as when I used to work with my development team all located in the same office.

Gardner: We’ve mentioned how you are very ambitious in your scope. You’re looking for a full Web services stack. You’re producing an application server. You’re going to be introducing a mashup server. But today we’re going to focus on the ESB product that you’re going to be demonstrating and supporting for real in June.

Let’s go to Ron at ZapThink. Ron, the role and definition of ESB have been points of contention, and yet most folks that are pursuing the support of an SOA activities infrastructure market have some sort of an ESB approach. Why don’t you give us a level-set, if you could, on the state of the ESB market, why it’s essential for SOA development and maturity, and what you think is the proper functionality -- or perhaps your philosophy around ESBs?

Schmelzer: The place to start is that an ESB is actually not specifically necessary for an SOA. However, there are a lot of things that people require of their SOA infrastructure that a lot of vendors, who are pushing ESB products, are selling. The challenge of the market is that you can't really take any two ESB products, as you did J2EE application servers, and compare them to each other and see a very large overlap of functionality.

What you will find is that a lot of the ESB vendors are basically taking the infrastructure technology they had prior to the SOA wave and have applied Web-services technology or perhaps business process composition on top of that to run services, which is what people are looking for.

If I have a service, I need to be able to execute it reliably. I need to be able to secure it, manage it, govern it, and deal with the metadata. That’s what people really need from an SOA infrastructure -- all that capability. How do I reliably run, secure, and manage those services so that the loose coupling that I am looking for actually can exist?

To that extent, the ESB is really a catchphrase or a catchall for a wide variety of SOA infrastructures. If we look at the capabilities of the WSO2 ESB, it’s providing a lot of that SOA infrastructure capability. I don’t know if we’re ever going to get to a point in this industry where there will be a standardization of the ESB term. There are just too many forces in the industry that would basically try to own that term and not really make that happen.

Gardner: Let’s switch over to Paul again. You have described your offerings as middleware for Web services. In a sense, you’re starting from the perspective of this not being in a distributed-object environment, but more in an XML and semantic environment. Tell us what your requirements were as you started approaching this ESB project?

Fremantle: Actually it’s interesting listening to Ron, because what we were aiming to do was exactly what Ron says, which is not focus on what various players call their ESB technology, but instead on the requirements that someone needs for their SOA. Those are exactly the things that Ron talked about: managing your interactions, being able to turn on and off security and reliable messaging, being able to manage the quality of service that the message has as it flows across the network, being able to bridge between some mismatches, and managing connectivity.

For example, maybe I have a lightweight AJAX interface, but I already have a SOAP backend. How can I switch between that REST-like XML or HTTP interface and the SOAP interface? How can I switch between an existing JMS network and a .NET Windows Communication Foundation, SOAP reliable messaging, secure endpoint?

Then, finally, there's some level of transformation that often needs to go on the network, and that’s typically what we would call low-level transformation -- things like version management, switching namespaces on XML messages, or switching some XML formats.

Those are the kind of things that we saw a real need for. We took a kind of a different vision of what an ESB was from many of the vendors. A lot of the other vendors in the marketplace had some existing technology. They either had a JMS engine, and they said, "Okay, we’re going to rebrand our JMS engine as an ESB." They had a traditional message-oriented middleware product. Or in the case of JBI, they say well, "We’ve got a JVM. So, what’s the bus? It’s a JVM."

We took a much broader view to say that the bus is really all of your XML, HTTP, and JMS -- all of your communications -- and it encompasses a variety of clients and servers and different endpoints. So what do you need in that space? You need a very smart and simple mediator that can fit in, without disturbing those existing systems, and add those levels of management, connectivity, and virtualization that I was just talking about. That was really our plan and our approach to this space.

Gardner: What would the message be to developers? You’ve created a developer portal associated with your website for your company. As developers are scratching their heads and trying to determine what they want to do with SOA and how they want to produce services, what is it about your ESB that might be of interest to developers vis-à-vis some of the alternatives?

Fremantle: The first thing that’s of interest about our ESB to developers is that it’s very, very quick to get going. It’s the sort of thing that I think developers like. There is a 30MB download. You download it, you unzip it onto your hard drive, and you switch into the bin directory and start it up. You point your Web browser at it and you can start configuring and managing it straightaway.

The second thing is that it can add some instant value, even in a very simple scenario. Some things you can do very quickly. For example, you can interpose it as an HTTP proxy, so you don’t even have to recode any of your clients to start using it.

You can turn tracing on and off selectively. For example, perhaps you have a production environment and 99 percent of the time everything is working fine. But every once in a while you get an error and you need to help figure out what that problem is. You can have the system running, switch on trace, capture traces of the failure case, and then switch it off without having to bring anything down or redirect any messages, and so forth. You can instantly get some monitoring and management capabilities, without having to do much coding.

Finally, you can start to use it to do some of the things that are quite tricky. For example, one of the common cases that customers ask us for comes when they have an old Axis 1.x runtime, or a .NET 2.0 runtime. This runtime doesn’t support the latest WS-ReliableMessaging or WS-Security standards, and they need to enable that to talk to a partner. One of the things you can do very simply with the ESB is switch on those capabilities. So some of those capabilities that have a reputation for being complex are now just checkbox items with the ESB. Those are some things that I think would appeal to developers about this product.

Gardner: Do you expect that the arrival of this code under the Apache license, you’re calling it ESB 1.0, is going to be used by the developers primarily as a test-and-design environment, a learning experience that will then lead to operational use, or do you see this as an operational alternative as well, right from the get-go?

Fremantle: We really see this as an operational environment. Although this is a 1.0 product for us, the core runtime of this has been in development in Apache for about 18 months. We’ve done extensive performance tests on this engine. We're really, really pleased with the performance results.

For example, one of the things we’ve done is load it up with thousands of concurrent connections to simulate the scenario where you have a sudden spike and load that your backend can’t take care of. It doesn’t drop connections, even when you load it with thousands of concurrent TCP connections.

Similarly, we’ve done performance tests of how much overhead this adds to the path. For a standard 1K in, 1K out request-response message, you can add the ESB into that with an extra network hop now, and we add less than a third of a millisecond overhead.

We’ve done tests against one of the market-leader ESB products out there, and we’re twice as fast at doing XSLT processing. So we’ve really done a lot of heavy-duty testing on this. We think it’s up and ready for production use, despite the fact it’s just a 1.0 release.

Gardner: Ron, I suppose these days we’re seeing a lot more multiple ESBs in enterprise and hosting environments. Do you think we’re getting overcrowded now that we have another ESB? There are many other open-source ESBs: IONA/LogicBlaze CXF, MuleSource, and also Apache ServiceMix, and Apache ActiveMQ. For folks out there who are in this operational production environment, how do they start making sense of this?

Schmelzer: Well, I would say "vive la difference." It’s completely unreasonable to expect that an enterprise is ever going to be able to standardize on one technology stack for anything. We wouldn’t need SOA at all, if companies were truly homogenous. The reason why SOA has such appeal is because there’s this continued heterogeneity. Look at all the legacy mainframe technologies that exist. Part of the reason they exist is because they continue to provide value.

The fact that there are so many new technologies in the market, open source and commercial, providing value for runtime for SOA, goes to show that companies are still looking for best of breed. No two companies really have a similar environment, either a runtime execution environment or a distributed environment. Some companies are highly centralized and some companies have divisions distributed all over the world, and in parts of the world where bandwidth and processing power are still factors and budget is a factor.

In those environments we’re going to continue to see heterogeneity. A central organization might be able to invest in one kind of SOA infrastructure technology, but their branches, divisions, and departments may invest in something else. It's the power of SOA to abstract those differences so that they’re not so visible.

If there’s one thing that we can hope for from SOA it's that it really and truly enables that loose coupling, because if we’re going to continuously try to fight this battle of heterogeneity being a problem for IT, I don’t think we’ve really gotten anywhere with SOA.

Gardner: What now of loosely coupling, but across multiple ESBs? Is that going to require some way of federating among those ESBs or would it be an uber-ESB on top of them that you will use? What sort of scenarios do you expect?

Schmelzer: That’s a touchy subject. I believe the middleware-for-middleware approach is fundamentally the wrong approach. We’re seeing some companies saying, "Hey, put our ESB on top of your ESB," or "Let’s get some sort of magic integration middleware that basically integrates ESBs." That’s the old school, tightly coupled approach of managing heterogeneity.

I thought that the promise of Web services and SOA was that we could expose loosely coupled service interfaces, so that the infrastructure that runs those services doesn’t matter. The idea that you would need proprietary integration middleware to integrate other integration middleware is, in an SOA concept, a ludicrous thought. We should be able to architect our services so that the infrastructure matters less than it used to.

That being said, we do need infrastructure to run those services. Everything that WSO2 is doing is facilitating the running, execution, and, of course, management of intra-service communication, where you’re trying to manage some of that heterogeneity. A lot of stuff they were talking about in mediating protocols, and all that, is specifically to isolate services from having to worry about the runtime environment. Trying to overlay a heavy proprietary integration middleware stack on top of what is primarily another integration middleware stack is fueling the problem more than providing a solution.

Fremantle: Can I add something to that?

Gardner: Certainly.

Fremantle: I have to agree with Ron. I don’t think that the answer here is to have multiple proprietary ESBs and then some kind of uber-ESB between them. One of the things we tried to address, both in the Apache open source [Synapse] and in our own product, was making this product something that was really invisible to the rest of the world. You can almost think of our ESB as being a smart network router. You can have multiple versions of these around the network.

One thing we’ve done is to allow the ESB to run off of a set of metadata and configurations that’s remotely managed. It could be in a registry, it could be in an SVN repository, or it could be on a Website or a file system. Multiple brokers can fit in the network and communicate with each other, but they could also communicate with completely different systems.

This comes back to what I was saying earlier. To us, your ESB is the totality of all your different networking and service-oriented systems, whether they’re .NET, Axis 2, WSO2 application servers, or ESB nodes. It’s really about using open standards and open metadata -- things like WSDLs, XML schemas, URLs -- as your foundation of integration, which means that you don’t really end up with this problem of multiple ESBs that don’t communicate. You end up with a single fabric that’s completely based on standards, and you happen to have some useful management endpoints within that fabric.

Gardner: Both you and Ron have mentioned that word "management," and we discussed earlier how you have a lot of ambition in terms of the scope of your development activities. Yet you’re also very interested in partnering, as I understand it, and that would include areas for management, and registry/repository. Can you give us a little bit of your philosophy about how this fabric would work, using both your approach as a fairly robust and complete stack, and also partnering with other componentry?

Fremantle: Absolutely. First, we have built internal registry and repository into the ESB, but it’s our first step in this and what we’ve built in is a pluggable interface that allows us to talk to other registries and repositories out in the network. Because we work off a lot of those standard metadata types, such as Web service policy documents, Web service description language documents, HTTPs, URLs and so forth, we can really work in a very open manner.

At the moment, the kind of interface we use to talk to our remote registry is just an HTTP interface, but there is no reason why, if we get the demand, we wouldn’t write to an UDDI interface. It's just that none of our customers have asked us for that today.

We also see the Web service management and governance space as becoming very important here. At the moment, in the Web service management space there's a bit of a problem, which is that there are two competing standards. There's been some work to merge them, but that hasn’t been completed yet.

So, what we offer in our ESB is some simple, so-called REST-based interfaces to get at management information that customers can utilize in the same SOA manner that they utilized in the other services to help manage and monitor their service interactions.

As the Web services management standards start to tighten up a bit, we certainly expect to partner with other companies who provide WS-Management consoles to allow people to manage their network through our interfaces.

We also offer a very lightweight AJAX-based GUI that comes with the product, and which allows you to monitor, manage, and control your service interactions across the network.

Because all of our code is built on these open standards and open interfaces, once again this a heterogeneous story. This is the beauty of open sources. Although as a company, WSO2 is trying to provide to our customers the most useful components that we see, those components naturally and inherently interoperate with other vendors' software, other open-source projects, and other components.

Gardner: Given this flexible use-it-in-many-ways and enter-the-market-in-many-ways approach, I wonder if we could look a little higher up from a business abstraction point of view. What will systems integrators look to as they pick best of breed, and as they pick a stack, and as they factor how to manage what’s on-site in the organizations they’re working with?

I suspect that you want to be a very good partner to these integrators, as they inject SOA activities into the way that they produce code, services, and applications -- and then also take that into the enterprises that they’re working with.

How do you see this whole systems integrator movement toward SOA shaking out, and how do you make yourselves appealing to them?

Schmelzer: SOA offers an interesting opportunity for systems integrators. They formed a large part of their business, at least in the late 1990s and early part of this decade, doing a lot of the heavy lifting of integration, actually making systems work together, facilitating the systems, implementing enterprise applications, and things like that. SOA gives these folks more of an opportunity to focus on the business than they had before and provide a higher margin of services around business process.

[SOA] allows these system integrators to focus on things like building shared services and business services that reflect the business needs, and focus on governance, policy, and enterprise architecture, which is a missing skill set for most enterprises.

Actually this gives systems integrators a good opportunity to let the opportunity of focusing on the business exceed the opportunity of focusing just on implementation and infrastructure, which is migrating overseas anyway. So there are some unique opportunities here for systems integrators with regard to SOA.

Gardner: How about that, Paul? Throwing more warm bodies at the problem probably wasn’t a good idea to begin with. Now you can’t even get the warm bodies in many cases. The goal should be to work smart not hard, I suppose. How do you take that message to the integrators?

Fremantle: We’ve had a lot of interest from system integrators. We formed some partnerships with some of them, and we’re ongoing with that process. What we found attractive to system integrators is that they now are looking much more for simple, lightweight components that work straight out of the box -- rather than large complex solutions.

Part of that is exactly what Ron’s talking about. These guys haven’t got huge amounts of time, so they need something that they can get on with and be productive with instantly. That’s the first thing.

The second thing that system integrators look for is extensibility and flexibility. One of the things system integrators want to do is to add value over the core products or components that they find. We’ve been very careful with the ESB and also in the Apache projects that we work on to create the right plug points.

It’s very simple to extend our ESB just using simple scripting language. For example, you can use JavaScript, Groovy, and Ruby -- those sorts of languages. If you use Ruby or JavaScript, there are native XML language constructs that are called REXML and E4X that you can use inside your code to do really simple, high-quality XML transformations or manipulations. That’s the first level of integration.

The second level is to jump into Java and actually write Java classes. That can be very productive and a way that you can extend the ESB with custom functions.

Then there's actually a third level of that. You can write your own plug-in to our XML configuration language. So you can effectively take your component and raise it up to be a first-class part of the ESB and its configuration model. That means now there can be a third-party set of add-ons to the ESB that start to add value.

We see those two things as being very attractive to the system integrators. First, ease of use -- get it started quickly -- and second gain the ability to extend it, to add extra value, and to build up a catalog of reusable components that makes their jobs easier.

Gardner: I would think that those same attributes would be of interest to companies that want to position themselves within an ecology or some sort of a supply chain, where they’re creating services that will be consumed among partners. Therefore, those same attributes that would be of interest to a systems integrator would be appealing to those enterprises that are seeking a role other than just creating their own applications and services, but rather to become a center of gravity for a larger business process or ecology.

Fremantle: Absolutely.

Gardner: We’re about out of time. This has been a very interesting discussion. We’ve been talking about the advent of new open-source products and code being orchestrated by WSO2. We’ve been talking with Paul Fremantle, the vice president of technology at WSO2. Thank you for your time, Paul. It was very engaging.

Fremantle: Thank you, Dana. It has been a great conversation and it has been a pleasure talking to you.

Gardner: We’ve also been joined by Ron Schmelzer, a senior analyst at ZapThink. We appreciate your insights, Ron.

Schmelzer: Glad to be here. Thank you for having me.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast on WSO2, open source, SOA, and the arrival of the WSO2 ESB 1.0 product in June 2007. Thanks for joining us.

Listen to the podcast here. Sponsor: WSO2.

Transcript of Dana Gardner’s BriefingsDirect podcast on open source Web services stacks and WSO2's latest ESB. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.