Are there any downsides like performance or gotchas in terms of functionality to using the built in ProfileProvider with .NET?
I will be storing office information, extra security questions, etc. Nothing to outrageous so it could be a good fit.
It's not bad for novices, but I think it's tied to the whole membership and roles providers, which I have found to be needlessly cumbersome.
Related
Can anyone expound on disadvantages, if there are any, to using a ColdFusion development framework? I'm developing an application traditionally, and I'm tempted to use a framework having seen how simple some things can be done.
I'm new to ColdFusion and frameworks in general. I want to understand the implications of using a framework, including advantages and disadvantages.
Disadvantages:
learning curve (pick a lean framework to reduce this)
front controller makes ugly URL, often needs URL rewrite on web server layer
risk of framework being discontinued (no support, hard to maintain, break on new CF ver)
framework bugs (pick a popular framework with good & fast support)
harder to debug sometimes, since actions are generally not a .cfm anymore. Tip: make use of cfdump and cfabort to see the dump in the controller layer
some frameworks takes longer to reinit. Since most frameworks will cache the configurations and controller layer for performance, during the development phase, you'll need to reinit all the time. CF9 eases this problem 'cause it is much faster.
lastly, sometimes you'll be using framework's API, an abstraction from CFML, and missed out on the native ColdFusion way of solving the same problem.
Performance generally is a non issue. Don't worry.
Henry's already given a good answer, but I would just like to pick up on this part of your question:
But does it not come with a performance tax?
The performance overhead of a framework is negligible.
In fact, you may even get better performance from frameworks such as ColdBox, which have built-in caching.
Remember, most frameworks are mature codebases used by lots of people - most likely, your newly written untested code is going to be the culprit, not the framework.
However, as a general rule (not specific to frameworks) performance is not a problem unless you've got measurable results that say it is.
i.e. don't just think "I'm going to do X instead of Y because I think it'll be faster" - go with the simplest option that meets user's needs, and only change it if you can prove that it has a performance problem and that your proposed solution is better.
It depends the nature of project you are into. I think its always advisable to use a frameowrk for better code organization, scalability, conventions and other. If you are supposed to start with a enterprise level application then coldbox is the best framework as far as my expriece goes. It has a bigger learning curve but its worth learning. If its simple start up project then FW1 is good. You can find a list here
http://www.riaxe.com/blog/top-coldfusion-frameworks/
I'm not satisfied with the answers given by the SOAP vs REST questions notably here:
Performance of SOAP vs. XML-RPC or REST
because it's just general philosophical answers and not pragmatic answers with some study cases.
Nobody can give precise cases of when soap would be more suitable than rest, especially as for performance point of view ?
Update:I think REST is winning the war.
Performance is not the deciding factor.
First I should say, asking a SOAP-vs-REST question is a little cockeyed, because SOAP is a XML envelope format, and REST is an architecture. So I will make a little assumption and suppose that you are really considering SOAP-vs-POX or SOAP-vs-JSON or SOAP-vs-some other data formatting approach.
The deciding factor should be this:
Do you now need, or will you need in the future, the SOAP envelope?
The SOAP Envelope allows things like framework-provided encryption, digsig, routing, and authorization checks, among other things. You can of course, do those things with REST (or more accurately, with plain-old-XML, or JSON, etc) but you have to do more work yourself, to make that happen.
If Performance - whatever you construe it to mean - really is your #1 criterion, then you should probably abandon SOAP and POX and move to protobufs or something else optimized for performance. These can be faster to serialize and faster to transmit.
If you think this answer is "too philosophical" and you really want hard figures, well, then I suppose you'll need to conduct some tests. The actual perf will vary greatly on the toolkits you choose, the shape of the messages, and the extra data services (like encryption and so on) that you use. But in the end, perf won't be, or shouldn't be, decisive either way.
If your SOAP toolkit is 20% easier to use. debug, and maintain as your POX toolkit, then you should use SOAP, regardless of the performance. People (coders, architects, testers) are much more expensive than CPUs and networks these days. You can always buy another 2 cpus, or a bigger network, if necessary, and if your design is correct. But you can't buy 20% less time developing, at any cost, if your framework is hard to use, or if it drives away your people. Unless you are running a geo-scale network, you will do better to optimize for the people, instead of for the network.
You can find an article comparing REST and SOAP here:
http://www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf
Authors conclusions seemed to be:
Use RESTful services for tactical, ad hoc integration over the Web
Prefer WS-* Web services in professional enterprise application integration scenarios with a longer lifespan and advanced QoS requirements
Personally I do not like terminology like "professional enterprise" because it is loose and informal. However in my opinion authors made some good points in the article. Maybe to conclude and to give some own thoughts:
If you want to make API public - do it in RESTful way. Why? It is simple to use for a client application so it will make your service more popular. For example Amazon is exposing both REST and SOAP APIs, but 85% of their users have chosen REST version Amazon API - SOAP vs. REST
Use SOAP and WS-* stack if you will create (or you have some control of the process of creating) both consumers and producers of your services and you do need advanced features of WS-*. This will probably required more resources also because SOAP applications tends to be "heavier" (more features, but more sophistication also).
Also considering performance REST could be faster (messages are definitely shorter and you do not need to parse xml).
Hope it will help.
In your example of flash client - it is really hard to tell without knowing the details, however if one do not need all this security and transactional features of WS-* I think building REST application would be simpler and faster.
Answering to comment
I should use soap because i'm in so
called "professional enterprise"
And assuming of course that your choice isn't really dictated by big software vendors.
SOAP is suited for bigger enterprises because it encourages more formal approach. It offers specifications, which are huge, so your developers may need time to learn them and maybe even some professional training --> so spending companies resources. It also offers tools - and not all of them are open source, so this can also mean additional resources. But if your team will learn this way of integrating services it will probably be efficient and resulting code will be high quality.
REST in contrary is more a philosophy of developing applications. So, no huge specifications, no specialized tools. No resource spending. This may work nice if you have a small team of good programmers - they will not need so many guidelines if they know the basic principles . Unfortunately it is also easier to do things wrong.
Another thing to consider is the applications size - the richer the API, the more services you want to integrate, the harder it will be to do it RESTful. Also building small SOAP application wouldn't be probably a good idea - whole overhead and entrance cost is just too high.
You need to evaluate pros and cons for your project. It is impossible to give recommendation without knowing all the details I think.
And finally - this has nothing to do with reasonable arguments but more with politics. I think that management level people seem to prefer WS-* stack and SOAP (it has support of "big enterprises" so it is easier for them to justify their choose). On the other hand people from academic background[1] prefers REST - because there is still a lot of research that can be conducted in the area.
[1] I'm somewhere in between, so I can observe both behaviors ;-)
I am a total newbie to the world of SOA. As such, I am looking at some "SOA frameworks/technologies", and trying to understand how to utilize them to build a highly scalable (Facebook class) website.
There are several "pains" I am trying to solve here:
Composability (+ managing dependencies, Pub/Sub)
Language-independence of services
Scalability & Performance
High availability
I looked into some technologies that answer a subset of the above criteria:
Thrift - Facebook's cross-platform RPC platform
WCF - supports SOAP, JSON & REST, so it can be considered language-interoperable. Generates WSDL files that can be use to generate java proxies.
Microsoft DSS - just inclued it in my survey, but it doesn't seem relevant as it is highly state-driven and .NET specific.
Web Services
Now, I understand how I get some aspects of composability and language-independence out of the above. But, I haven't found much concrete information (not buzz) about how to use the above / other tools for scalability and high availability. So finally I get to my question:
How does one leverage SOA technologies to solve the pains I defined above? Where can I find technical guides for that? I am looking for more than just system diagrams, but rather actual libraries, code samples, APIS...
I think the question has more to do with the concepts involved than the tools. Answers to the items:
Understand and internalize bounded context. Keeping unrelated pieces separate its important to get real reuse on different services. Related technologies won't help you on this, its you that separate the app in appropriate contexts, which you can appropriately reuse for different services.
Clear endpoint for communication based on known protocols allows implementing different pieces with different technologies
Having the operations flow like independent actions based on different protocols, gives you a lot of places where you can add tiers. Is a particular sub-process of the overall process using lots of resources and the server can't take it anymore, just move to a separate server. Load kept growing, and that server isn't taking it anymore, add an additional server and load balance. You also have more opportunity to use caching and connection pooling.
Have a critical sub-process that needs to be available all the time, add a server so you can have a fail over. Have an overall process that needs to be "available" all the time, use queues for pieces that can be processed later.
Do you really need to support that type of load? Set appropriate performance/load/interoperability targets that relate to the specific scenario. If you really need to support that type of load, I recommend you get someone on board who has dealt with it.
If it is something for a load that might eventually be, identify the bounded contexts and design the interaction between those with a SOA mindset. Keeping the code clean is all you have to do for the rest, use TDD, loose coupling, focused integration tests, etc in your code base. With good code, if you later need to separate pieces of the system, it will be a lot easier.
There are interesting and relevant things said about services and architecture by Amazon's CTO - Werner Vogels:
An interview about the Amazon technology platform
A post on his blog - "Eventually Consistent - Revisited"
A 50 min presentation about Availability & Consistency
IDesign.net has a bunch of great downloads for WCF.
Worth a look at: http://www.manning.com/davis/ ?
Check out the Mule project which bundles the CXF services stack and also the Mule REST pack which provides RESTful alternatives. I think you'll see it addresses all of your pains and there are lots of examples in the documentation as well as the distribution.
May I recommend the book: Enterprise Service Oriented Architectures published by Springer Verlag.
All of the advice here is well and good, but don't worry about it until you really need to.
Focus on building a usable, functional application that people really like. When you start running into problems, then start handling bottlenecks.
You will never be able to foresee every way an application will fail, so how can you tell if [[insert tech here]] is your answer?
Our application exposes queries by way of web services, and what we've found is that our clients often want custom queries, either by way of further limiting the results returned by specifying additional criteria, or by asking for things that we don't already expose.
Now, we can take the approach of creating new methods for each of these new methods, but that's somewhat inconvenient; deployment of our application at a client site usually requires weeks of staged integration testing. We've proposed a named query mechanism, where the application administrator would define queries by name that are parameterized, and a corresponding web service that simply invokes these parameters. However, I can't help but think that someone has solved this problem before, so I'd like some input from the SO community on possible designs.
Thanks!
Updates
The specification pattern is a good one, but our application deals with enough data that we want to push as much of the querying work down into an RDBMS, which can do a better job of optimizing the query plan than we would ever want to. Moreover, we support three RDBMS backends, so we're stuck using a greatest-common-denominator approach: we use as much capability as the least functional database can provide.
I would also recommend to consider the "Specification Pattern" in this type of applications as a design decision for your backend. Check the following posts about "Specification Pattern":
http://www.mattberther.com/2005/03/25/the-specification-pattern-a-primer/
http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx
Take a look at Hibernates Criteria API and use it or build some similar
functionality for Your users.
If it's worth the effort, provide a tree-like interface for grouping criterias. ("all criteria of a group must match" / "one criteria must match" / "negate")
Advantages:
Easy to build.
User parameters are possible.
Powerful queries are possible.
You can apply restrictions like SELECT ... FROM table WHERE someRestriction AND (user-provided criteria)
Since we really don't know which how your users use your interface it seems a little premature to give a technical advice on something that feels a lot closer to "Inmates are running the Asylum" problem.
There are some very good advice and common ways to solve this i technical aspects but do they work for your users? Maybe the really don't give a crap about your problem but rather have a fine working one button solution? (Or more like google?)
I'm implementing an SOA at a large company, and I'm not sure which web service specifications (WS-*) actually make sense to implement. At a minimum, I'm looking at WS-Addressing, WS-Security, WS-Eventing, and WS-ReliableMessaging. However, there are several other standards that look interesting, but I don't know which ones are widely adapted. I don't want to implement a standard (and force all the developers to follow them) if they're not mature or necessary.
EDIT:
I'm asking this question not about a specific situation, but in general. There are quite a few WS-* standards that don't seem to have a lot of practical use (at least to me), so I'm really curious about which ones are widely used.
Thanks for your help!
KA
WS-Adressing is widely used, and quite useful. For WS-Security, consider the set of mechanisms you'll need (based on your usage scenarios).
Only SOAP is widely adopted. If you care about reach, going beyond WS-Security and WS-Addressing is asking for trouble (even WS-Security can be hard for a lot of people). If you are creating services for internal use in a large company, then I wouldn't worry as much. Something like WCF would allow you to provide endpoints with different bindings for a wide range of consumers without writing any additional code.
There are two types of web services : REST and SOAP. They represent different protocols of sending data over the internet.
SOA is an acronym standing for Service Oriented Architecture. It is a way of architecturing your system using multiplet tiers (applications) one atop the other. Web services, mostly soap based are used to implement this archtecture, but they are not the only way.