How are you doing!
I have a scenario where I need to create an OSB service(which is a mere pass-through service) that will be based on a WSDL that contains 2 ports, each pointing to a different URL. In this case, How do I create the proxy and business services. As I see, when I create the proxy service based on a Port, only one port can be selected at a time, so I'll need 2 OSB Services/proxies. If I select the binding, then the port informaiton won't come from the wsdl into the generated effective proxy wsdl, and it will have only one port, so even in this case, I'll have to generate 2 wsdl's for those 2 ports. Am I right? or Am I missing anything?
Another question on the same scenario
We are storing all the wsdl's in MDS, so need they are abstract(atleast not service/port information). So, in this case, if I make the wsdl as abstract, it will lose the port information, so how do I do? 2 business services, each pointing to a different URL? So even in this case, what about the proxy service? How can a proxy service that exposes one port cater to 2 different services?
Is there anyway that I can achieve this with a single OSB Service? I would prefer the 2nd approach of storing abstract wsdl's in MDS.
Regards
RaviKiran
When you create a Proxy service, you have full control over how that proxy service calls out to business services. In your case, something simple like an Operational Branch would suffice, but really, OSB allows you to control calling out to multiple services. You don't need to provide multiple ports for your proxy service, as you can make all the calls and control from inside.
Regarding your second question, it wouldn't matter if you're using abstract or concrete WSDLs in your OSB configuration for either the Proxy or the Business Services. You define the endpoint you're connecting to. In Business Services, OSB will take your WSDL and call whatever endpoint you tell it to. For a proxy service, the server OSB runs on will dictate what port address it's going to use, outside of the Endpoint URI that you've defined for it.
I would read Oracle's documentation on the Concepts and Architecture for OSB. It covers alot of this background information on implementing proxy and business services, and might point you to the more specific question you want answered. In particular, section 2.2 covers the Proxy and business service abstraction concept pretty well:
Oracle® Fusion Middleware Concepts and Architecture for Oracle Service Bus
11g Release 1 (11.1.1.7)
Related
Recently i have been doing some research about web services.
What i understand so far is that a web service is basically an API that communicates over HTTP.
There are Different kinds of web services:
SOAP web services (api that uses SOAP)
RESTful web services (api that uses The REST)
During my research those were the only ones mentioned except for one site. There they also mentioned:
XML-RPC
JSON-RPC
Are those also web services? And why aren't they mentioned?
If i said something wrong feel free to correct me.
Types of Web Services There are mainly two types of web services. SOAP
web services. RESTful web services.
-source: http://sfdcsrini.blogspot.com/2015/09/what-is-web-service-and-what-are.html
Broadly speaking, you're correct that there are two types of web service, but it's not SOAP vs. REST. It's RPC vs. ReST. There are other types of 'web' service which don't interact over HTTP, but they tend to be for specialist use cases these days so lets ignore them for now.
An RPC service is one where the API models some kind of abstract 'object' on which some defined set of 'methods' can be called - hence the name Remote Procedure Call. Any object defined in the API can have an arbitrary set of methods defined against them and HTTP is typically just used as a transport mechanism, with all the information required for the call to happen (object identifier, method name, call parameters) being serialised into a document which is transferred to the remote end via a POST operation and all objects are accessed via the same URI. Sometimes, query parameters on the URI are used to identify the object and/or method. SOAP and XML-RPC are both types of RPC implementation styles and are similar but not the same. JSON-RPC is another RPC mechanism, it just uses JSON to encode the RPC call rather than the more verbose XML.
ReST, on the other hand, is a resource oriented API style. In a ReSTful API the application communicates with 'resources' by transferring representations (i.e. serialised document formats) back and forth. Each resource has a consistent & well defined API and a unique address, called a URI. HTTP can then be used not just as a transport mechanism but, more importantly, also as an implementation of the API. So, the only way to interact with a resource in a ReSTful API is via one of the well-known HTTP methods - GET / PUT / POST / DELETE / PATCH. Not every API endpoint will implement every method but no endpoint will implement anything other than those methods.
The most important difference between the ReSTful approach and the RPC approach is what the data transferred means. In a ReSTful API the documents transferred represent the resource which the application wishes to manipulate whereas in an RPC the document transferred represents the method call which the caller wishes to make (or its response).
Two Type of API (Application Program Interface) was avilable.
That Was,
1)SOAP - Simple Object Access Protocol.
2)REST - Representational
State Transfer.
Say we have hosted a few webservices over over https://mycompany.com/Service
e.g.
https://mycompany.com/Service/Service1
https://mycompany.com/Service/Service2
https://mycompany.com/Service/Service3
As you can see on mycompany.com we have hosted 3 webservices each having their distinct urls.
What we have is a Jboss instance with 3 different web wars deployed in it. When someone hits the service it gets past our firewall and then teh load balancer redirects to Jboss on port 8080 on the requried path and it gets serviced.
the 3 services are consumed by 3 different clients. My question if say Client1 using Service 1 is only given out the url corresponding to it can they use some kind of scanner that can also inform them that Service2 and Service3 are alaso available on mycompany.com/Service?
Irrespective of clients - can anyone simply use some scanner tool to identify what Service Endpoints are exposed on the host?
Kindly note they are a mix of SOAP (WSDL) and Rest based services deployed on same instance of Jboss.
Yes, someone can scan for those endpoints. Their scanner would generate a bunch of 404s in your logs, because it would have to guess the other URLs. If you have some kind of rate limiting firewall, it might take them quite a long time. You should be checking the logs regularly anyway.
If you expose your URL to the public internet, relying on people not finding it is just security via obscurity. You should secure each URL using application-level security, and assume that the bad guys already have the URL.
You may want to consider adding subdomains for the separate applications (e.g. service1.mycompany.com, service2.mycompany.com) - this will make firewalling easier.
We are building a web application where we are following SAAS model using RESTful services for internal communication between modules.
There is a scenario where we want to resolve the host name of the server for RESTful service through one of the parameter value passed in the URL of service. In our architecture, each server instance wants to provide it's service for a set of values of a particular parameter in the URL.
In a dynamic environment, such responsibility can change from server to server. How can the client resolve dynamically which IP address it should contact to get a particular request served? Is there some sort of URL service registration and resolution facility similar to DNS, which can take into consideration some metadata like parameter's value in the resolution procedure? Any links to some existing solution or ideas for implementing such thing are welcome.
You can use a reverse-proxy as front-end of your service (all worker servers). It must be capable of directing request to appropriate back-end server based on some knowledge about application-level semantics in URLs, including parameters.
Here is the list of the most commonly used reverse-proxies:
Nginx (specifically about reverse-proxying)
Squid
Apache with mod_proxy
The main thing to note is that these general purpose products may not meet your needs well, in the sense of how flexible they can be congifured. This is why I wrote a custom reverse-proxy for a similar web-service myself (the project was implemented in Delphi, and I can provide some further details on this if needed).
I am reading so many things to understand various things in WCF.
Very soon, actually, i want to move/convert existing WSE3 web services to WCF. In existing WSE web services, I have some (data) classes that model entities in our environment.
While transforming those classes, should I use Data Contract/Data Member attribute or the MessageContract attribute?
1. How to decide between Message Contract and Data Contract in WCF?
2. Does type of binding (like basicHttpBinding) has any role in this decision?
3. Does proxies created at client side (when we add web reference) change significantly depending on the Data or Message Contract?
(PS: I am trying to find a way so that existing WSE clients should be able to consume the WCF service without much alterations/modifications. Is it possible to use the current proxies generated from ASMX web services, to connect to the new WCF service just by setting URL of the proxy to WCF service?)
Here is a quick go at answering your questions:
1) Unless there is a specific reason like tweaking the structure of the soap XML, use DataContract instead of MessageContract.
2 & PS) Since you are currently using soap over HTTP, you'll most likely need the new services to be configured for basicHttpBinding. This will provide the interoperability that you need for the ASMX clients.
3) It shouldn't if the soap structure created by the WCF service matches your current soap.
I vaguely remember that WSE 3.0 supported some of the WS-* standards. If your current code depends on these then you may be able to also expose a wsHttpBinding for these operations but I don't think a default ASMX client works with a wsHttpBinding configured service.
It depends on control you need over resulting SOAP message. DataContract defines part of message body wrapped by element defined by operation. MessageContract defines a structure of whole message - you can use multiple body members, you don't have to use default wrapper element and you can also place some data into SOAP headers.
In your scenario the most important part is to define WCF to use same SOAP messages as your former WSE3 service. Here the important is how do you currently serialize data? If you use Xml serialization (and attributes) you can use it directly in WCF by switchinig from data contract serialization to xml serialization.
Btw. why did you use WSE3 instead of plain ASMX? Did you use message security? In such case you will need another binding. BasicHttpBinding is not able to do message security.
General answer is yes, you can create service wich your current client proxies will be able to consume. But in reality the effort depends on your current service and current code.
I'm looking to add a web services interface to an existing server application. The set of services to expose is not known at compile time and can change over the runtime life of the server.
From a tech standpoint all the server/web services endpoints will be on Windows.
In our server app a user will have the option to register workflows as 'web services callable'. This will create the WSDL defining this particular workflow service.
For the calling endpoint I'm thinking of an HttpModule that accepts the inbound web service request, unpacks the request and converts the XML data types into our server applications "domain", calls the server and finally converts the server outputs back into XML for return down the http connection.
Does that make sense?
Critical comments welcomed.
In effect writing your own WS engine. Clearly doable, but quite a bit of work to get right from scratch. I guess if you find some open source implementation, then adapting it should be possible.
A rather dirtier alternative, but one I've seen applied in another context, is to go for a simgle WS interface
String call( String workkFlowName, String payload)
The payload and response are both Strings containing any XML. So the caller needs to undestand the schemas for those XMLs. From the client's perspective the amount of coding effort is not much different. Your coding effort would I think be significantly redcued.
an HttpModule that accepts the inbound
web service request, unpacks the
request and converts the XML data
types into our server applications
"domain", calls the server and finally
converts the server outputs back into
XML for return down the http
connection.
That is what all web service frameworks do (e.g. Metro, Axis). So I can't see your problem. What's your concern with this approach?
The downside for the client is that, as far as I understand it, availability of your services may change over time. So you should consider a way to inform the client if the service is available (other than getting a time out error because it is not there), e.g. WS-ResourceLifetime or UUDI.
I ended up creating a C# class that implements the IHttpHandler interface. The implementation serves up the WSDL of the services exposed from our app and accepts SOAP posts to invoke the services. In the end most of the work went on converting SOAP types to our types and vice versa.