There's no "correct" or "standard" way to do this use case. The only standard here is the UDDI specification and the interface and structures it provides.
I've seen versioning handled by adding separate services and appropriately categorizing them. I've also seen it done by storing one service but having multiple binding templates for each version (binding templates usually represent the service's access point). Binding templates can themselves be categorized (ie. you can give one the "retired" reference). This latter scenario is commonly used in the development lifecycle of a service, for example, you might have different binding templates for "test" and "production" access points. The bottom line is any client discovering services on your registry is going to have to know how to appropriately decipher the information. The returned XML is standardized but the context of the XML (not all of it really, just user-defined stuff like categories) must be known. -----Original Message----- From: BalajiG [mailto:[email protected]] Sent: Thursday, January 29, 2009 3:57 PM To: [email protected] Subject: Re: General Release and Roadmap information Appreciate all the prompt responses. Regarding my question on "Retiring a service", I meant the logical delete rather than the physical delete. I think Jeff's notion of defining an active and retired category and assigning the services to those categories will help us. However, Is it the correct or standard way to leverage the registry API/semantics? How does other users handle such use-cases? If my initial question(#5) was not clear, the use case I referred is, 1)TestWS ver 1.0 is published into registry 2)TestWS ver2.0 is published into registry 3)1.0 should become obsolete and 2.0 should be the one visible to consumers. However it still remains for historical purposes within the registry. Kurt T Stam-6 wrote: > > Welcome BalajiG, > > I'm happy to see you decided to go with jUDDI. See my comments below. > > Cheers, > > --Kurt > > BalajiG wrote: >> Hi, >> We are new to UDDI world and just starting to looking at it for our web >> services and "internal/private registry" use-cases. >> >> We have decided to use JUDDI, however I'm trying to find a few >> information >> to explain our selection. Coud someone kindly respond to the following >> questions. I looked around reference, news, release sections of juddi >> website and couldn't find the answers. Please forgive my ignorance if my >> questions are basic or if I have over-looked any available information. >> >> 1) Where do I find the future/In-progress releases of this project?(I see >> that Version 2.0rc5 was on 2007) >> > We are actively finishing up the 2.0 release which supports UDDI v2. > (I'm working on 2.0rc6 as I'm typing this). The final 2.0 release should > follow shortly after. >> 2) Any pointers to the features that would be addressed in the up-coming >> releases or roadmap of this project? (say UDDI 3.0 etc...) >> > we are also close to a jUDDI_v3 alpha release which implements UDDI v3. >> 3) Any references to customers currently using this in a Highly available >> production environment? (To help bring the confidence of IT managers) >> > among other products jUDDI is part of JBoss (and JBossESB) and Glassfish >> 4) From the getting started pdf file, couldn't find exact information as >> "How to run this registry in a clustered environment? Ours is a Weblogic >> based cluster environment. As JUDDI metadata is being stored in the >> registry >> data-store, Is it safe tot say that Installing the mid-tier components on >> all nodes of the weblogic cluster will give us a clustered registry? Are >> there special instructions to install and run it in an clustered >> environment? >> > jUDDI is stateless, having it backed by a clustered database should do > the trick. >> 5) Does the publishing aspect support the concept of "retiring a web >> service"? (Or Is it as good as deleting the model/metadata from the >> registry?) >> > Not sure what you mean with retiring (a logical delete?), anyway we do > physical deletes. Maybe you can describe the use case so we can discuss > this some more. >> Thanks in advance!! >> > Hopefully you'll get some more responses besides just mine. > > Cheers, > > --Kurt > > -- View this message in context: http://www.nabble.com/General-Release-and-Roadmap-information-tp21734460p217 36810.html Sent from the jUDDI - User mailing list archive at Nabble.com.
