I'm using C# and I have windows form and web service...
I have a custom object that I want to send to the web service..
sometime, the object may contain a huge of data..
as a best performance, what is the best way to send a custom object to the web service?
Web Services are designed to handle custom objects as long as they eventually breakdown into some standard types. As per sending a huge data, there are MTOM and older DIME. If it's within LAN and against other .NET client, you might want to look into non-Web Services ways like Remoting or plain http.
See How to: Enable a Web Service to Send and Receive Large Amounts of Data.
If you are using / plan to use WCF within the network(as opposed to internet), named pipes on WCF is fast and simple. Use primitive types to pass objects. A string xml (although verbose) or a light weight binary object will do.
If it's a wsHttp webservice, use string, I can't think of any other way you would pass a custom object, unless the service knows about it.
Related
I have read a tutorial "web-service-php-mysql-xml-json".
It seems everything is ok. But then why we should use soap for web services?
When building web services you can go two ways:
SOAP
REST
Most people choose the path of less resistance, which is REST. This means simplicity, ease of development, using HTTP the way it's meant to be used, make good use of cache proxies, more human readable results etc.
SOAP on the other end is more heavyweight than REST and is also backed up by a large set of specifications. But because it is more complex (SOAP used to be the acronym for Simple Object Access Protocol – which proved to be... NOT) SOAP is not liked by lots of people.
Both approaches work and both have advantages and disadvantages.
For example, SOAP can make use of any transport protocol not just HTTP(S), SOAP offers more options when security is concerned, SOAP offers reliable messaging etc etc. REST on the other hand permits many different types of data formats, REST allows better support for browsers because of the JSON format, REST has better performance etc etc etc.
I’m not going to go into more details since you can find a lot of comparisons SOAP vs REST on the web. The thing that I want to emphasize is the fact that in some cases one works better than the other and it is up to you to determine and choose which one to implement given your particular case.
EDIT: To answer your question:
why use SOAP or REST? we can have web service without them?
Well, the W3C defines a web service as "a software system designed to support interoperable machine-to-machine interaction over a network".
OK... that's nice for a definition. But this is not the definition for SOAP/REST, this requirement can be successfully thrown at a communication protocol to handle.
So basically you could have a web service using whatever communication protocol you want (even creating your own) as long as is supports the "interoperable machine-to-machine interaction". This also means something else than SOAP or REST (OK... REST is not a protocol, I just use it here as reference to prove my point... so bear with me).
But you create a web service because you want some clients to use your service. And your clients are out there in the wild wild west (i.e. the web :D) and people there speak SOAP/REST. An there you come and say: "We relly don't like SOAP and REST here in our shop, we like stuff like RPC, CORBA and our own unique creation the "Bone Crusher 10000" protocol. If you want to do business with us, you go learn the "Bone Crusher 10000"". And your clients will say (eyebrow raised) "Yeaaaaah righttttt.....".
(I'm assuming here that your protocol won't be something ground shacking that will totally outclass SOAP/REST :D)
So, if you don't use SOAP/REST you will limit your target audience. It's like English for example. I'm not a native English speaker, are you? Well, it does not really matter since we are able to communicate in English. Want to try this in Icelandic? . Will you wait for me while I learn Icelandic, cause that's not my native language either?
As I already said, it is up to you to determine and choose what to implement given your particular case, but if you move away from known technology stacks you throw away what comes with that: lots of experience, resources, tools and communication options.
As a closing example, there's a lot of support for the SOAP protocol today and you can generate clients very easily starting from the WSDL file. And presto... your clients can communicate with your web service. Will it go as easy as this with "Bone Crusher 10000"? If you write the tools, provide the resources, support etc... Yes! But that will cost you time and money to create something that was already invented and is in wide use today.
An important point user159088 mentions in her/his answer is "[...] you can generate clients very easily starting from the WSDL file [...]"!
I'd like to further elaborate on this:
You can use SOAP in conjunction with WSDL which is standardized what means that people who know the standard (WSDL) can learn from it what operations a webservice offers and how data is exchanged.
This knowledge can be used f.e. to create tools that generate type safe binder classes/objects out of the WSDL file. You can make use of those generated classes (to make RPCs) without manually implementing the requests and encoding/parsing of the data that is exchanged.
Whereas for REST there is no standard (like a WSDL schema) on how the exchanged data looks like. As a result you often end up parsing the data on your own.
A second point is that REST works mainly with the HTTP(s) protocol (it is based on it). It uses the CRUD verbs (CREATE/READ/UPDATE/DELETE) of the HTTP(s) protocol. SOAP does not rely on it and can thus be used with other protocols as well.
I have a complex set of Library files that work with a large existing web site. What I'm trying to do is create web services that mimic the functionality of the website so that I can work on creating a mobile application as well.
The issue that I'm running into is that we can't serialize the complex objects I have created with the website. What is the best work around to re-coding the entire object structure into a serialized fashion. Would WCF be appropriate solution? I'm not very familiar with them so any details would be really helpful.
Any other ideas would great, or if there are any other tools available we can buy to help us with a solution.
Thanks in advance!
For me the WCF is clear favorite for your purpose. The main advantage of the usage WCF in your case I see the ability to return any data of any ContentType. Moreover WCF supports streaming of returned data which could also be very helpful if the size of file which you want to return from the service is large.
WCF allows you return data of the type Stream or Message. In the case you can set manually the WebOperationContext.Current.OutgoingResponse.ContentType to the value which you need ("image/jpeg" or "image/png" for example). You can find many example like this which demonstrate the technique. If you use .NET 4.0 you can use CreateTextResponse, CreateStreamResponse or other WebOperationContext Methods
See old answers: this, this and this as additional examples.
RESTful and document/message-style seem to be two trends to implement web services nowadays in general. By this, I mean REST vs SOAP, and document-style vs RPC-style.
My question is how compatible REST is with document-style web services. From my limited knowledge of REST, it is utilizing http GET/POST/PUT/DELETE verbs to perform CRUD-like operations on remote resources denoted by URLs, which lends it into a more "chatty" and remote-method like style, aka RPC style. On the other hand, document-style web services emphasize on coarse-grained calls, i.e. sending up a batch like request document with complex information, and expecting a response document back also with complex information. I cannot see how it can be accomplished nicely with REST, without declaring only one resource for "Response" and using POST verb all the time (which will defeat the purpose of REST).
As I am new in both document-style and RESTful web services, please excuse me for, and kindly point out, any ignorance in above assumptions. Thanks!
Your understanding of REST is misguided. This is not surprising nor your fault. There is far, far more mis-information about REST floating around on the internet than there is valid information.
REST is far more suited to the coarse-grain document style type of distributed interface than it is for a data oriented CRUD interface. Although there are similarities between CRUD operations and the HTTP GET/PUT/POST/DELETE there are subtle differences that are very significant to the architecture of your application.
I don't think you mean REST over SOAP. It is possible to do REST over SOAP, but to my knowledge nobody does it, and I have never seen an article talking about it.
SOAP is usually used for "Web Services" and REST is usually done over HTTP.
REST is really meant to be used with documents as long as you consider your document a resource.
GET allows you to retrieve the document. Obviously.
POST allows you to create a document. No need for your API to require the full content of the document to create it. It is up to you to decide what is required to actually create the document.
PUT allows to modify the document. Again, no need to force the client to send the whole document each time he wants to save. Your API may support delta updates sent through PUT requests.
DELETE obviously deletes the document. Again, you can design your API so that deletes does not actually destroy every bits of the document. You can create a system similar to a recycle bin.
What is nice with REST and working with documents is that the server response contains every information needed to understand the response. So if a new resource is created, you should send its location, same if a resource is moved, etc. All you have to document is the data types that will be used (XML formats, JSON, etc.)
Standard HTTP methods are just there because their behaviour is already defined and allow clients to easily discover your API as long as they know the URI.
I’ve been trying to wrap my head around how to expose my domain objects to the client. Whether I’m using a rich client or I’m using the web, I want to use the MVP and repository patterns.
What I’m trying to wrap my head around is how I expose my repository and model, which will be on the server. Is it even possible to expose complex business objects that have state via a web service, or will I have to use a proprietary technology that is not language/platform agnostic, like .Net remoting, EJB, COM+, DCOM, etc?
Some other constraints are that I don’t want to have to keep loading the complex domain object from the database or passing it all over the wire every time I want to do an operation. Some complex logic might be that certain areas of the screen might be disabled or invisible based on the users permissions in combination with the state of the object. Validation and error message information will also need to be displayed to the user. I want to be able to logically call a lot of my domain object operations as if it were running on the same machine.
With the web, you have free rein. You don’t have to expose your objects across service boundaries, so you can make them a rich as you would like. I’m trying to create an N-teir architecture that is rich and works when the client calling the model is on a different machine.
You can expose your domain objects like any other object through REST or web services. I think key is to understand that you will have to expose services that provide business value in a single call, and these do not necessarily map 1:1 to your repositories. So while you on the server may expect a single service call to use multiple repositories and perform various aggregations, the things you expose over any kind of web-service should be more or less complete results. The operations you expose on the service should not expose individual repositories but rather focus on meaningful operations that provide a given business value.
I hope this helps somewhat.
You can use a SOAP formater for .Net remoting,
but the resulting service will probably be hard
to consume as a service, and it will surly be very chatty.
If you want your domain model to be consumed as a service,it should be designed as a service.
As stated in domain driven design, a service is stateless, so it won't expose your objects directly. Your service should expose methods that provides meaningful business operations that will be executed as a single unit.
Usually consider that the model in your client is in a different bounded context because its concerns will be a bit different from the one on the server.
What I’m trying to wrap my head around
is how I expose my repository and
model, which will be on the server. Is
it even possible to expose complex
business objects that have state via a
web service, or will I have to use a
proprietary technology that is not
language/platform agnostic, like .Net
remoting, EJB, COM+, DCOM, etc?
A good domain model is going to be highly behavioral and designed around the problem domain (and your discussions with domain experts), I'd thus argue against designing it to be exposed to remote consumers (in the same way that designing it from the database or GUI first is a bad idea).
Instead I'd look at using a style like REST or messaging and decide on the interface you want to expose and then map to/from the domain. So if you went with REST you'd design your resources and API (URL's, representations, etc.) and then you'd need to fulfill it from the domain model.
If this becomes un-natural then you can always have multiple models, for example mapping a seperate read-only presentation specific model to the same data-source (or which wraps the complex behavioral domain model) is an approach I've used several times.
Some other constraints are that I
don’t want to have to keep loading the
complex domain object from the
database or passing it all over the
wire every time I want to do an
operation
Look at caching in HTTP and supporting multiple representations for a resource, also look at caching within your data-access solution.
Validation and error message
information will also need to be
displayed to the user. I want to be
able to logically call a lot of my
domain object operations as if it were
running on the same machine.
You can either represent this as a resource or more likely look at HTTP status codes and the response bodies you'd want to use in those situations.
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.