I am using AMX Service Bus 3.2. and trying to expose my rest services (ASP.NET WebApi) through the TIBCO Active Matrix. Unfortunately I have not found any way to do this in TIBCO business studio.
I found TIBCO Active Matrix Binding Type for REST but it is intended only for promoted services. It allows to expose SOAP services via REST interface but it is unable to invoke my REST services hosted on IIS.
As for now I see the only one way to implement that - Create addition SOAP service that will redirect HTTP request from Promoted service to my REST Service. But such solution is not very good SOA design.
Any help is appreciated.
Related
Currently VS 2015 Update 2 provides an easy way to create owin based stateless web api service using create new service template for service fabric application. Is there a reason why only stateless web api service template is provided and not stateful web api service? If I wanted to, can I modify the stateless web api service to derive from stateful web service? Is it that simple? Or are there any gotchas with this approach?
Web Api is intended to be facade/public entry point to the service fabric app. Being stateless saves the clients from dealing with resolving partitions/addresses and other hassle.
If you want to - you can modify web api service and make it stateful. Maybe it would be even easier to create stateful service from the template, install missing packages (that web api template has), copy OwinCommunicationListener and Startup, wire them into CreateServiceReplicaListeners override, and add valid service endpoint to ServiceManifest.xml. OwinCommunicationListener will provide unique address for each replica.
Yup, you certainly can modify it to be stateful. Web API is great for internal service-to-service communication as well as a public-facing API.
There is a caveat that we are currently working through: The web host for stateless uses Kestrel, which presents some difficulties for stateful services where multiple replicas share the same process, because Kestrel doesn't have the same port-sharing capabilities that http.sys-based hosts do. We're working on a solution that makes it easier to use Kestrel for stateful, but in the meantime you can always use the WebListener host, which is the http.sys-based host.
If you're interested, I'm working on a project that will have an ASP.NET Core 1 stateful service (among other cool things) that you can track here: https://github.com/vturecek/service-fabric-xray.
I have an ASP.NET Web API 2.0 OData service project which I am trying to relay via a service reference + WCF Data Service (5.6) through an ASP.NET MVC project—the reason I am doing this is so users browsers’ can access the service without worrying about CORS for IE8 and IE9— so they will have the same host.
After some tinkering, this setup mostly works however there are some problems, my setup:
Service Project
1) ASP.NET Web API 2.0 OData endpoint
2) WCF Data Services 5.6 OData endpoint + Entity Framework 6.0.2 (EntityFrameworkDataService<DBContext>) using WCF Data Services Entity Framework Provider (1.0.0-alpha-2)
When I directly access both of these services they perform flawlessly with whatever I throw at them—both through a service reference, LINQPad, and raw URLs. Then I setup the ASP.NET MVC project:
ASP.NET MVC Project (relaying service references above): WCF Data Services 5.6, (DataService<ServiceReference-1-or-2>)
The problems come when I try to perform the same queries on the WCF Service acting as a relay:
Relaying (1) with $inlinecount=allpages gives me: “An error occurred while processing this request.”
Relaying (1) and (2) with $select=... both give me: “Not Implemented”.
When I relay a dummy POCO context through the reflection provider all of the operations work flawlessly on the relay WCF Data Service, which leads me to suspect that the problem is in the combination of WCF Data Services and the Service Reference, as they both work without problems independently… Perhaps the WCF Data Service is examining the LINQ Provider for the service reference and arbitrarily deciding that it does not support the operations?
I could live without $select but not having $inlinecount is a deal-breaker. There are a couple of alternate solutions I could take but I would really like to make this approach work: any ideas?
This was very similar to: WCF Data Service - Proxy mid-tier service
In a nutshell: you can have a relay by either
1) Making the service believe it is at a different URL than it is (so it is effectively broken for all access except through the proxy).
or
2) By writing another service which manually does the relaying to the service reference...
I chose none of the above and restructured my service as Web API Owin middleware. I lost the ability to have a separate service deployment but can easily swap in another piece of middlware and it makes CORS issues non-existent.
We have some legacy OData service code in our application which is written using a WCF Data Service.
Everything else in our system now uses Web API as the data interface so I am wanting to port our WCF OData Service to a Web API service with the OData annotations.
My question is, we currently use the OData service for standard CRUD statements and also a lot of Service Operations. Are there any limitations with Web API OData that would limit it compared to WCF Data Services (i.e relationship chains, service operation calls, etc.)? I'm wanting to get away with updating the service so the client side of things doesn't have to change at all.
I've started working on a similar port from WCF to WebAPI for OData with the recent release of Web API 2 and its support for $select and $expand - until then I could not really replace the data service. Service operations can be added as actions
I have been catching up with MVC4 Web API and WCF Data Service. From the surface, they both seem to be able to work with oData in the consuming client. I wonder which one is better for separation of concern (separate data service layer from UI layers). In my current solution, I have a plain MVC 3 style Intranet project and a MVC Data Service project. The 1st project has a Service Reference to the 2nd project. My goal is to write the data service once and make it available to all projects that would need to access underline database. When I read about Web API, it seems to me that the ApiControllers can return oData compliant result to the consuming client without MVC Data Service. My confusion is how I am going to expose this Web API MVC project as a service endpoint. Should I wrap it in WCF? Thanks.
You just create a controller inheriting ApiController and decorate one action with [Queryable] attribute, Rest depends on your route setup. Easy-Peasy.
Which one better? Web API. Since it has all the goodness of HTTP and you are not restricted to ATOM format.
You may use PocoHttp for seamless access of the data from your client.
im trying to understand where WSDL's fit in, in a typical web service backend application. i am coming from a Spring background and in my experience so far, in Spring, each url request gets mapped to a specific controller class via a dispate servlet running in the web container. you can specify which url matches a given controller via xml config or from annotations.
is using a WSDL the same thing as using an xml config file to map url requests to java objects?
Thanks in advance. im moving from Spring to standard j2ee/EJB3.
WSDL is just a description of Web Service interface, most Web Service systems generate those descriptions on fly like for example when you create asmx web services you can generate WSDL on fly by typing http://yourhost/yourwebcontext/yourwebservicename.asmx?wsdl and it will return you the description of that web service. Then you can use a tools that generate stub proxies for coding using those descriptions automatically, for example in Visual Studio when you add an Web Service Reference those operations are done automatically
No, WSDLs are not like a dispatch servlet.
A WSDL file is a description of a web service (SOAP, REST, etc.). A WSDL can (theoretically) be used by anyone to generate executable code which consumes the web service described by that WSDL.
From the WSDL tag info:
"WSDL" stands for "Web Services Description Language." It is an XML language used to describe a web service to code that wishes to consume it. It describes the messages sent and received, the possible faults, and the communication and security requirements.
From WSDL Essentials:
In a nutshell, WSDL represents a contract between the service requestor and the service provider, in much the same way that a Java interface represents a contract between client code and the actual Java object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services.
Using WSDL, a client can locate a web service and invoke any of its publicly available functions. With WSDL-aware tools, you can also automate this process, enabling applications to easily integrate new services with little or no manual code. WSDL therefore represents a cornerstone of the web service architecture, because it provides a common language for describing services and a platform for automatically integrating those services.