Webmethods Integration Server can integrate systems and orchestrate different web services from external systems on the network.
My question is: Is it possible to create Java code running in Webmethods Integration Server, and expose it as a web service? Therefore, having Webmethods host the web service.
yes that's possible. You can use a Java service inside IS to code your logic. You have to define an interface for this service (a doctype). After this is done, you create a webservice provider that calls your service.
This applies to IS from version 7 upwards.
Absolutely, that's one of the core purposes of the platform.
To expose any service (flow, java, adapter service etc) you need to create a web service connector (of type "Provider") and then drag the services you want to expose onto it. You can then point to the WSDL it generates.
The approach of webMethods to have everything as a service means that any code you write on the Integration Server can be added to one of these providers and thus invoked as a web service.
You can also proxy other web services (e.g. the wrap and layer approach) by building a web service connector (Provider) using an existing WSDL. What it will then do is mimic the existing WSDL and allow you to provide an implementation of it.
Related
I know how to make web application in technologies like jsp/servlets and applications servers.
Suppose I make some utility method for particular application say ‘A’ and its working fine no any other web or desktop application in need of this method.
Same thing I can provide such utility method via web service like Rest/Soap.
So why I need web service in this scenario, I can imagine if such service is useful for other application and we provide it as web service then its fine.
Can anyone give me some answer which clear my doubt?
Thanks
Based on Your Comment, i would like to clarify.
Web service is a concept in which you expose a utility or functionality to the world.
Any one in the world can access the same by first establishing ground rules as in SOAP via WSDL.
The Services can serve any number of requests from any application provided it sends the proper input request needed by your service.
In case you have built an application A with a utility functionality X,
Then application B,C,D and so on can access the Web Service.
All it needs is:
the URL for the Service which is exposed through network to the consuming application
The requested parameter format
and the Proper Response format.
Once this is setup, any application, not just in java, can access the service so even .Net applications or PL/SQL applications can access the Web Service Utility.
As you can see, I'm really starting learning about Web Services and, in all examples I've seen, a new Web Project is created to implement the Web Service.
In my case, I already have a Web Application implemented and I need a WS to an Android app for this application. So, my question is: can I create the WS in this project or do I have to make a new project for that?
Any help will be apreciated, thanks.
Can I create the WS in this project or do I have to make a new project for that?
It depends on your design. Any web application can be the producer of the web services, so yes, you can use your current web application to host the services. But, there will be more requests to your application since there are new clients apart from internet browsers, so if your application is prepared to handle lots of requests, then do it. IMO it should be a different web application since they have different purposes, even if they use the same business services and data access layers, so if your main web application is undeployed for maintainability purposes, then your web application that hosts the services can be still up and running smoothly.
I have written a SOAP based web service which runs fine on a Tomcat server. The Web Service service itself is a Spring MVC based web service that runs on the Tomcat application server.
Now i need to write a Thick client which will be a standalone Java app that will use the services of the web service. I think i am correct in that the client only needs to know about the service details (i.e. operations) and nothing else.
What i am not sure of is the architecture and environment i should use for the client. The client application will be based on Swing but is it possible to use Spring with Swing together?
On the web service i have the following setup
view --> Service --> Model
The client application is basically a configuration tool. It uses the web service to configure user accounts. This means that the client application does not actually write anything to any database. It just uses the services of the web service to make changes to 'user account' and probably view list of accounts.
My question really is
- Is an MVC design suitable for such a use case
- Usually Spring is used for web based applications. Is there any benefit in using Spring with the Swing based client?
- Are there any alternative or better solutions/design/architecture that would achieve the same?
An example showing Spring used in conjunction with a Swing application would be very usefull.
Thanks in advance.
Spring MVC is not appropriate for a Swing-based client. Use the core Spring framework and a JAX-RS implementation like Jersey to provide simple REST web services in tomcat. Jersey also provides a corresponding client API that you can use within your Swing application to invoke the REST services.
If you have decided upon Swing as your platform, there are two options you can look at:
(1) Net Beans Rich Client Platform
http://netbeans.org/kb/trails/platform.html
(2) You can roll up your sleeves and write your own app using a low level yet extremely flexible framework called Swixml
http://www.swixml.org/
Give Swixml a good try before you try others, it may surprise you.
You can implement Swing-based thin client application with Spring Integration backend serving as a integration tier. It can expose gateways accepting simple Java types or DTOs. Your Swing presenters / controllers interacts with these components in order to call remote webservices.
I have SOAP web services for Application 1 available to me. And, I'd like to implement a Java application that translate Application 1's Web Services calls to Application 2's JMX API. So App 1 can manage a bunch of operations through App 2.
If I understand the problem correctly, I want to build a SOAP/JMX Proxy (Remote Proxy design pattern) as my translation layer. This means it will receive SOAP requests and translate them to JMX, forwarding the translated request and then do the inverse to return the response.
Do you have suggestions on this approach and if there is another way to proceed? Any pointers/corrections are highly appreciated.
Epitaph, this looks like a repost of your same question Ideas on how to approach a project involving Integration of APIs. In essence, it is the proxy pattern. Your web services are just calling another object via the JMX API.
Is there an elegant way to use Services across or between OSGi containers?
Is it even possible?
For instance, lets say I have a service interface on my local machine. What methodologies/technologies can I use to get that service interface accessible through a remote OSGi container's BundleContext?
There is a RFC called Remote Services (formerly Distributed OSGi) that does exactly what you are trying to achieve. The RFC is almost completed, and there are already 2 implementations provided respectively by Apache CXF and Eclipse ECF.
Both the implementations allows to do transparent remoting of an OSGi service. You just have to define the OSGi service as usual, and add some configuration parameters to make it a remote service.
Check:
http://cxf.apache.org/distributed-osgi.html
It is possible, but there are no libraries (afaik) that will do this for you. I've rolled my own for my current job. OSGi runtime on client and server, RMI is the transport. I've had to make HEAVY use of Proxy objects.
Register a service in the server's OSGi runtime (Equinox). I have a listener that watches all services looking for a property/attribute indicating this service should be exported (made remote), something like "remotable=true". It's easy to filter using the ServiceTracker. Over RMI I instruct the client to create a Proxy object with the service interface. All calls to this proxy object are generically send back over RMI (a call like execService serviceid, method name, var args params) and then invoked on the REAL service.
I've left out some of the low level details, but you can probably sort it out. If you can stray away from RMI, you may want to look into Riena (there may even be a way to write an RMI transport for Riena, I just haven't bothered to try)
It's not very clear what you are trying to achieve. You have got a service, you can access it using RMI, and you need to available as an OSGi service?
I guess you could write an interface to you local machine service. You could then write a bundle that connectes to that service and exposes that interface in the OSGi service registry. Then, your main bundle could locate that service using the interface name or service name.
It shouldn't be too much work to get an RMI connection to your local service. Maybe some config options to establish the initial connection. It might be important to write a facade for your service before you publish it in OSGi, in order to achieve some form of decoupling, and perhaps to hide the fact that it is an RMI service.
But then maybe I completely misunderstood you and all this is useless.
As well as CXF above, there's also Eclipse ECF, which is a collection of communication frameworks and provies an early implementation of the OSGi 4.2 remote services (aka distributed OSGi). It works by registering a local service to which your client binds in the VM, then creates a proxy on the remote machine, and using a technology of your choice (RMI, WebServices etc.) can remote the calls.
Obviously this uses by-value method invocation syntax (which your service needs to know about) but other than that, any comms errors are RuntimeException.
It certainly is possibly. Check out https://docs.paremus.com//display/NIM20/Home which includes an OSGi RSA implementation that includes a high performance RMI distribution provider.
Check the chapter "Remote Services" in the OSGi specification version 4.2.
It defines a standard way for distributing services between several OSGi containers.
The brand new version 4.3 of the OSGi spec has even more detailed support for this - see chapter 6 Remote Services and 112 Remote Service Admin Service.