My assignment is to create an App for a Mobile Device (Like iphone/android/BB/etc..), the purpose of this app is to tell the users there is something new on the website and then show an list (inside the App) showing the latest updates.
The Company insisted I use ASP.NET/C#/Visual Studio and use the SOAP protocol.
I've started working with C# and then using the so called WCF.
I've already got some stuff working. (Like "consuming" the WCF from an Android App and getting data sent back).
My Question is what will be the best "Architecture" to work with for the Mobile App Development. I was thinking about have only 1 WCF and then call a general function like Do() (Or some other name :)) and then adding a soap header where u can define what u want the service todo. Like getting a record from the database, or ping , er something else, whatever the company may need in the future :)
How this would work:
The Client (Mobile App) would make a call to the WCF, and in the soap header is states, lets say, it wants to register the Phone with the Device ID. The WCF will receive the Soap Requests, extract the header and use some sort of switch to decide what it needs todo. Once it knows that to do the WCF will then, for example, access some local Classes to insert/retrieve Database data or do something else and when its done it will simply return what is needed. (Like an OK sign or data or something else.. :)).
Is this a right approach, cause how I am looking at this, it makes it very easy for changes on the back end without updating the App.
Sorry if this a retarded question, but I am new to WCF and Mobile App Development, and i'am trying to deliver a great product at the end of my internship. I was just wondering what sort of "Architecture" you guys suggest I would use for this sort of assignment.
EDIT
I already told them SOAP is too heavy for mobile development and shown them some graphs. But they insisted to use techniques they already know.
After doing some research I indeed think the contract based approach is the better way to go. But can you maybe answer a few questions regarding it?
-Can I have like one WCF file that gets "consumed" which holds all the different operations?
-Can I authenticate the client (With using Soap headers Required) at the beginning of the WCF and after that call the desired operation?
SOAP is generally regarded as a little too heavy for mobile development. Since users may incur data charges and generally have lower bandwidth, it would be preferable to take a REST/JSON approach. You can still use WCF to do this at the server.
You can use a generic operation (MessageAction="*") but you will then need to handle the serialisation/deserialistion of messages yourself. However, unless you have a pressing reason to do this I would suggest properly structured operations are the better way to go. They are much more maintainable. You can still make implementation changes at the server without affecting the client, as long as the message contract does not alter. The reality is that if you want to change the message or operation contracts you will have to make changes to the clients anyway. After considering this, the 'contract' based approach only has upsides and no real downsides.
Related
There is an ASP.net C# web application through which we can get the recipient emails, time zone and their smtp server details in to the database.I have two requirements:
1. Consider a table in the database. When ever there is a change in the table, an email has to be sent. It is OK if we can constantly check the database every 5 minutes. It would be great if we can send it instantly but a delay is fine.
2. Sending emails automatically at 12 AM at their respective time zone.
I m familiar with C# programming. But kind of new to automatic scheduling stuff. This could sound like a basic question but it would be great if you can help. What is the best way to implement this - Web api or web services or WCF or windows services or combination of web api and task scheduler? Please let me know your thoughts. Also a small tip on how to implement this would be great.
You have an option of setting up trigger but I hate that approach as it will add overhead to your table tow insertion and not actually needed. I think you are in the right path by thinking about pooling. There is a nice little library in .net called hangfire which I find to be very useful to do scheduled task. It has pretty sophisticated reporting and almost all the time works really well. You can give it a try. But if you want to control things better writing a small windows service don't be that bad either. I think doing websevice either using webapi or wcf is a bit overkill here and might not fit purpose.
Basically, I have a new desktop application my team and I are working on that will run on Windows 7 desktops on our manufacturing floor. This program will be used fairly heavily as it gets introduced and will need to interact with our manufacturing database. I would estimate there will (eventually) be around 100 - 200 machines running this application at the same time.
We're lucky here, we get to do everything from scratch, so we define the database, any web services, the program design, and any interaction between the aforementioned.
As it is right now, our legacy applications just have direct access to a database, which is icky. We want to not do that with the new application.
So my question is, how do I do this? Vague, I know, but basically I have a lot at my disposal here, and I'm not entirely sure what the right direction to go is.
My initial thought, based on what I've perceived others doing, is to basically wall off the database by using webservices. i.e. all database interactions from the floor MUST occur through the webservices, providing a layer of security by doing much of the database logic behind closed doors. Webservice calls are then secured to individual users via Active Directory.
As I've found though, that has some implications of its own... We have to abstract the data before it reaches the application. There's still potential for malicious abuse by using webservice calls repeatedly to ruin or spam data. We've looked at Entity Framework and really like what it provides, but as best I can tell, that's going to be unavailable by the time we're at the application level in this instance.
It just seems like I can't come to a conclusion on what is "right". So, what is right?
WebServices sounds like a right approach. Implementing a SOA-oriented layer on the webservices layer gives you a lot of control over what happens to the data at the database server.
I don't quite share your doubts about repeated calls doing any damage - first you can have an audit log of every single call so that detecting possible misuses is obvious. But you also could implement a role based security so that web service methods are exposed to users in roles, which means that not everyone will be able to call just any method.
You could even secure your webservices with forms authentication so that authentication is done against any datasource, not only the active directory.
And last thing, the application itself could be published as a ClickOnce application so that it is downloaded and executed from the web page and it automatically updates itself just as you publish new versions.
If you need some technical guidance, I've blogged on that years ago:
http://netpl.blogspot.com/2008/02/clickonce-webservice-and-shared-forms.html
My suggestion since you are greenfield is to use an API wrapper approach with Servicestack.
Check out: http://www.servicestack.net/ServiceStack.Northwind/
Doing that you can use servicestack authentication, abstract away your db layer (because you could move to a different DB provider, change its location, provide queues for work items etc...) and in time perhaps move your whole infrastructure to an internal intranet app.
Plus Servicestack is incredibly fast, interoperable with almost any protocol you through at it, and provides for running it through MONO, so you are not stuck with a MS backend that could be very expensive.
My two cents. :)
First of all this question is not appropiate for StackOverflow, you might get close-votes really quickly.
Second, You may want to have a look at WCF RIA Services for this.
These will allow you to create basic CRUD operations for all your entities, and stuff like that.
I never used this myself, no I'm not sure what the potential issues might be.
Otherwise, Just do what we did:
Create generic (<T>) interfaces and services and contracts and everything. This will allow you to adapt your CRUD functionality in your Services, DAOs, ViewModels and such to any entity type.
I have been building a console app the uses the Saleforce SOAP API, and now need to use the Salesforce API in a web app.
Am I correct to assume that SOAP is better suited for a non web-based app, and REST is better for a web app?
If I where to create a wrapper that would be used in either reporting from local apps, or posting to salesforce from our websites, should I expose both the REST and SOAP api's, depending on what the app is? Or should I just stick to using one? What are deciding factors I should look at if I just need to pick one?
The other answers contain some good general info, some salesforce specific things to take into account are
1) You can directly bulk update data in the SOAP API, but you'll need to use the Async Bulk API to do that from REST.
2) The soap API contains a few things not available in the REST API, most notably describeLayout, queryAll, getDeleted & getUpdated
3) the REST API contains a few things not available in the SOAP API, including the API for chatter, and access to the recently accessed records lists.
4) the REST API can access binary data (files, attachments, content, etc) without the overhead of base64 encoding/decoding.
So, depending on exactly what your app is trying to do may push you one way or the other.
I believe it ends up being personal preference if you're consuming it by a .NET application, regardless of whether it's a web app or not.
Personally, I would go with SOAP as .NET has a lot of built in functionality to consume a SOAP service, it builds all the method prototypes for you and will make development faster than you handcrafting REST requests yourself. .NET will take care of the marshalling of SOAP.
As for building a wrapper, you have to consider your target audience, if your target audience is other .NET application developers, then exposing your own WCF service might be a decent option, WCF also has endpoints for either SOAP or REST.
IMHO, if you are developing the solution from .NET as your question indicates, SOAP is the way to go. REST services are beneficial because they lack the bulk and tool set requirements that surround SOAP and are nice for the bootstrap developer without access to heavy investment tools like .NET. I agree with the other comments that REST more closely mirrors the underlying HTTP methodology, and is easier to read and parse explicitly, but that isn't really something you have to concern yourself with from within a tool like VS and .NET.
Additionally, since you have existing console apps that may be brought into the communication mix at some point, it might be good to have the WCF flexibility to be transport agnostic and not tied to HTTP as you would be with REST.
So I really don't think you are in a position to take advantage of the REST advantages or be impacted by the shortcomings of SOAP, so it makes sense to go with the heavily standardized option that fits best into your existing tool set.
The decision to use REST or SOAP when both are available is usually related to:
The tools and language you're using for your application
Your familiarity with either style
The performance needs of your application (JSON payloads are smaller than XML payloads)
If the 'local' apps are calling the services from the server side, then all else being equal, you can at least generate C# code directly from the WSDL and that makes using the SOAP API simpler (no hand coding).
If the web application needs to call the API directly from the client side (browser), then use REST and work with JSON. This will be far simpler. You wouldn't be able to reuse the same wrapper regardless, so no problem using two different APIs other than the time it takes to learn them.
If the web app usage of the API is on the server (not client) side, then definitely target just a single API. WSDL if you want to auto-generate the code to call it, REST otherwise for simplicity and efficiency.
IMO, SOAP was a standard created as a contract type messaging architect, I.e. When passing messages just use this "contract." It was generic enough that it doesn't embrace any particular technology.
REST is a actual methodology that embraces HTTP, it is a way of utilizing GET, POST, PUT and DELETE to it's max potential.
I wouldn't assume one is better then the other, what it really boils down to is using the right tool for the job. I wouldn't make a distinction between web-based app and non web-based. Because SOAP or REST can be beneficial to both.
Here are a few questions I would get answered first:
1) Who is my target client. Microsoft Workshop Client, Java, PHP type.
2) What types of (Lack of a better term.) "Endpoints" do I want to expose to my Api. (JSON, XML, Ajax, POX or all of the above.)
3) What will my clients be going with this API? Do they already have clients that are based on SOAP. If so, SOAP is the way to go.
4) REST will makes you think about your URL design and thus allowing a client to "mashup" data to build what they need. So if you think that's something you want. REST is the way to go.
5) REST makes use of the "GET" in HTTP, this allows a client to cache results. "Conditional GET is what it's called. It allows them to cache a big object, ask the server via just a header (small) if the last update matches what is cached, if so. don't bother with a full object GET, what is cached is the latest version. This can be done in SOAP, but out of the box, REST is better for this.
Anyway, hopefully that gives you the better data, so you can make the better decision. And if all else fails you can just do both. But then you'll have to deal with trying to get two types of services (different methodologies) and one codebase for both. (can be tricky, but not that difficult.)
Personally. I would pick one, then if you ever need the other, burn that bridge and pay the technical debt for it.
Late to this party, but just a quick note:
The Salesforce API isn't completely RESTful: I would call it REST-ish. It has SQL-like queries in URLs for some of its REST interface, that sort of thing.
SOAP API:
What is it for? Integrating your organization’s data with other applications using SOAP.
When to use it? You have pre-existing middleware services that need to work with WSDLs and XML data.
Protocol SOAP/WSDL
Data format XML
Communication Synchronous
REST API:
What is it for? Accessing objects in your organization using REST.
When to use it? You want to leverage the REST architecture to integrate with your organization.
No WSDL requirement.
Well-suited for browser-based applications, mobile apps, and highly-interactive social applications.
Protocol REST
Data format JSON, XML
Communication Synchronous
I've made a little game as an application for the web in silverlight using C#, and I simply would like to save the top ten scores of any of the users that go on it.
How can I write to a file and save it on my web hosting area? Is this possible?
I think this would be the best way, because I only need to store a name and score (csv file), and this would be extremely easy. I hope this is possible.
If not could someone point me in the rite direction of being able to do this with a database, I've created a template just incase using MySQL with the features provided from my web hosts. Is there any easy way to do it that way?
Thanks in advance,
Lloyd
You can add a small WCF service to your website with an ISaveScores interface. The SL app can connect to the WCF service to post scores, and the WCF service can then store the data however you want. If you use a csv file, make sure you handle locking properly, since it is very possible for multiple requests to happen simultaneously.
EDIT
Since the host is Linux, just create yourself a rest service or some other service that silverlight can post to in the same way. Silverlight can talk to pretty much any type of service, so use the same technique in your environment.
You could do it with a service as Brian suggested (although it sounds like you might not have windows hosting, so you may not be able to use WCF for it) which is probably the best way -- but if you wanted a simpler solution you could also do it with just a postback to a particular page setup for the purpose.
Write a quickee PHP page that looks for a name and score in POST data, and writes it to your MYSQL database. Call it from your SL app with a webrequest. Then you just need another simple page to query the DB and list the results.
We are building a system that interacts with an external system over TCP/IP using the FIX Protocol. I've used WCF to communicate from client to server, where I had control over both client and server, but never to an external TCP/IP based system. Is this possible with WCF? If so, could the community provide links for me to get started and faced in the right direction?
Unfortunately I do not have much more information that what is supplied above, as we are still in the early early planning stages. What we know is that we have an external vendor whose system will communicate with our system over TCP/IP. We would like to use this as a learning opportunity and learn WCF.
Possible? Possibly yes, but it's going to take some work.
For starters, you will need to write a custom WCF Transport Channel that handles the specifics of your TCP/IP based protocols (i.e. you'll need to write all the socket handling code and hook that into the WCF channel model). This is because the TCP channel in WCF isn't for this kind of work, but uses a relatively proprietary and undocumented wire protocol.
I'm not familiar enough with FIX to say how complex it would be, but there are some gotchas when writing WCF channels and documentation in that area isn't great.
The second part you'll need to deal with is message encoding. To WCF, all messages are XML. That is, once a message is passed on to the WCF stack, it has to look like an XML infoset at runtime. FIX doesn't use XML (afaik), so you'll need to adapt it a bit.
There are two ways you can go around it:
The easy way: Assume the server/client will use a specific interface and format for the data, and have your channel do all the hard work of translating the FIX messages to/from that format. The simplest example of this would be to have your WCF code use a simple service contract with one method taking a string and then just encapsulating the FIX message string into the XML format that satisfies the data contract serializer for that contract. The user code would still need to deal with decoding the FIX format later, though.
Do all the hard work in a custom WCF MessageEncoder. It's a bit more complex, but potentially cleaner and more reusable (and you could do more complex things like better streaming and so on).
The big question though is whether this is worth it. What is your reasoning for wanting to use WCF for this? Leveraging the programming model? I think that's an important consideration, but also keep in mind that the abstractions that WCF provides come at a price. In particular, some aspects of WCF can be problematic if you have very real-time requirements, which I understand is common in the kind of financial environment you're looking at.
If that's the case, it may very well be that you'd be better served by skipping WCF and sticking a little closer to the metal. You'll need to do the socket work anyway, so that's something to consider there.
Hope this helps :)
I don't think it is possible, at least it won't be easy to set it up because you don't know the communication protocol of the other end, except for it's TCP and accept FIX tags.
Why don't you within WCF application open TCP connection a SOCKET. That should do the trick in a simpler manner.
I think so. I have a system that I almost got working that was supposed to do almost exactly that (WCF over HTTP from the internet). The server provider seemed to not want to allow it thought so you will need the right permissions on that end to make it work.
Up shot: I don't see why not.
Not really - Ms didn't make the TCP/IP connection handler to talk to non-WCF services, they assumed you'd write a Web Service to do that.
This is discussed here on SO.