Our company is in the process of setting up a SOA. We are starting to expose certain functions as WebServices for other applications to use. The services are based on webMethods flow services, which are deployed to multiple IntegrationServers. Currently we generate the WSDL manually in Developer and store this in a central location.
What is the best practice to manage these services and to provide information on them for clients? webMethods itself does not provide any further support besides generating the WSDL, or does it? Is Fabric the best way to go?
Storing WSDLs in a central location is definitely a start, but there’s still lots to be done!I think you’re on the right track with Fabric: it supports fail-overs, dynamic configuration changes, security, etc. What’s more it’s not limiting you to webMethods produced WebServices only, it doesn’t really care!
There are other ways to do it as well, by “rolling your own”. What I’ve seen in the past (not webMethods related), is a UDDI repository which categorises all WebService and points to relevant WSDLs. This is not a bad solution because your WSDLs don’t have to be physically in the same location.
There’s also lots in ebXML (repositories) that you can have a look at.
But, if must of your services are in webMethods and you’ve made the investment in the tools, I’d definitely go with Fabric!
Best regards,
Hido Hasimbegovic
CustomWare Asia-Pacific Pty Ltd
Home of WmUnit
There are also free UDDI servers available online, such as jUDDI (Apache jUDDI – Introduction). It may not be as user friendly as some of the pay tools, but it serves the same purpose.
Of course, since UDDI is still young, you can always just create a web app to provide information and allow downloadable services.
Glue 5.02 also has a UDDI server that is very easy to setup and can use a JDBC data source as the repository. I have used the WmUDDI package that comes with IS 6.x to query the Glue UDDI server to locate businesses and services and to register new services.
I hear that a standalone webMethods UDDI server offering is in the works as well.
You should get the UDDI API refrence online to explain what the fields actually do. If you google UDDI API, you will get several results that offer up the API for the UDDI services. After browsing it briefly, the services in WmUDDI will start to make ALOT MORE sense b/c they are all wrappers to this API.
The API refrence will explain what each of the fields require, what they mean, etc. Its actually fairly easy to use. As an aside, there is a WmUDDI fix you can download…it has some minor updates…nothing critical, but something to think about going forward.
As far as a UDDI server, I would recommend downloading a free version to play around with (Such as juddi that I recommend above). Others are more user friendly (such as MS and Websphere…haven’t used Fabric)
Some UDDI basics…
-A “Business” is just a container of services. You would probably have one business registered per group of services (i.e. an entire project, or an entire company)
-Each service is given a business key by the UDDI server
-Don’t worry about the ‘TModel’…that isn’t necessary when starting out