Suppose I have 2 web services A and B in SOA project. Both web services are running on a remote servers. Web Service A depends on information available from only a locally installed desktop application on a human actor machine and thats all web service A does i.e. provide this information). There are hundreds of such human actors with the same locally installed application providing its own information that web service A needs. Web service B needs this information from web service A, the result of which (which is the whole benefit of this project) is provided to that human actor who originated this process (by loging into system and clicking some command button). So this human actor is acting like the consumer of Web service B. The question is how can I make this locally installed application act as Web Service A (in the context of SOA project)?
This question could best be answered by some one with extensive experience in Web services and SOA.
This SOA project uses java, like ESB based on Java and there is no Microsoft specific services running although the desktop application is a Windows application. The application provides c/C++ API for an external process to call and retrieve the information needed by Web service A. What I want is the both web services A and B are hosted on remote server and interacting with each other via ESB but the problem is how to make local application information available to Web Service A?
There are two types of solutions
The first: have the original client application add a parameter with the address of web service A, and use this address for calling the service.
The second: pass a more abstract user identifier from the client (actually, there's a good chance you have such a field in the service). and use a translation service to retrieve the physical address corresponding to this id.
To allow such translation, the desktop application that acts as a server needs to "register" with the translation service when starting up.
If you are using an ESB, or other SOA infrastructure (like a service directory, message queuing service) it will include much of the functionality you need to build the translation service.
regarding the actual hosting of the service in the client machine.
the simplest solution is to use a different process from the actual application, and just access the files or DB the application uses.
In this case you can use any infrastructure you like to develop the service.
a more complex scenario is when you need the actual application to supply the service. in this case you will need to have a thread in the application that listens to service requests.
if you are using WCF see Hosting Services about how to host a web service in your application.
EDIT
some additions regarding you clarification.
as I understand, the desktop application exposes a C\C++ API that is available for external processes on the same machine.
You can either write a web service that will use this API. Googling "C++ Web Services Windows" will give yo several relevant pointers on implementing those.
Another good option is to use a messaging infrastructure. most JMS providers provide API's in languages other then Java - including C++.
Your application will be a C++ windows service that listens and sends messages to you JMS provider.
Related
The Window desktop application provides C++ API that gives an array of customer information such as name and address. I want to expose this as SOAP Web Service with Security so that authorized clients (from remote servers Linux/Java based through ESB) of this web service can get this information at any time they want in SOA implementation (Java based).
The desktop application does not have a standard database. It stores its data internally. Its basically old custom built CRM application that is installed on each agent's PC box. Each agent has its own list of customers.
What are the steps to achieve this task?
Do I need to run this as Windows service?
The short answer is, yes, you can expose data from a desktop application through a SOAP web service. It is easier to do with C# and .NET, but not impossible to do from C++. What steps you need to take will depend on which platform you are developing for.
Roughly -
Implement an endpoint that supports SSL where clients can connect to your desktop application (using sockets in C++ or HTTPListener using .NET).
Write code that can receive and dispatch SOAP requests.
Handle SOAP requests and return properly formatted SOAP responses.
Handle WSDL requests.
Implement a security mechanism (cookie based or otherwise).
Using .NET, most of this is in the platform code already, you just have to put the pieces together. With C++, you may find some third party libraries but essentially you'll be writing your own.
You only need to implement a windows service if you want the data to be available while a desktop user is not logged in and running your desktop application. The challenge here is that you'll have to make sure the windows service can access the same data the desktop application is using.
Another strategy would be to access the data from your desktop application using the C++ API and Interop and implement the web service as a standard out of the box asmx hosted on IIS.
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs
Simple problem, actually. I am trying to evaluate the possibilities of Google Apps, using Python as development language. It seems practical to create a web application or web site with it, but how about creating web services?
I am not too interested in solutions to create a SOAP or REST service in Python for Google Apps, since a simple Google search should provide plenty of solutions. I am more interested in experiences and ease of use.
But the real question is: When comparing a web service in Google Apps with web services in the Microsoft Azure environment, which would provide the better performance? The best user experience? I don't care for the actual development languages but need a good comparison of pro's and cons of web services in both the Google App Engine and Microsoft Azure.
Somehow, Azure seems better suited for services while Google seems better for sites. A tough choice...
Would be very interesting to see if both could be combined into a single solution. :-)
Btw, choosing which engine to use also means choosing the proper development environment and programming language. While I'm proficient in .NET and Python and many other languages, the choice for the service engine determines my focus for future projects.
When building services in Windows Azure, they'd simply be processes running in your VM (Windows Server 2008 SP2 or R2 SP1). You can host services easily in any of the three role types:
Web Role (essentially Windows Server with IIS running) - just add a WCF endpoint to IIS or self-host from your own process).
Worker role (Windows Server with IIS not running) - self-host from your own process
VM role (your own Windows 2008 Server VM pushed to Windows Azure) - Host with whatever mechanism you install / set up.
Each VM in Windows Azure may expose a total of 5 endpoints. These can be a combination of input (external facing) and internal endpoint, each port supporting tcp, http, or https. You define endpoints in your vm role's properties.
Internal endpoints are only usable by other VMs in your deployment. You can't see them / access them from anywhere else, including other Windows Azure deployments. Input endpoints are accessible by the outside world.
If you want an app running in Google to access your Windows Azure service, simply connect to the endpoint via ip+port. The one thing you'll want to be aware of is bandwidth usage. Because your Google-hosted app will be in one data center and your Windows Azure service in another, you'll pay ingress / egress for data going in and out of your Windows Azure service (and I'm guessing there's an associated bandwidth charge on the Google side, but I'm not sure).
It's actually pretty simple to set up a service. For .NET-based examples, look at the labs in the Windows Azure Platform Training Kit (this also other good examples, such as setting up your first Windows Azure application). For a python service host, you'll need to execute python.exe from your VM role's OnStart() event handler, passing in your script name (and optionally port number to listen on). For a simple example of launching python.exe, look at Steve Marx's blog post here.
EDIT: If you're looking to host multiple services (e.g. multiple ports), you can choose to host them in a single VM role or in separate roles, to optimize for cost (with the known limit of 5 endpoints) or performance (scale each service independently).
I'm investigating integrating a 3rd party web application with PeopleSoft via web services. I'm not that familiar with PeopleSoft. After some initial investigation, it appears that in order to expose any PeopleSoft functionality as web services, you have to do some considerable configuration in the Integration Broker component of the PeopleTools module. It seems that you can either define internal PeopleSoft services with "service operations" and related "handlers" or you can create a PeopleSoft service for an existing "Component Interface." Then, you have to expose that PeopleSoft service as a web service.
Are there any standard, default, out-of-the-box web services available for a PeopleSoft system, or do you always need to go through the steps of defining them in the Integration Broker?
After looking at a system like Salesforce, which has a standard web services API, it seems like there might be something similar for PeopleSoft, but I'm not finding it. Am I on the right track in thinking that the Integration Broker is the only way to go, or am I just not aware of some standard web services API that exposes basic PeopleSoft functionaity as web services?
Integration Broker (IB) is what you need to expose business logic from peoplesoft and consume it with your 3rd party tool, or to consume a webservice from your tool in peoplesoft.
There are some out of the box messages, but most of them are made to have different PIA (PeopleSoft Internet Architecture) communicate.
Be aware, IB components were almost complemently remixed in peopletools version 8.47. So it's important to give your tool's version when talking about IB.
Never heard about a standalone API for implementing web services, outside of the IB framework. IB will use dedicated class to handle sending and reception of your messages. You mention it as the handler. And if a component interface need to be used it will be done throughout this class.
Integration broker is used to setup the basic configurations that will be used in exposing and using web services. this includes making nodes and its routing available for other system to use.
http://docs.oracle.com/cd/B14099_19/integrate.1012/b14060/int_broker.htm
There are many web services available in peoplesoft. you can alsi expose any componemnt as a web services by executing very simple steps.
http://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tibr/chapter.htm?File=tibr/htm/tibr14.htm
Custom web services can also be build.
What are the differences between a web service and a Windows service?
My experience has mostly been with Windows services, and I have never created a web service.
Do web services behave similarly to Windows services?
Can they have scheduling, run at certain times, etc.?
When you would use a web service in place of a Windows service, and vice versa?
They're about as different as two things can be.
A Windows service is an application that runs without a user being logged into the system, usually to process some data on the machine that needs no user intervention to work with.
A Web service is a website that, when contacted, returns XML (typically) in one of several standard formats for the service consumer to process.
One can't be substituted for the other. They are fundamentally different.
You are asking us to compare apples and oranges. I am posting definitions as well as links to further reading for you so you can see why these two things are exclusive and cannot be compared like you are trying to do.
Web service:
Web services are frequently just Internet application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services
Windows service:
A Windows service is a long-running executable that performs specific functions and which is designed not to require user intervention.
A web service is an HTTP interface to a system. For example: the Twitter API or the Google Maps API are REST web services.
A Windows Service is a background process that runs without user interaction.
The two are not related.
Webservices are simply a way of exposing services for consumption. They are about interaction between components.
A windows service is an executable that runs for a long time on a machine to perform some task.
You wouldn't use one in place of the other - they perform two entirely different functions.
For (a simple) example (to highlight the difference), if you wanted a method to pass control messages to your service, you could expose a webservice as the protocol through which third parties would communicate with your service.
A web service is software system used for machine to machine communication over a network.
Here's the wiki for Web Service.
A windows service, in contract, is a service that runs on an local machine.
Here's the wiki for Windows Service.
They are independent technologies, one would not replace the other.
I don't think there is a very large difference, a web service runs in IIS or Apache, a windows service doesn't. You can call windows service methods by using remoting and you can create windows service with WCF. The methods of a windows service can return xml or json too.
IIS 6 doesn't support all the WCF possibilities so we have build WCF windows services (this is called self hosting).
Both a web service and a windows service are apps that run in the background. You can use WCF to build both kind of services.
web service was mostly used in application integration between systems.
windows service was mostly used in background tasks, scheduled tasks.
A windows service program can call web service methods.
web service program cannot call window service methods.
A Web Service is a dll hosted by a web server and run as a web application and can be spun up upon request.
A windows service is an exe hosted by the operating system and runs continuously waiting on a request.