My company is working on a project to develop a desktop and mobile email client that can connect to different mail servers with minimal configuration for users or server admins. We want to be able to support Exchange but I've realised after some research that there are a number of issues to think about. Our goal is to be able to connect to as many types of Exchange server as possible, so we need to choose a protocol, or protocols to implement that will allow that. It seems there are 3 different protocols in use - WebDAV for older 2000/2003/2007 servers, Exchange Web Services (EWS) for 2007/2010+ servers and ActiveSync which is supported by everything post 2003 (I think).
My question is, which do you think is the best approach for implementation?
-ActiveSync seems to have the most coverage but is the biggest pain to implement. Would a dual implementation of WebDAV + EWS provide the same coverage?
Also, if there are any Exchange Admins out there, which protocols tend to be enabled by default? If WebDAV/EWS are always turned off by default then maybe ActiveSync is the only option. It seems that as the iPhone and Android support ActiveSync it is most likely to be turned on, but what about the others?
Also, would be interesting to have statistics of what servers are currently in use - i.e. how many are still using 2003, have migrated to 2010 etc.
Would like to hear your opinions.
Cheers,
Kevin
If you are building an email client and targeting Exchange, I would recommend ActiveSync. The other protocols -- WebDAV and EWS -- were not intended for generic email clients. EWS, for example, does not support transactions or syncing, so if you have multiple clients you will have to deal with tons of race conditions on your own. WebDAV requires some funky limitations and is not always enabled. ActiveSync is relatively easy to write, it just requires getting a license from Microsoft, and it always works with Exchange.
If you just want to send and read email, however, don't overlook IMAP and POP3. You'll find the broadest support for those, even though are disabled in the newest installations.
About Versions:
2003 should be hard to find, as it is out of any Support.
A lot companies have skipped 2007 Version, so you should find a lot of 2010/2013 installations.
Although Exchange 2016 was released back in october, I assume, that there arent too much installations out there (2016 is more like a CU to 2013 :) )
Related
I know asking this question here is not proper, I feel sorry for that.
I have tried searching websites, Amazon and Alibaba, but fail to find any product can support Eddystone-EID.
So, I think developers in stack overflow may know any product can support Eddystone-EID.
Could you share any any information for that?
The two vendors below claim to sell beacons compatible with Eddystone-EID as of October 2021:
Gimbal
Estimote Location Beacons
Before you buy anything beware that Google shut down their beacon platform web services in April 2021. I wrote a full blog post to explain what this means: Eddystone is Dead, Long Live Eddystone!
Using these web services is completely optional for Eddystone-UID and Eddystone-URL, but critical for Eddystone-EID, because the beacon identifier rotates with a crypto algorithm and a “trusted resolver” server is needed to convert the advertised “ephemeral identifier” from jibberish to something meaningful and useful.
Without Google’s beacon platform web services, I am aware of no commercially available trusted resolver for Eddystone-EID. You would need to build your own, which is a non-trivial effort. Without a trusted resolver Eddystone-EID is worthless.
Because of this, make sure the vendors above still support using their products with Eddystone-EID. In time, it is likely they will remove support in their beacon firmware.
Finally, it is important to note that just because Google gave up on their beacon web services, most apps that use Eddystone, iBeacon and Altbeacon are unaffected. Beacons are standardized and will work forever — just don’t use Google web services! Again, beacon technology aside from Eddystone-EID has no need for Google web services.
I have seen this question asked several times but the answers have so far been very robotic and disappointing:
What is the difference between EWS vs EAS?
Now, most sites give the following: "One is a protocol for mobile devices, the other is a web service." Well, no shit. Here's the real question:
What is stopping someone from setting up a descent library for EWS that any mobile app or OS could use instead of paying MS a per-user license fee for ActiveSync? Is EWS too expensive, since it's SOAPy instead of RESTful? Is ActiveSync doing more of the heavy lifting in terms of caching and general logic? Does EAS have some feature that EWS doesn't have (shared calendars or some such?) Is it really just a matter of mobile OSs wanting to ensure that Exchange 03 is supported?
I'm sure they each have their finer points that make them distinct, but the question that I think most people are getting at when this question gets asked is "Why should I pay for EAS if EWS can do the same thing and more if I'm willing to write the client side myself?"
Most organizations will license EAS because one or more of the following is true for them:
They want to allow existing mobile devices (iOS, Android, etc) to access their services without requiring new software to be installed on them (EAS is supported on lots of devices). Zimbra and Kerio do this, for example.
They can't use EWS as a client protocol to access their Exchange services, but EAS is available.
They want to operate in a low-bandwidth environment and can't afford the weighty overhead of SOAP within EWS compared to the compressed WBXML of EAS.
I'd wager that #1 makes up the vast majority of them.
Aside: EAS is not RESTful. Everything goes over POST, there's no hypermedia or ability for the client to do content negotiation. It's basically session-oriented RPC, using WBXML as an encoding format and HTTP as a transmission protocol.
I'm looking at having thousands of simultaneous connections from mobile phones to the server whereby anytime a user interacts with his cell phone, the data is sent and logged by the server. Also, anytime the server has new information for that user, the server can push that information without a browser refresh. I am wondering what is more stable and how you would build this?
A good real-time framework or infrastructure will have numerous APIs that should let you connect any device, no matter the technology, to the real-time server e.g. an iOS client library for iPhone and iPad, a JavaScript client library for numerous platforms including normal and mobile web, an Android compatible Java library and so on.
An interesting idea might be to choose which ever framework or real-time service suits your needs best and then using something like PhoneGap. But, as #rt2088 says, it depends if you need the notification app to be running as a service on the phone or as a standalone application.
The choice will also depend on whether you want to install, host, maintain and manage the scaling of your own real-time services or not. If not, there are a number of services out there who you could use so you can concentrate on building your application. If you do want to manage your own infrastructure then the Comet Maturity guide could be a good start. It's a little out of date but is still probably the best reference available.
the ability to push new content the
user based on his GPS location which
is "pinged" to our server. Based on
that, we deliver local content. What
frameworks are you talking about?
There are a number of real-time frameworks available at the moment. Some are hosted services and others require installation on your own hardware. The majority of them will come with a bunch of libraries in different technologies that make it easier to get up and running with them e.g. a JavaScript library that wraps the WebSocket object and also manages fallback for web browsers that don't support WebSockets.
I've just created a Real-Time Technologies Guide in which I've listed all the real-time technologies that I could think of and provided a bunch of tags associated with each.
wouldn't a javascript client library
cover all platforms if it is a web
appilcation?
If the application is a web application then yes, a JavaScript library would be all you need for the client application. The server side libraries that you require would depend on the real-time technology you choose.
Best solution to achieve this is to use the WebSocket communication. It is bidirectional asynchronous communication. Currently every browser supports this new standard and plenty of code snippets available. You just have to google it. There are many server and client side frameworks. choose the one best suits to your requirement.
The details of the WebSocket specification is available at -
Websocket specification
Do you need notification when user uses mobile browser of handset or the mobile handset itself (performing non-browser tasks)? Based on that, the framework to record user activity can be selected.
I am investigating developing an app for Windows Phone 7 that requires access to email/calendar information from Exchange Server (read only).
The way I see it there are 2 options EWS or ActiveSync.
WP7 only supports Basic Authentication.
By default on Exchange server installations the EWS virtual directory has Basic Authentication disabled meaning a configuration change of Exchange Server to allow EWS to be used.
The ActiveSync protocol looks like it would take some time to get your head around and develop an implementation.
The questions are
1. How common is it for people to enable basic authentication for EWS? Is this something that most businesses are likely to not want to do?
How difficult is it to learn and use the ActiveSync protocol? Is it something that could be done in days, weeks or months?
1) To find out about the common configuration of EWS servers I'd spek to some sysadmins and ask them. Maybe try on https://serverfault.com/
1) How difficult something is to learn very much depends on the skills and experience of the person learning and the teaching resources available. This is a non-trivial protocol so I wouldn't expect learning it to take days. There will also be a licensing cost of implementing Excahange ActiveSync which I suspect would make it an expensive option.
Option 3: Create your own web service that acts as a proxy to EWS and does the authentication for you. Ugly and a bit painful, but if your app is architected well, once WP7 supports better authentication, switching to directly hit EWS should be pretty simple.
ActiveSync is painful and does not support everything that EWS supports. I would recommend going the EWS route if you have that option.
If your going to use ActiveSync, think again... it uses wbxml and you would need to create your own API for doing calls - this means crating tokenized blobs which must be 100% perfect and account for all aspects of whatever type of messaging items you are going against or will risk creating bad items or even poison ones. The devistation caused by bad EAS calls could well exceed your customer base... so, you need to be very careful. Also, while the specs are public, it needs an very expensive license. If you license, you would need to get a support contract with a specific schedule in order to get develper support. With a team of developers, it will likely take 3-5 or so years to do a full implementation client side and work out most of the bugs. So, as far as the skills in email development, you and your other developers would need to be pretty hard-core. There may be third party APIs which wrap EAS calls... however, you should be sure that they are licensed and that that the license would cover your development - so, you would need to research those on your own.
EWS has more features and is far, far easier to use and is what is suggested... further, there is no special licensing, etc.
Using a proxy web service+Exchange Managed APIs so that WP7 can go against Exchange without writting a ton of code:
http://www.telerik.com/products/windows-phone/getting-started/exchange-client.aspx
... can also use this approach to use NTLM.
Before considering EAS...
http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
This is slightly off topic of programming but still has to do with my programming project. I'm writing an app that uses a custom proxy server. I would like to write the server in C# since it would be easier to write and maintain, but I am concerned about the licensing cost of Windows Server + CALS vs a Linux server (obviously, no CALS). There could potentially be many client sites with their own server and 200-500 users at each site.
The proxy will work similar to a content filter. Take returning web pages, process based on the content, and either return the webpage, or redirect to a page on another webserver. There will not be any use of SQL server, user authentication, etc.
Will I need Cals for this? If so, about how much would it cost to setup a Windows Server with proper licensing (per server, in USA)?
This really is an OT question. In any case, there is nothing easier than contacting your local MS distributor. As stackoverflow is by nature an international site, asking a question like that, where the answer is most likely to vary by location (MS license prices really are highly variable and country-specific) is in my opinion not likely to receive an useful answer.
I realize this isn't exactly answering your question but if you want to use Linux, maybe you want to look into using Mono. .Net on Linux.
If users will not be actually connecting to any MS server apps (such as Exchange, SQL Server, etc) and won't be using any OS features directly (i.e. connecting to UNC paths) then all that should be required is the server license for the machine to run the OS. You need Windows Server CALs when clients connect to shares, Exchange CALs for mail clients, and SQL Server CALs for apps that connect to your databases. If the clients of your server won't be connecting to anything but the ports offered by your service, you should be in the clear, and it shouldn't cost any more to build a server for 100 users than 10.
You may not need any CALs for users depending on how you use the server. Certain functionality requires the purchase of CALs but some doesn't. There's no real good way to answer this question since the requirements are too vague. Does it use domain services? Does it use SQL server? Clustering? There are many variables.
If you are looking at what the most you could possibly pay, go to CDW and look at the Open License/Open Business products to get an estimate.
Like said above, if you are using your own connections and nothing else on the server you wont need the cals.
I would Google the ROI on Linux vs Windows for a commercial server, I have no option generally on this, but I have seen that long term they level out, in the grand scheme of things the initial cost of the Windows license is actually minimal and insignificant.
Choose the best technology to solve the end users problem, document why, provide an evaluation report, include maintenance costs, development costs etc. When you do this the answer will be clear to you and your customer.
If your users are not connecting to any other windows resources (Active Directory, SQL Server, File Shares, etc) then you shouldn't need CALs but you I believe there is something like an external connector license. There's also a 'web edition' which looks like it's in the range of ~$400.
Also it looks like Microsoft will be removing the CAL restrictions on web servers completely in Windows Server 2008
Microsoft should call their licensing division Enigma...