Hello, and welcome to another in our podcast. series covering topics around WebSphere Messaging and

Transcription

1 IBM Podcast [ MUSIC ] Hello, and welcome to another in our podcast series covering topics around WebSphere Messaging and Integration. This is Leif Davidsen, I am the product manager for WebSphere Message Broker. Hello, I'm Andy Piper. I'm the WebSphere Messaging Community Lead from IBM's Hursley laboratories. Thank you, Andy. Today's podcast is, Using a Registry and Repository with WebSphere Messaging. Maybe what we should do to get started is find out what is a Registry and Repository, and what's the point in having one? Yes, I guess a clue's in the title there. So, a Registry and Repository is a place where you can register the assets. Typically these are in this case services assets, and we mean kind of Web services and applications, what they are, what you have in your business, and acts as a kind of store for them, right? So that's what the repository side is. So, it's a place where you store and register and record your Service-Oriented Architecture assets. -1-

2 Do we have a solution in this space? Yes, we do. Yes. It's called WebSphere Service Registry and Repository, funnily enough. That sounds like a fascinating name. So, I can see that having Registry and Repository might be useful. I can certainly see that as I grow my number of services, having somewhere to store them would be a good idea. Now, let's apply this to if I'm actually using messaging with WebSphere MQ in my enterprise. How can WebSphere Service Registry and Repository be useful in that case? That's actually a good question, because typically when we start to look at a service registry, we start to think, oh, Web services, that means WSDL, Web Service Definition Language. And that means HTTP, because the most likely binding for a Web service or a service is going to be initially over HTTP. Now, there is also the ability to provide bindings for JMS applications, and something that IBM did was to provide a definition which says actually, we can start to treat MQ applications as services. And we have a WSDL schema which enables us to treat MQ endpoints as services. So, if I have WebSphere MQ and in particular if I have a -2-

3 version of WebSphere MQ Version 7, the Explorer has the capability to have a user wizard to define our existing MQ assets as services. So, for example, I might have a particular application that has an input queue and an output queue, and it might expect to receive data in a particular format. So, I'm asking for a customer record, I parse in a customer number. I get back a piece of XML or even a fixed format message which contains the customer record. And if you think about it, that's exactly the same as an interaction with a Web service as a request response on a Web service. So we can start to use the wizard that comes in MQ Explorer to create that WSDL file, and then we can take the WSDL file generated and we can import that into our Registry and Repository. And that enables us to start to locate, query, catalog MQ assets within our Registry and Repository. So, it sounds like if I'm moving to try and reuse more of my assets, particularly more of my MQ assets, this is a good use of being able to define and reuse my MQ assets rather than having them locked up in applications. Definitely. So, one of the problems that people often find is that, okay, we've got this MQ -3-

4 infrastructure and we've got different applications listening on queues. But we don't know what they do, we don't know how they interact with one another. This gives us a way of starting to treat them as more formal services, and it enables us to find them. The first step to really making the best use of an agile infrastructure is the ability to find out what services and capabilities we already have via a catalog like a service Registry and Repository. So, as you said, yes, it's a good thing, particularly to try and make more use of things. Is there anything else that can be done if I'm using service registry with MQ? There is. The service registry has a nice Web interface, and that has the ability to administer the Registry and Repository; also to query it. But one of the other things it has is some impact analysis tools. And what that will actually do is to start to discover dependencies between different systems and services, and for example, to visualize what would happen if you made certain changes. One of the things that you can do is you can start to apply those impact analysis and visualization tools to your MQ assets. For example, you can start to find out how -4-

5 different queue managers queues and channels interrelate to one another. It does sound like real and immediate benefits can be achieved by using the WebSphere Service Registry and Repository with MQ, particularly if you've got an extensive infrastructure already in place. Now, what about if I'm also using WebSphere Message Broker? That obviously is another piece of the infrastructure. Can we use Service Registry with that as well? Of course. Again, WebSphere is a family of products, and it's really important for us that we make sure that they work nicely together. The ESB actually probably has even greater benefits from having a service Registry and Repository. Message Broker has a couple of nodes for directly interacting with WSRR, the Service Registry and Repository. It has an endpoint lookup node and a registry lookup node. Now, the registry lookup node will enable us to query any object in the registry and just get back a full set of information. So that could be an XML schema, it could be a WSDL file, it could be anything that we can store in the registry. And it's a very rich capability to store information. -5-

6 The endpoint lookup node, though, is much more focused, and what that will actually do is actually query and ask for the current binding information, the current location, the current HTTP address of the Web service. So, for example, I can have a payment system, and I could decide that for various operational reasons I need to move it from one server to another. Or, I could decide that certain types of customers need to be redirected to a different system perhaps through an acquisition or something, some infrastructure change. By including an endpoint lookup node into our flows before we actually use the SOAP request or HTTP request node, we can dynamically update the endpoints of those nodes' queries. So we are really building a lot more agility into our infrastructure by combining these products. It certainly sounds like you can have a much more agile and indeed dynamic infrastructure. Obviously, one of the aspects of defining everything may be in relation to governance. Now, the term "governance" means different things to different people, but I think to some people it means a lot of overhead and hassle. Yes, so governance is a great thing for...if you're a business person, you'd love to know that everything -6-

7 in your business is catalogued and understood, and you know the value of it, you know how often it's being called and so on. I mean, I'm a techie, and honestly, my first reaction to that word is often, oh, dear, this is going to stop me from doing cool things. But if you actually think about the benefits you get from having this repository, they actually start to outweigh the fear. For starters, the Registry and Repository comes with Eclipse plug-ins, which from a developers' point of view enable you to query the registry and very quickly pull in information. So, if I'm a flow developer and I've been asked to invoke that payment system we talked about before, then I can really quickly go into my Registry and Repository plug-in in the Message Broker toolkit to find the payment system, import the WSDL file and the service definition. And then it's a really simple case of dragging and dropping that on to a flow canvas to create a proxy to invoke that service. So, you know, the actual productivity of doing that is immense. Operationally, it's also extremely valuable because we can start to find out what we did have and where those things reside. So, it does sound like this is actually a win -7-

8 for everybody, both the business people do get some of the governance that they want, but there are specific benefits for developers when using it in this way. Absolutely. That's our goal here. It's a product which has benefits to the business, to the infrastructure guys and to developers. So it's definitely something that's worth thinking about in the context of a messaging infrastructure. I think we should start to see more and more people getting interested in this as they get more services in their business and they start to need to manage them more effectively. So, where should listeners go to find out more about this? Probably the best place for more information would be both the MQ and the Broker info centers which contain information about the specifics of support for those products and integration with the Registry and Repository. And I would also suggest that on developerworks there are some good articles about the topics we've discussed today about integrating in particular Message Broker with Registry and Repository and performing dynamic service lookups. mqseries.net of course is a great community, and there's -8-

9 lots of users there who are sharing their own experiences with the products and asking questions and getting some informal support from us as well. So, that's a good place to look. Thank you, Andy. I know other places to follow would be yourself on Twitter as well as various other sites. That would also be the IBM WMQ and the IBM Broker accounts on Twitter, of course, as well, as very useful accounts to follow for up to the minute real-time information. Thank you, Andy, for another very informative and useful talk. I think that was a particularly good topic for hopefully all of our listeners. And I hope they enjoyed it, too. IBM Podcast [ MUSIC ] [END OF SEGMENT] -9-