I want to find many functionality similar services, and when one service failed, I could switched to the other.
Is there a repository where I could find Web services, using functionality e.g., weather forecasting?
(I heard that UDDI seems to be deprecated, but I cannot confirm for that)
#Bogdan - The Apache jUDDI project actually put up two instances:
one for demo, for which there is no guarantee your data will stay around, but it's nice to play around with it. Find the link for it at the landing page of the prod instance (it only allows me to post two links)
one for (semi) demo production purposes for which you can request a user account, and data is guaranteed to stay around. You can find it at: https://www.webserviceregistry.com. If you want the certificate to match the address then use: https://uddi-jbossoverlord.rhcloud.com, which is a less catchy address to the same instance.
Cheers,
--Kurt
There was only one notable public UDDI registry (put in place by IBM, Microsoft and SAP) but that has long been discontinued. If you are to find a public registry it will probably be something set up just for demonstrative purposes (e.g. jUDDI demo).
#JohnSaunders is right, nobody uses UDDI in the wild. Public repositories are not practical while the private ones are most of the time unnecessary, providing for a complex solution to a simple problem.
You should find (and evaluate) a few stable web services and have their endpoints in a configuration file of some sort. Call one of the services and on failure go for the others you have configured.
If on the other hand you insist on going the UDDI route, then create your own private repository and use that because you won't find a public one (others - me included - have tried and got out empty handed).
To directly answer your question, yes UDDI does support this kind of query. Basically, you'd want to use a "Inquiry API" method "Find_service", passing in a CategoryBag/keyReference that matches a known pattern for weather services with some wildcards to help you get results. In addition, you'll need a find_qualifier for approximateMatch to enable the wildcards. Part of the issue is that UDDI allows registrants to use the spec in many different ways and thus this example assumes that there is in fact a standardized way to register and tag a service as providing weather information. It's up to the governance process of the organization hosting the uddi node.
"#JohnSaunders is right, nobody uses UDDI in the wild" - talk about a blanket statement. Perhaps you both meant "few people", but to say "nobody" without being able to prove it is silly.
"(I heard that UDDI seems to be deprecated, but I cannot confirm for that)". Widely used? probably not. Deprecated? Apache, Microsoft, IBM, HP, Oracle, and WS02 still sell or give away implementations of UDDI so I wouldn't exactly call it deprecated.
Related
I am developing a SOAP interface and am having trouble deciding what to name the endpoint address.
Options:
- {soap,api,service,???}.foo.com.au
- www.foo.com.au/{soap,api,service,???}
What are the typical names that a SOAP service gets?
I would use www.foo.com.au/soap, mostly because it's an easy way to tell people that it's a SOAP service, and if you want to add a REST service later, you can use www.foo.com.au/rest
Keep in mind, in practice, all solutions are technically equivalent. The benefits of one naming system over another are only at the ease or understanding what the URLs are about (for humans), or maintainability, really. So, if you are searching for a standard we can tell, at best:
If you have a big company with lots of applications, go for the http://api.company.com/application/rest and/or http://api.company.com/application/soap approach
Reason: you can separate, right from the start (networkwise) the web service servers (http://api.srv.com/app) from the human web browsing servers (http://www.srv.com/app).
All applications have one big root "meeting" point (the root URL api.company.com), so if anyone wonders what is company-wide available, just check http://api.company.com and it can list all services available.
If your setup is not that big, it is probably not worth the trouble, so don't fear using the www.. But keep in mind it's best to use at least a different context, such as api/, so that anyone knows right off the bat a service URL is about a web service(!): http://www.company.com/application/api/rest / http://www.company.com/application/api/soap
Note: It's also common to use service, although api seems to be somewhat better descriptive (api.something.com leaves no doubt about what that page is about).
Some examples (as you can see, there is really no global standard):
Google's search API: http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=test
Twitter's search API: http://search.twitter.com/search.json?q=w00t
Facebook' Graph API: http://graph.facebook.com
Facebook' Dialog API: http://www.facebook.com/dialog (see, no standard even within facebook!)
Weather Gov SOAP forecast: http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Buy many seem to keep the good ol' company-wide APIs "meeting points":
http://developers.google.com
http://developers.facebook.com
http://dev.twitter.com
I have been fighting with this for a while now. I need to prototype SOA, and with it, the registry. I have been fiddling with jUDDIv3 on JBoss SOA Platform 5, but there don't appear to be any tools that allow me to publish to a v3 jUDDI registry. See my related questions here and here.
I realize after reading comments on those questions, and some articles on the internet (like this one) that UDDI is failing or dead, however my organization has some legacy tech we need to work with.
Also, my supervisor (I'm an intern) is adamant about sticking to standards. In principle, I agree with this, but perhaps a dead standard really isn't a much of a standard if nobody uses it.
In short, I need to provide the registry component of Service Oriented Architecture. It probably needs to be UDDI, so that it fits with the legacy tech, and satisfies the standard. Whatever the solution, it would be best if there were tools available that allow me to publish web services to that registry.
This problem has dragged on much longer than I would have liked. Any small piece of advice is really appreciated.
You may use WS-Discovery. WS-Discovery is a standard protocol for discovering services and service endpoints. This enables service clients to search for services based on a given criteria and bind with the discovered services. There are tow modes of WS-Discovery,
ad-hoc - servers advertise the services they have using a UDP multicast protocol
managed mode - servers and clients use an intermediary known as the discovery proxy for all service discovery purposes.
You can simply try this out with WSO2 Platform (free and open source under apache2 license). Please follow [1] to see a simple scenario of WS-Discovery in managed mode.
[1] http://charithaka.blogspot.com/2010/04/ws-discovery-with-wso2-carbon.html
I'm working on a API that will accept addresses in searches. We would like to use Google's geocoding service to normalize the addresses before submitting the search criteria to our search engine.
This caught my attention:
http://code.google.com/apis/maps/documentation/geocoding/index.html#Limits
"Note: the Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited. For complete details on allowed usage, consult the Maps API Terms of Service License Restrictions."
Does this mean we can't use the Geocoding service for this purpose? Having used libraries that access Google's geocoding service before, I know it's technically possible to do this but it sounds like a violation of the terms of service.
Are there other options for what we're trying to do?
Edit:
It turns out our company does have a license with Google to use the addresses that come back, and they will eventually be displayed on a Google Map to the end user, satisfying the terms of our agreement.
Short answer: You can't. The terms of service seem pretty clear-cut that geocoding using their API is not in line with their terms, unless you display them on a Google Map.
If you need this for other purposes, you should consider licensing a Geocoding library and dataset(s) for your regions of interest. There are quite a few companies which sell these for commercial purposes.
Update on this really old post:
#Cerin pointed out something important on this answer.
USPS Web Tools API are only free if you're using them to ship
via USPS
So be legal.
You are correct: you can't use the Google Geocoder for address cleaning.
You can use this wrapper to access USPS's Web Tools.
Another inexpensive solution is Semaphore, but you'll have to write your own wrapper class to call the DLLs.
The USPS has a free service to validate addresses. It's in a fairly easy-to-use API that you can curl information to and receive a valid response back. The only rub is that they're a little slow when it comes to registering, and they require you to run several tests before they'll open it up. Regardless, once you've jumped through the hoops, it does a great job. It's been keeping addresses in my app clean for quite a while now without any hiccups.
If you are going to start the development of an API for your web application. Is there any kind of guidelines, best practices or standard to build web services. I have seen a few discussions in this topic and I will like to get more information.
At least get pointers on where to get the information.
Thanks in advance.
There exists a wide variety and latitude regarding "web services". I find it useful to make explicit note of what we are talking about:
web = transported over HTTP(S)
service = remote procedure call (RPC)
Note that the HTTP(S) portion of this merely specifies the transport medium, but not the content. Also note that the RPC portion of this merely specifies the behavior (essentially invoking remotely a named function with arguments that returns a result) but not the content.
A critical question that arises is whether you control both sides of the communication. If so, but especially if not, you need to be concerned about interoperability.
SOAP is a standard for implementing a web service that specifies using specificly-formatted XML for the content of the request and response. It is VERY heavy, and there are still problems with interoperability across various implementations.
There are lots of custom implementations, most of which are lighter, but you will almost certainly have interoperability issues.
Since any form of content can potentially be used to achieve a web service, I recommend picking something that is able to handle complex content (to varying degrees), standardized, lightweight, and robust.
I am recently leaning towards JSON for the content format. I recommend considering the same, especially if you are considering implementing AJAX.
Best wishes.
API 101
I am pasting this URL as a close approximation of the possible answer. Since I did not get any other answer, I think this is as close as it gets.
I will like to have more detail best practice outline, if someone find something better, let me know to mark their answer as accepted.
If you could answer some of these questions, you might get a more satisfactory answer.
who is the audience that will be consuming the the service?
What types of client technologies will be consuming the service
what assumptions/restrictions can you put on them (platforms, tooling, skill
set)?
How broad is you API - how many methods will it expose?
Is security a consideration - how secure do you need to be?
Do you need to support transactions?
a. What are the things I must consider?
b. I have several Stored Procedures being execute by the current application. If I create equivalent methods to execute these procedures, what would be the risk or the challenge.
Architecturally, one thing you must consider in transforming a web app to a web service is that local access to methods and data is not the same as remote access. Remote access should be designed so that invocations are more course-grained and exchange more information at once.
Another thing you would need to think about is what your serialization protocol you will use. For example, SOAP vs a REST-based protocol.
Also, think about security - the security considerations are different between a web application and a web service.
Finally, think about how others will know about your web service (or if they will at all).
One risk is ensuring that your code remain the same.
What I mean by this is that there is a distinct possibility of code duplication in this situation, and as such means that you may inadvertently forget to modify one of the places where the Stored Procedure is used (say if you add a new variable to the stored proc call).
Then you also must consider security. For example, exposing a web service call that provides a list of users to the wild is probably not that good of an idea. you need to plan for how you're going to pass/receive authentication & authorization information.
Managing your code base as Stephen said is going to be a big challenge if you create equivlant methods. Your much better off extrapolating the methods into a new library, that both the web application and web service will use. Your web apps shouldn't have any data access code in them.
With a web service you need to consider your clients. Who is going to access your data and from where. If for example its from a .net windows client on the same network or machine a TCP binding might be best. Or if you need to support older .net framework clients or even java clients you need to be careful about what technology you use.
You will also want to choose between WCF or ASMX. Which the previous paragraph shouuld help answer.
It seems to me that the greatest challenge will be that you are obviously tempted to do this. I think you're making a mistake.
Your web application, and the web service you propose, have different requirements. By "transforming" the application into the service, you will burden the service with the requirements of the application.
Here's a "thought experiment": what if you were to write the service from scratch, ignoring the application. How similar would the service and application be? If they would wind up alike, then transformation would make sense. Otherwise, not so much.