3 - Oisin Hurley of the STP Project

Daniel Spiewak: Hello, and welcome to the third episode of the EclipseZone Europa Podcast Series. My name is Daniel Spiewak and I'm here with Oisin Hurley of the STP project.

OK, Oisin, can you tell us a little bit about yourself?

Oisin Hurley: Yeah, sure. I work for a company called IONA Technologies. We're based in Dublin, in Ireland. I've been in IONA quite a while, and we basically started off developing CORBA software, and then we moved into J2EE web services. And now we also produce software that's related to SOA. Both SOA runtimes and the SOA repository.

I, myself, started off with distributed object systems and compiler technology way back when. And I guess it was distributed object systems research that I was working in that kind of brought me to the CORBA fields. And that's what I enjoyed when I started working there.

I've mostly been a technologist, although I have spent quite a bit of time working in the areas of standards too. So, I've worked with the OMG at the JCP and the W3C and, most recently, I've worked with the Service Component Architecture Consortium in defining a new SOA standard about how services and service components may be defined. Acting in a various programming line, which is constructed and has policies associated with them. That's recently moved to the OASIS standards body.

I've also got some experience in mobility software developing for mobile phones and disconnected systems and imbedded systems too. Right now my focus is on SOA-related projects, of which STP is one of the major ones.

Daniel: What prompted or inspired your work on STP?

Oisin: Well, at the inception of STP, and just before then, we were looking at this area. The existing tools that were available in the open source arena provided a means for people to develop web services.

So, for instance, if you looked at WTP for example -- which is a very important and very well-known Eclipse project -- you see in there all the technology pieces that you need to develop web services developed from WSDL, develop and generate code from those. And you'll also see code there to deploy to well-known containers like Tomcat and the various J2EE containers.

When you're developing in SOA, though, there's a bit of a level-up, the constants change a little bit and creating code for services is only part of the story. For sure, it's very important, and for sure, the development of the service interface, the bindings and configuration that go with that. Absolutely vital.

But they're only one part of the story. A SOA developer is a kind of a mythical beast. There isn't just one kind of SOA developer. If you're in an organization that is going to use SOA to develop solutions, this is something you want to push across all of your staff so that when they develop solutions for your business, they use the SOA design metaphors to do that.

Then what you need to do, is you need to include the people that not just work on developing the code, but you also need the people who work on other aspects: the process flows, the business requirements and testing the monitoring.

There's an awful lot more to it. And so, in the SOA area over the past few years, there's been some new things that have come on the scene and have become important points for vendors to hit when they're trying to sell products.

And these things include things like policy, to be able to construct design and runtime policies, creating and validating them and tying them to implementations. Effectively, what you have there is a system whereby you can make and formalize a statement of intent and see it carried through to a real-life operation.

Another thing that's on the scene right now is a repository, a place which acts as a system of records for storing things like process flows, policy schemas, reusable elements of your service-oriented architecture. And that can be viewed and reused.

Repository and registry are two words that go together nowadays. Registry, many people will be familiar with, but repository is something that has come on quite strongly now as a requirement for large organizations that want to deploy SOA.

Finally, there's a thing called assembly. This is where services are brought together to form groups or composites which allow you to define the external access to those composites. And this is something that was brought in as part of the service component architecture standards, which have been in the tube for the last couple of years.

So, a lot of those things are new, and they are built -- basically -- on top of the service metaphor. So, a lot of the existing tools that are in the open source area can get us to the ability to create services and configure them, but what they don't give us right now is a way to produce the assemblies; interact with the repository; apply, design and validate policies.

So, this is the sort of thing that the SOA tools project is hoping to address.

Daniel: OK. How do you envision STP being used? What sort of use cases do you have in mind for it?

Oisin: STP is intended to provide support through the SOA life-cycle, from design through implementation to delivery. And in each of those particular areas, there's many scenarios that need to be supported. Some of them are very different. They range from things like the top-down design of interfaces, generating code, generating tests, automation, and providing support for packaging your services and intermediaries that you've created, deploying them to the latest and greatest runtimes.

And there are new technologies in that area. For instance, STA as I've mentioned, and JBI, which is another deployment technology. And we need to be able to address the needs of developers that are using those. And we also need to be able to address things like policy model design, repository storage and business process model representation.

Of course, because there's such a huge variety of scenarios that are possible in this area, we need to trek our way through them very, very carefully, because otherwise our scope will just be too large. What we need to do is take the use cases that make sense at each turn and pay attention to our users and to our development community to see what are the particular sweet spots that they need to hit for their own sets of requirements.

Right now we have code in the area of service development for JAX-WS, Java Services, SCA Java Services, and we also have a business process modeling notation editor and an underlying component model.

These things, together with our flexible deployment architecture, fill out an initial baseline for us as the starting point for use cases and scenarios. So, for example, one of our basic use cases is to develop -- starting with WSDL -- to develop a JAX-WS Java Service and deploy it to a Tomcast container.

Another use case is to develop a Java SCA-based service, using an open source runtime code -- Tuscany -- and deploy that. So, we'll build the scenarios and we'll build the use cases as we go about. Truth be told, there are many, many different approaches.

Daniel: Sure, sure. Cool. What do you see in store for STP in the future?

Oisin: I see a lot in store for us as time goes on. For example, there's lot of code out there right now for developing and deploying JBI infrastructures. I mentioned earlier on this solution called JBI, Java Business Integration, which is a standard solution developed by Sun as part of the JCP; and right now, the SOA Tools Project doesn't have anything in that area. There's a lot of tooling code out there that does work in this area, and it would be really useful to have all that work consolidated in one place, so you can look at things like ServiceMix and Sumaro tooling there. It would be really cool if we could have that level of support within STP.

