I am looking for a Data Look up Service, that I could send a real estate property address (street, city, state, zip) and get back information about this property (owners, mortgage, sq footage, rooms, etc)
Would any one know of an existing service like that, that could be used and an ASP.Net application?
Thanks!
Well the type of service you are looking for is generally limited to Multiple Listing Service. To be a member of an MLS you have to me a member of the NAR (National Association of Realtors). Even then the type of service you are looking for (on demand lookup) is then available generally only to Designated Brokers (there is only one Designated Broker per Real Estate brokerage). However you can sometimes find services that can provide MLS like lookups for you (check google etc) but you will likely have to pay. It would probably interest you to check out this related question.
Related
Consider the following micro services for an online store project:
Users Service keeps account data about the store's users (including first name, last name, email address, etc')
Purchase Service keeps track of details about user's purchases.
Each service provides a UI for viewing and managing it's relevant entities.
The Purchase Service index page lists purchases. Each purchase item should have the following fields:
id, full name of purchasing user, purchased item title and price.
Furthermore, as part of the index page, I'd like to have a search box to let the store manager search purchases by purchasing user name.
It is not clear to me how to get back data which the Purchase Service does not hold - for example: a user's full name.
The problem gets worse when trying to do more complicated things like search purchases by purchasing user name.
I figured that I can obviously solve this by syncing users between the two services by broadcasting some sort of event on user creation (and saving only the relevant user properties on the Purchase Service end). That's far from ideal in my perspective. How do you deal with this when you have millions of users? would you create millions of records in each service which consumes users data?
Another obvious option is exposing an API at the Users Service end which brings back user details based on given ids. That means that every page load in the Purchase Service, I'll have to make a call to the Users Service in order to get the right user names. Not ideal, but I can live with it.
What about implementing a purchase search based on user name? Well I can always expose another API endpoint at the Users Service end which receives the query term, perform a text search over user names in the Users Service, and then return all user details which match the criteria. At the Purchase Service, map the relevant ids back to the right names and show them in the page. This approach is not ideal either.
Am I missing something? Is there another approach for implementing the above? Maybe the fact that I'm facing this issue is sort of a code smell? would love to hear other solutions.
This seems to be a very common and central question when moving into microservices. I wish there was a good answer for that :-)
About the suggested pattern already mentioned here, I would use the term Data Denormalization rather than Polyglot Persistence, as it doesn't necessarily needs to be in different persistence technologies. The point is that each service handles its own data. And yes, you have data duplication and you usually need some kind of event bus to share data across services.
There's another option, which is a sort of a take on the first - making the search itself as a separate service.
So in your example, you have the User service for managing users. The Purchases services manages purchases. Each handles its own data and only the data it needs (so, for instance, the Purchases service doesn't really need the user name, only the ID). And you have a third service - the Search Service - that consumes data produced by other services, and creates a search "view" from the combined data.
It's totally fine to keep appropriate data in different databases, it's called Polyglot Persistence. Yes, you would like to keep user data and data about purchases separately and use message queue for sync. Millions of users seems fine to me, it's scalability, not design issue ;-)
In case of search - you probably want to search more than just username, right? So, if you use message queue to update data between services you can also easily route this data to ElasticSearch, for example. And from ElasticSearch perspective it doesn't really matter what field to index - username or product title.
I usually use both approaches. Sometimes i have another service which is sitting on top on x other services and combines the data. I don't really like this approach because it is causing dependencies and coupling between services. So in general, within my last projects we tried to stick to polyglot persistence.
Also think about, if you need to have x sub http requests for combining data in some kind of middleware service, it will lead you to higher latency. We always try to cut down the amount of requests for one task and handle everything what is possible through asynchronous queues. ( especially data sync )
If you conceptualize modules as the owners and controllers of the data they work on, then your model must also communicate that data out of that module to others. In contrast, the modules in a manufacturing process have the access to change data without possessing and controlling it.
Microservices is an architecture for distributed processing, like most code, where modules pass the data around to work on it. From classic articles by Harvard Business Review and McKinsey on the subject of owning members of a supply chain, I identified complexities arising from this model and wrote an article teaching programmers what you need to know: http://www.powersemantics.com/p.html
Manufacturing is an architecture for integrated processing, where modules work on the data without passing it around from point to point. This can be accomplished by having modules configured to access the same memory, files or database tables. My architecture shows how to accomplish this on memory via reference properties.
When you consider "exposing an API at the Users Service end which brings back user details based on given ids", you need to be aware that creates what HBR calls "irreversible" complexity, which I've dubbed centralization complexity. Don't build A->B (distributed) systems, because you can't decentralize them later after failing to separate requirements. Requirements in production processes represent user instructions, and centralized modules only enable you to change the wrong users' processes. In other words, centralized modules don't document user groups or distinguish them from derived-product-users.
I am trying to prototype a system that will display a list of choices to a user, and allow them to place an order for the one they select (an over simplification of the prototype, but sufficient to get to the point). I have the users credit card number, billing and shipping addresses, and other contact information, but I can't find any web services that will let me actually purchase something with this information to complete the prototype. I have checked directories such as Programmable Web and Xmethods, but they just seem to point to APIs that let you check for prices and availability, but not actually place an order. Does such a thing exist, or is there some reason (such as security) that I am missing, that prevents such a service from being offered?
The most important thing about online shopping is the security of transmitted information (e.g. credit card data). So the ideal case is to transmit these information directly to the related bank's (issuer of the credit card) payment services, rather than passing it via other service providers. This is what 3-D Secure does.
So when you use a common API this means putting an extra broker between, and passing the secure information to this party which increases vulnerability. Since such a broker cannot use 3-D secure (since it is not the merchant so not possible to make an agreement with the banks) and it should pass the information to online shopping site.
Moreover, an online shoping site can block traffic coming from such an intermediary webservice at any time if you do not make an obligatory agreement and making agreements for each online merchant is practically not very possible.
There is no such free API available the simple reason behind that information like credit card is very secure and confidential and there will security threat on free API's.
here is list of best 10 online payment system
http://sixrevisions.com/tools/online-payment-systems/
and this one who providing live demo
http://www.fastcharge.com/
I think it is possible though I don't know in depth information. I think this is what you see. In next steps you will be redirected to payment gateway of the bank and then you can complete the transactions just by answering some security questions. I think this is a service you should obtain from the bank. And I haven't seen any universal API that can perform the task you have mentioned.
Dialog GSM - Sri Lanka
Anything.lk - Sri Lanka
I'm looking for a United States Address Validation web service, as the title says. Also:
I don't need maps
I don't need Geo coding
I do need:
Validation that an address is real
Address parsing
Google's Maps / Bing Maps seemed good, but won't work for me because of these:
Prohibits use if not plotting points on a map image
Low request limits (100,000 / day) for premium account. I need more like 1,000,000 / day
Does Geocoding, which I don't need, which is resource intensive, which means it's slow
Any suggestions?
Maybe USPS?
https://www.usps.com/business/address-management-products.htm
use FedEx's API. They have an API to validate addresses.
Also:
https://webgis.usc.edu/Services/AddressValidation/Default.aspx
You can try Pitney Bowes “IdentifyAddress” Api available at - https://identify.pitneybowes.com/
The service analyses and compares the input addresses against the known address databases around the world to output a standardized detail. It corrects addresses, adds missing postal information and formats it using the format preferred by the applicable postal authority. I also uses additional address databases so it can provide enhanced detail, including address quality, type of address, transliteration (such as from Chinese Kanji to Latin characters) and whether an address is validated to the premise/house number, street, or city level of reference information.
You will find a lot of samples and sdk available on the site and i found it extremely easy to integrate.
You could, in theory, run desktop software and plug into any kind of API it provides, but then you become responsible for things like uptime, data updates, and associated overhead. You may also run into issues with the software threading model--is it multi-threaded or single-threaded software? You don't want to find that out in production.
There are a handful of web services out there that can verify US-based addresses, including the USPS official web service. The USPS one is very limited in the fields that it returns. For example, if you're looking for the "delivery point" which is used to make a full barcode, the USPS API doesn't return that information. I believe the USPS web service also limits the number of queries that you can perform, although I don't remember the exact limit.
A few things that you'll want to look for in a web service include the price (obviously) as well as geo-distribution of their servers. If a company has all of their servers in one location and that data center goes offline (which can and does happen), you're left out in the cold. If they have multiple physical locations, it can help to prevent unnecessary outages. Also, you'll want to make sure that the service call returns all necessary fields as per your requirements--like delivery point code, barcode, and DPV code (which tells you how deliverable an address is).
Lastly, you'll want to determine how you feel about interacting with the company. When you call them on the phone, are they responsive and concerned about your needs? Or are you talking to some front-line person that can't answer questions and is only able to gather information about your company size and revenue so they can evaluate how big of a fish you are and determine which salesman gets to call you back. Can you talk to the engineers that wrote the web service on the phone or via email?
There are a few choices out there and you'll have to choose the one that best fits your requirements and unique situation. Do a Google search to find a list of companies. In the interest of full disclosure, I'm the co-founder of SmartyStreets. We have an address verification web service API called LiveAddress. You're more than welcome to contact me directly with questions on my personal Twitter account or the company Twitter account.
I'm working on a web-application that operates on services. Every service is normally provided over some (possibly several distinct) geographical domain(s) like city, county, region, state, country or worldwide.
Typical tasks:
users will submit their location as lng,lat and I will need to find what are the services available for them
when users add new service they should be able to select the smallest geographical domain that covers service area, eg: US->California->SFBayArea.
I wonder what is the best db schema to represent hierarchical relations of geo domains and where to get the actual data for geographical domains?
I started with openstreetmap though it looks rather complex and it will take considerable time. So I decided to appeal for community wisdom :)
Thank you for sharing your wisdom!
Have a nice day!
--UPDATES: updated typical tasks
For all sorts of geography-related data (though not maps), try http://www.geonames.org/.
We're looking at adding charts to our webapp. I recommended using a 3rd-party service such as Google Charts; this idea was rejected over fears about client data being passed to Google.
Google's Privacy Policy (which appears to apply to Charts) seems to preclude the abuse of our data, since it states that they require opt-in to share it with anyone. Still, I'm not sure of this.
Is there a legitimate concern here with respect to privacy/security of the data we send to Google?
Is your web app to be used only by your company or also by your company's clients? If there are clients involved, then that would be a strong reason not to use Google Charts. After all, you can't take the decision to send your client's their data to Google, no matter what Google's Privacy Policy states.
My company has the same concerns, here are a couple of things that came up in the discussion:
Google has a good track record thus far in not unilaterally exposing customer data (unlike say, Facebook). Chances are they would not expose your data.
If you're really concerned about the exposure of data, you could always send the Google Charts API erroneous column and row data names, then rename the data to their correct names on the client side. So you could have columns Dept A, Dept B, Dept C, but you could send it to Google as X, Y, Z. That way, even if someone did see your data they'd have to spend a bunch of time making sense of it.
Use a client side library such as Flot (code.google.com/p/flot/). We'll probably use this option since we have some government customers who don't have access to the outside internet.