Dear All,,
I need to consume web service and they send me WSDL. I was added it to service reference and when I called method GetDataWarehouse() in WSDL I got error..
"The one-way operation 'SubmitAccessList' on ServiceContract 'DataWarehouseWebService' is configured for transaction flow. Transactions cannot be flowed over one-way operations."
SubmitAccessList is one of method in WSDL but I wonder because I didn`t used it for now..
Can you give me a hint?
Ok, what you use is pretty irrelevant - WDSL is "all or nothing" in that the tool looks at it all, or not at all. You can argue this is a limitation -it is - but in most cases not a relevant one.
What is funny that this looks - never experienced this myself - like an error, as in the provider got a very funny non-legal setup for his web service, which means and hints there is nothing you can do. It seems they implmenent a one way web service.... and the service contract is putting in transactions. BAD combo.... a transaction can not be properly handled without additional communication and feedback to the sender, so the one way paradigm (fire and forget) is not logically compatible.
If noone else has a better ansqwer... I would say contact the web service provider for support (and have them fix their service).
I gladly take a correction on this if anyone has a better idea ;)
Related
I need a advice on creating a architecture where i want API layer in between UI layer and Business Layer. UI layer should only consume rest services for displaying data.
Reason for doing this is that we need to expose same service for others clients like Ipad, Android etc.
Now my question is:-
1) Do we need dependence inject in this case? (i don't think so coz we are not going to use any reference at UI layer. The only thing is, we are manipulating the JSON returning by service.)
2) Will it hurt performance?
3) Is this the right approach?
Any help will be appreciated. Thanks
we're doing roughly the same thing now.
1) No, you can't.
2) No, twitter is api first, they seem to be doing ok. I guess technically it will, but it does mean you can scale horizontally so the extra hop overhead can easily be counteracted.
3) You have multiple ui clients so it seems like a decent viable solution.
Security
Security: Basic Authentication
Its the easiest to setup, but be aware the token is reversible, so use HTTPS to encrypt the communication.
The HTTP Authorization header containing the username and password is sent with every request to the api level.
You could use session but that requires a bit more setup.
There are plenty of how to's on setting up basic authenication in C# and web api.
The way i created an API for me was:
Project 1 : WebAPI serving as a portal to fetch data
Project 2 : Class Library, providing services to the WebAPI layer.
Project 3 : Class Library, providing data to my services layer using EF.
Now, different controllers in the web api project require different service objects(from project 2) to work with. I had to provide constructors for those controllers using DI. for this i used Autofac.
For you, your business layer would be Project 2.
Data flowing through one more Project layer might take some time, and you will need to put up exception handling and logging again in the API layer. i don't think performance should be big problem here.
In my experience I've seen such platform oriented approach - providing mSOA to N amount of clients. The architectural solution was a Facade that was hiding all the complex Business Layer requests and in the same time providing UI insensitive processing.
Will it hurt performance?
Not necessary - since it has knowledge of how to handle all required sub-systems requests. All the clients just know that they need a single JSON contract to get the job done, not which and how many of the services to call. By doing so - we have a much better and simplified communication. Take a look at the Mediation (intra-communication) pattern:
I have a WCF service that is locally created in C# (with a [ServiceContract] and [DataContract]) and uses webHttpBinding for binding.
I would like to invoke "GET" and "POST" operations outlined in the contract from a WF workflow, but I just can't seem to get anything to work. Here are some of the things I've tried (from VisualStudio 2012):
Adding a service reference. I hear this is supposed to create the activities I want (after compiling), but I can only find my service by running it and finding it by address. I cannot "Discover" the service, even if I include the projects for the service in my solution that has the Workflow project. No activities are created as a result.
Importing a service contract. This seems to work a little better, in that I get activities, but I only get ReceiveAndSendReply activities. It doesn't seem to matter whether I make the contract as part of my Workflow project (and import it), or create a normal reference to the service's WCF project (and then import the contract through that reference).
Filling in the fields of the Send and ReceiveReplyForSend components of a SendAndReceiveReply activity directly (this was actually what I tried first). No matter what I try, I always run into a wall with the error, "Manual addressing is enabled on this factory, so all messages sent must be pre-addressed."
This seems like something that should be fundamental to WF and a lot easier, but I'm just not getting it. Am I missing something simple?
All of our services take a ServiceCallContext object as a parameter. The service then creates a broker and tells the broker what connection string to use based on the ServiceCallContext.
In other words, some of our customers have their own databases so the service calls have to point the brokers to their databases.
I would like to take the code that looks at the ServiceCallContext and chooses the correct connection and put it in a base service class. My team lead doesn't like that idea because with services he feels that this would be 'hiding' behavior and that this would be a bad thing. He suggested that there may be better ways to accomplish the same thing through some sort of WCF extensions.
I honestly don't care how we implement the code so long as I can reuse it because I think it's absolutely silly for me to be rewriting it in every service I create. I began looking into some WCF videos on PluralSight and it looks like there's a lot of great stuff it can do but unfortunately I'm not quite sure where to start. Can anyone give me a little direction as to whether WCF can accomplish what I'm trying to do and if so what particular features of WCF am I looking for?
The functionality you need is a custom interceptor.
This allows you to tell the WCF stack to look at incoming messages and the do some action based on them. If you wrap the interceptor up into it's own assembly then you can reference it from multiple services.
We currently have an application (Client/Server) that communicates through WCF. We would like to move away from the WCF approach and use a REST approach instead.
There are a few reasons for this, such as overhead (in terms of size) and the possibility to use the same access method for both our Windows client (currently a WinForm client) and mobile devices.
We are also sometimes running the server on the Mono framework, and even though we have it up and running, we have seen some differences regarding how WCF is working on the Mono stack compared to the .NET Framework (so I would not like to use the WebHTTPBinding in WCF to handle REST).
The service also needs to be self-hosted (i.e. not in IIS).
The problem when shifting from WCF to other alternatives is related to contracts. I would like to make it possible to unit test the REST calls, and I would like a contract to be involved, enabling the clients to use proxy classes that they do not have to create by themselves - pretty much like WSDL.
The main idea for handing out proxy classes to developers is that the clients should be able to rely on the service provider to get the correct proxy classes and that they should not need to care about the URLs used.
Is there any way this could be done automatically, and if so - using what framework or method?
Having looked brifely at WebAPI, I came across an example of generating a proxy (http://www.codeproject.com/Tips/535260/Proxy-Object-Generation-for-MVC-and-WebAPI-Control). This would simplify for the developers, but would mean that I manually need to create the proxy for the developers to use.
Any suggestions would be appreciated :)
For Client side unit tests, you should create mock for your rest service responses.
Otherwise You can create a static mock page with all of your service responses.
I'm trying to find the most efficient way to create an error code list for my web service so that when certain problems occur my client app will know what it is. I don't want to return a lengthy string, so I'd rather use simple numbers. I'm just curious as to how some of you would create your own error code table for an asp.net app. Would you just create a bunch of constants, or an enum type in your web service? Or would you create some kind of class that only holds constants? I'm not sure what the best way to handle this would be. I don't want to instantiate a class just for errors codes every time someone hits the web service.
Edit: I should have been a little more specific. The web service does use data contracts, but doesn't use WCF. I'm using a home brewed implementation of JSON-RPC, which requires that an error code be stored in the response json.
Just a thought for you, but ... don't worry about creating the class, the garbage collector will dispose of it when you no longer need it, and if you use it often enough, then it will stay in the applications memory in Jit form so it will be performant!
Personally, I try to not worry that much about "performance" to the extreme as it is typically not even noticeable...
However, if you are worried, then you should look at creating a single static class which can be used application wide and instantiated on start up and hold the constants there as then a single in memory class will be used saving on memory and any perceived performance hit.
Best wishes
Matthew
Assuming you mean the WCF type of web services, you can use FaultContract to specify different errors and how to handle them on the client side.
You are not programming in C, why error codes?
Web service is broad here but I assume you mean WCF?
Anyway WCF throws a FaultException which bubbles up to the client and this is a lot better than using error codes. Error codes don't tell me anything, and can be prove to be a PITA to maintain later.
But if a FaultException occurs there are lots of information that I can glean from the object.
FaultException (or SomeException) > Error Code.