I've been asked to come up with a .net web service stub for multiple similar webservices which will:
implement create/read/update/delete/find for an arbitrary object.
hold persistent xml data for objects of that type.
Is there anything out there that does this job already or anything that can make the job of creating it easier?
You may look at WCF Data Services. As usual with Microsoft products it is impossible to understand what it really does by looking at the front page, but is something of a "query a database by specifying the query in the URL in a standardized format (OData)". It creates a WCF service as a front end, and you should be able to write your own dataprovider for XML files.
It is arbitrary in the sense that the technology is independent of the object type, but you need to create a schema for its specific datatypes.
Related
I'm new in web services and I'm developing a C# WCF service that is calling an external service from another company to get some client data (for example: name, address, phone, etc), this part is working fine so far.
The external service is based on a standard XML Schema, and other companies will have soon the same service generated from the same XML Schema, using the same name methods and returning the same type of xml file.
My first question is that after I complete this first implementation, there is any way to add “dynamically” the other external companies services, having the information of their URL/Ports/etc, or do I have to insert each on them manually as services reference in my internal service project every time I need to add a new one, then compile and re-deploy?
My second question is related with the data contract /members, my understanding is that even if they are returning the same XML files, their data contracts/members will be different, is that true? So I’ll have to make a specific code to read the information I need from their data contracts for each new external company?? If this is true I have been thinking to make a generic code to read the raw xml, is this the best choice?
While C# is a compiled language it does support pluggin architecture through MEF. You could use this and add a small plugin .dll for each of your sources.
That being said it's quite possible that all you need is a configuration list containing connection details for each of your sources and connecting to them dynamically. That will only work if they're using the exact same schema, so that the objects they serve will serialize the same for all sources. You will have to instantiate the proxy dynamically through code using that configuration then, of course.
I should add something for your second question. As long as you're the one defining the contract, it doesn't matter if their actual objects are different. All you care about on your end is the xml they serve, and that you can connect using your representation. In fact, you can generate the contract as a .wsdl document. Each of the service-implementer can then generate domain objects from that. On the other hand if you're not the one "owning" the contract, some of the sources may decide to do it slightly differently, which will cause you a headache. Hopefully that's not your scenario though.
Best of luck! :)
My first question is that after I complete this first implementation, there is any way to add “dynamically” the other external companies services, having the information of their URL/Ports/etc
Unfortunately yes, you will have add service, compile it and deploy every time
My second question is related with the data contract /members, my understanding is that even if they are returning the same XML files, their data contracts/members will be different, is that true?
If you will use auto generated every service will create different contracts. I would think about creating you own class and convert external classes using reflection and extension methods
What is considered the best way to expose a type to another application over the web?
I know that this is possible by creating a type defined in a web service (WCF). Although, the consuming application wouldn't actually be making any method/service calls. Would it still be advisable to do this? Is there a better alternative?
Edit 1:
There is a website that needs to invoke our PC application. We are using a custom registered protocol which will allow them to pass query-string parameters to us. Many of these parameters are currently defined as Enum types. My goal is to expose these types so that the calling website is able to serialize the data and pass it via the query string safely.
Edit 2: Would JSON be a good way to achieve this? I haven't really delved into it too much but reading an overview seems like it would be a great alternative to what I've been rambling on about ;)
If you are asking about exposing complex types for webservices:
My webservices have either simple standard types linke integer or boolean or strings that contain xml for complex data.
the xml can be described by xsd-files to verify the content. There are also tools for many platforms that generate source code from xsd for the objectmodell. (i.e xsd.exe for Dotnet) there
> Best practices for exposing types over the web
I would use xsd.
If you want your api with structred types insted of xml you have to process yourself the article Contract-First Web Services my be helpful
Okay, so I have this Silverlight client program. I'm not allowed to use the web project, but I do need to be able to read from an SQL database for my data.
Some internet searching brought me to LINQ to SQL and the System.Data.Linq.DataContext object, as well as SQLMetal.exe. I have created my data context object from the meta data in a remote SQL database and the code looks okay (from what I can tell - all the right names and types seem to be there).
What I wanted to do was add this into Silverlight, but I realised, on importing the code, that you can't use System.Data in a Silverlight application, which sort of rules out having this code in the Silverlight client itself. Now this is annoying because a DataContext quite conveniently comes with properties which are tables and such like (I find those really convenient in Silverlight).
So I can't do it the 'normal way'. I can do it with a WCF service, but... well, here's where I could use some advice. I can create a WCF service with asynch calls, but I'm not really sure in what way to wire up the DataContext object. I mean... I need access to the classes in there within my Silverlight application (for my entities in the database) (and I'm not quite sure how to do that - help there would be appreciated). Then to synchronise it all up? Well, I could use some suggestions. For example, before, I have an exposed ObservableCollection. In its getter, it repopulated itself with the contents of, for example, Context.Customers. This made things nice and easy, but I can't see a way of doing something like that now. If I made a call to an asynch service for every 'get', surely this would be unacceptably slow.
If you could help me pick my way through this, I would be grateful. Thanks.
You definitely need to read about Entity Framewrok and couple articles about using WCF RIA + EF in Silverlight applications.
Hope, that will help you.
As mentioned above, you can use RIA services.
But more importantly... you should never use the classes that are generated in LINQ to SQL or EF in your client application. Your client application should only know about and use Domain Layer objects. Your datacontext and the types it uses should stay buried behind a repository pattern that gives you back Domain types.
Your client, whatever that may be (Silverlight app, WPF app, etc) only needs to (and should only) use these domain types. This is part of the whole separation of concerns and SOLID principles. Because I can guarantee you at some point in the lifecycle of the app you will swap out your source for data, so you may end up using Entity Framework, or NHibernate to talk to the db instead, in that case your client would be hard-wired to your LINQtoSQL types, and you wouldn't be able to swap out the ORM layer without breaking the client.
I need to create a .NET web service that accepts xml, uses this to query a database, and then returns xml. I have been given xsd files for the request and response. Could someone point me in the right direction for where I start from or an example?
I haven't used WCF before so would prefer to use a simple asmx file to do this. I know how to get the data from the database, so it's the xml and web service bits where I'm lost.
I've tried googling this for a while but don't know where to start. Thanks.
The problem you have is that asmx and WCF are both code-first web service technologies. What this means is that you generally start with classes and the web service stack takes care of exposing your types as XML across the wire.
You are starting with a schema, which is not code. So if you want to use asmx/wcf you need to model your schema in code. You can do this by inferring a class structure from your schema using xsd.exe (or svcutil.exe for WCF).
Alternatively you can model your classes by hand based on the schema definition.
Once you have your classes then you can add declarative attributes to the code (See http://msdn.microsoft.com/en-us/library/83y7df3e.aspx for asmx, DataContract and DataMember for WCF). These attributes control:
how an incoming stream of XML is deserialized to a type when a service request is received, and
how instances of your response types get serialized to XML when passed out of your service
The problem with this approach is that getting your XML to validate against your XSD schemas will be a little bit hit and miss, as you cannot rely 100% on class inference from XSD, and additionally you may miss some fine detail if you are modelling it by hand.
Whichever way you do it you need to make sure that your request and response class instances cleanly serialize into XML which will validate against the XSD schemas you have been given.
Also look at a framework called WSCF-Blue which allows you to do contract-first web service design: http://wscfblue.codeplex.com/
Good luck, if you need any more detail about this please let me know via a comment.
From what I can understand, you need to build a webservice, which will accept XML as input, do some processing and spit out XML.
I assume you have a basic understanding of XML but dont know anything about XSD. In very simple terms, XSD is a document which is used to validate a XML file. Think of it a rule book for how XML file should be structed, you can read more about XSD from W3schools. Dont worry about the XSD to much right now. Get a few sample XML documents, which you need to accept as input and output. Build a console application to parse the sample XML file and get the results from the database. Then use the results to build the output XML by looking at the output sample XML. Once you have that completed, then you can use the .NET classes to validate your input and output XML from the XSD you have.
You can look at this answer to see how validation is done.
Once that is done, you can create your web service to return the XML as string.
Hope this help.
I'm a complete neub to working with WCF but have been put on a project that needs it. Although not given as a requirement I want this service to seemlessly work with any client regardless of the technology it is written in (e.g. Java).
Basically, the client will send me a block of XML which I will validate and process. If all is well, I am going to return an XML document with 2 fields in it (an exit code and a message).
If I use DataContracts (with 1 write only and 2 read only properties) will that do the trick or is there more to this than I am seeing.
Thanks much!
Clay
DataContracts are not "the solution"; the DC is one possible approach for message serialization. whether you want to use DC depends on what the XML must look like, or can look like, and also how you want or need to map from objects in program memory to messages (xml documents or fragments).
In particular, if you want or need xml attributes in the messages, then DataContracts is probably not the way to go.
DC can support this kind of input message:
<request>
<flavor>7</flavor>
<param>eiueuie</param>
</request>
notice all data is stored as xml elements. DataContract will not work for this kind of message:
<request flavor='7'>
<param>eiueuie</param>
</request>
...in which any of the message data is stored in xml attributes. If you want to use XML Attributes, then you probably want to use the XML Serializer. If you don't care one way or the other then DC will probably be fine.
BUT, the Xml Serializer cannot map private fields or properties into XML elements, while DC Can. So, if your object model requires that, then you cannot use XML Serializer and you should use DC.
To find out more on the tradeoff between DC and XMLS, read this.
Having said all that, the decision on whether to use DC or not is just one part of your design. You will also need to decide whether you want full SOAP Envelope support (which allows for things like message signatures and so on) or whether you want the simpler "REST" message format, which is probably better called "plain old XML" .
And then there are things like instancing, hosting and activation (use IIS or self-host?), logging/auditing, security (authentication and authorization), and so on.
So, WCF can work for you, for any type of client, but the choice to use DataContracts or not is just one piece of the puzzle.
Data contract is just definition of transferred data - it is not domain object so making decision about what will be read only doesn't make sense. Client will deserialize the response and you will have no control over its processing of the data = client can change response anyway. Response can be also changed by any processing component in WCF pipeline.
Just start with DataContract and basic SOAP service (basicHttpBinding) or basic REST service (webHttpBinding + webHttpBehavior) and you will be fine.