Moving up to a higher level, we also need to have a framework to allow the construction of extensible policy models. This is a vital aspect to SOA development, as companies will need to organize their expectations of behavior of the services and composites that they're going to deploy, and need to codify these in a way that makes sense, in a way that can last through the SOA life cycle.

The refined cost code generation allowed the generation of tests for validation and stuff like that, so that's really important. And yet another vital aspect is the position of APIs that can interact with systems of records such as registries, catalogues, or repositories. These are the place where large organizations store all the pieces that they expect their developers to use and re-use to put their systems together.

This is very important to them. Right now, there is some code within the Web Tools Project to interact with the UGDI registries. What we see now in that mars [audio distortion], there is a lot of consolidation, there are large organizations that are buying smaller organizations that have slow entry in the registry repository space, and it looks like now is the time to start creating tooling that can maybe make things a little bit more coherent and basically allow the organizations to have the flexibility to make choices.

We also need to support, or in some way expose the SOA life cycle, as a set of practices which can be encouraged by the tooling. We don't want to force anybody down any particular path, or if there are some fundamental aspects of a SOA development life cycle in large, which involves things like design and development, implementation, and then delivery, and it would be very useful to, in some way, embody that in the flow of the tools, which will help focus the activity of the SOA developers.

So there's a lot going on there that's really important, and there's an awful lot that we can do. So the future is very large [laughing], in terms of all these delivery requirements. There's many more things, I mean, there's generation of test scenarios, new views, the high level models, provisions of intermediaries for routing and transformation, and basically I could go on forever here.

But one key point to notice is that we will be developing all of this ourselves in the SOA Tools Project, basically because this would be a huge remiss, it may not focus on the suites lots of people actually require. And this is one of the excellent things about open source, is that the stuff that needs to be done gets attention, and the stuff that isn't quite as important doesn't get quite so much attention. So what we need to do is follow the hints and tips and directions of our users and of our development guys, to see what the problems are that they need to solve.

Of course we'll be looking at the kindness of other open source developers to contribute code in this area as well. Because as you develop software and you spend a long time doing it, you find that developing the software is one small part of the whole thing. There's so much more you have to do; you have to develop so many more tests than you have software. You should have a lot more tests than you should have software.

And if people have developed things to that extent, it's great to be able to re-use it, provided we can work the licensing, and the open source licensing works, etc.

Of course, we'll continue to build on the shoulders of the giants in the Eclipse ecosystem. Projects like the Web Tools Platform, Data Tools Platform, Eclipse Modeling Framework (well, that is the Modeling Project); I know there's, and will provide us, with a huge amount of the raw materials we need for success. STP, the SOA Tools Platform project, really kind of sits on top of every other project in Eclipse, it consumes from so many of them. So that will be vitally important as well for us.

Daniel: Do you have any tips for developers coming in to start working on the project? Where should they get started?

Oisin: Well, one of the big challenges to anybody coming into an open source project is where to start. If you're watching an open source project and you're interested in it, it's very important that you have a small, little piece of thread that you can pull to start, to get in there. And it's important that the barrier to entry is low for people.

So, with something like an Eclipse Project, Eclipse is a specialized programming environment. It's a UI platform, and there's a lot in there to learn, so the learning curve can seem very large. Certainly compared to, maybe, projects that don't have quite such a specialist bent such as some of the projects that you might find maybe in other communities like the Apache community, which doesn't require any UI sort of familiarity or familiarity with the Eclipse platform. Don't be daunted by that because, in the hill of the haunt, it's just code, right?

What I think is usually the best thing for developers to start with is to go in and take a look at some of the bugs, go and look at some of the bugzilla entries that we have. And some of these bugzilla entries can be maybe very, very complicated solutions; some of them may be simple solutions. If you want to come aboard, go and take a look at the bugzilla, maybe ask some questions about it. Come onto the list, the dev list: stp-dev@eclipse.org, and state: "I've take a look at bugzilla XYZ, I think I can have a go at it, I'll take it on," and we'll be extremely happy to help out in any way, shape or form that we can. If the documentation is not enough, we'll make more; if you need somebody to help you through some of the sessions or the building and stuff like that, that's what we're there for.

But the best way to get in there is to download the code, build it into your own Eclipse workbench, and find a bugzilla, and run it through in debug mode to see what's happening. And that will help you ramp up the learning curve.

Daniel: Any closing remarks?

Oisin: We're currently working on finding a way to make our long term plans much clearer than they are right now. We've had some feedback that our plans aren't as clear as they could be, certainly compared to some of the other projects; we've taken that feedback on boards, and we're, as I said, trying to find a way to make these plans much clearer, we'll have them up for further discussion up on the newsgroup and the websites in the very near future.

I'm also delighted to say that we've had approaches from some organizations that would like to contribute code to us, and I would like to say to other people, you know, all contributions are welcome. If they make sense for SOA Tools, please feel free to contact us on the SOA Tools Project mailing lists, the stp-pnc@eclipse.org or stp-dev@eclipse.org, and tell us all about it!

Likewise, if you have any particular requirements in the area, don't wait for us to make it up ourselves; come along and tell us what you need, and tell us what you'd like to see. And if you feel like you want to bring something to the table and work on some stuff, we'd be very, very thrilled to see that.

Daniel: OK, thank you for your time, Oisin!

Oisin: No problem at all, Daniel, great to talk to you!

Daniel: Same here.