I'am wondering if two Web Services can have the same targetnamespace. Or is it discouraged to use the same tns multiple times and what is the reason for this limitation?
Technically you can have both the webservices have the same target namespace. But namespaces package logically related set of items together. I wonder why you would like to use the same namespace.
Related
I'm now working on Ember CLI application. Now checking the strategy for implementing Authentication.
Now, I plan to create Auth.js, which would maintain the login state and can perform actions.
For example, in Balanced-dashboard, they are using "Namespace", but Travis-CI put it in Util folder.
I also feel like Ember.Service is appropriate for putting Auth.js.
It seems both Namespace and Service are kind of Alias of Ember Object.
So, I'm wondering which of them to choose.
What kind of rule I should apply?
I actually just answered a similar question there. Long story short: don't waste your time and use ember-simple-auth, you will save hours of work :) It is a very flexible library that can handle different authentication/authorization mechanisms in parallel and across different tabs of the browser.
Otherwise yes, Ember services are the way to go!
I have a django backend set up for user-logins and user-management, along with my entire set of templates which are used by visitors to the site to display html files. However, I am trying to add real-time functionality to my site and I found a perfect library within Node.Js that allows two users to type in a text box and have the text appear on both their screens. Is it possible to merge the two backends?
It's absolutely possible (and sometimes extremely useful) to run multiple back-ends for different purposes. However it opens up a few cans of worms, depending on what kind of rigour your system is expected to have, who's in your team, etc:
State. You'll want session state to be shared between different app servers. The easiest way to do this is to store external session state in a framework-agnostic way. I'd suggest JSON objects in a key/value store and you'll probably benefit from JSON schema.
Domains/routing. You'll need your login cookie to be available to both app servers, which means either a single domain routed by Apache/Nginx or separate subdomains routed via DNS. I'd suggest separate subdomains for the following reason
Websockets. I may be out of date, but to my knowledge neither Apache nor Nginx support proxying of websockets, which means if you want to use that you'll sacrifice the flexibility of using an http server as a app proxy and instead expose Node directly via a subdomain.
Non-specified requirements. Things like monitoring, logging, error notification, build systems, testing, continuous integration/deployment, documentation, etc. all need to be extended to support a new type of component
Skills. You'll have to pay in time or money for the skill-sets required to manage a more complex application architecture
So, my advice would be to think very carefully about whether you need this. There can be a lot of time and thought involved.
Update: There are actually companies springing around who specialise in adding real-time to existing sites. I'm not going to name any names, but if you look for 'real-time' on the add-on marketplace for hosting platforms (e.g. Heroku) then you'll find them.
Update 2: Nginx now has support for Websockets
You can't merge them. You can send messages from Django to Node.Js through some queue system like Reddis.
If you really want to use two backends, you could use a database that is supported by both backends.
Though I would not recommended it.
I'm building a web service which handles items for different countries. So far a request is something like example.com/item.php?country=us&id=1234
The idea is to rewrite these uri using friendly names. I'm thinking about two possible choices:
us.example.com/1234
example.com/us/1234
My preference is for #1 but I was wondering what would be the pros and cons of each. Admin access to the server wouldn't be an issue btw.
Thanks.
Your first solution (us.example.com/...) would require working with DNS entries and host headers. potentially you would have to make a different site for each country (depending on your hosting platform).
Your second approach (example.com/us/...) is simpler, and probably requires less work and maintenance.
we are planning a REST api for our application and are trying to make
a decision on if we should implement separate controllers for the REST
functionality or not.
We could use the withFormat{} in our current controllers but
separating the REST functionality in different controllers feels
somewhat cleaner..
In that way we can build our API seperate from the current controllers
and we could even take the REST controllers into another application
etc.
Any thoughts on this subject? Any real world experience in what the
best practice would be?
We recently faced the same decision and we decided to go for separate controllers for the REST API.
Advantages of separate controllers include cleaner/clearer controller actions and the possibility to support different versions of the REST API later on.
We also would like to keep the option to host the REST API on separate server instances open. These servers would use exactly the same .war, but with different configuration settings for the feature toggles.
A disadvantage of separate controllers might be the DRYness of the controller code. Although this should be limited, since IMHO you should keep the controllers as thin as possible and extract shared logic to Grails services or helper classes.
I will work with grails soon, but so far i have little experience with it. But in web apps i worked, we always left webservices separated from the controller code. We also separated REST from SOAP. Common methods for them would be in service layer. It, indeed, felt cleaner. We didn't had to insert a lot of ifs in the methods
I would, for a given resource, use one controller that interfaces with a service layer based on context (the media type received or requested -- SOAP, JSON, XML, etc.) This way, you have a truly uniform resource identifier that can accept and return various media types and the controller won't need to know anything but what method the user wants to perform on what resource and what media type is involved.
For instance, maybe the service layer returns objects that have methods such as 'toXml', 'toSoap', or 'toJson'. Then you can just ask the service layer to do whatever and use a switch statement on the requested media type to either return the requested information, or by default throw a 406 Not Acceptable status code. For unsafe or idempotent transactions, the object may have constructor or factory methods for a given media type and then you just ask the service layer to do whatever with that object.
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.