I'm interested in use apache synapse to monitor Apache ODE invocations, exists any configuration to redirect all Apache ODE calls changing the endpoint and adding WSA-TO header?
Exists any other way to do that just changing the apache ODE configuration?
I've been looking in ODE's documentation all references to redirections are modifying the the processes definitions (BPELs)
https://ode.apache.org/endpoint-references.html
Thanks
You are correct that BPEL's support for endpoint reference manipulation is something that is done within a business process as part of its execution. This is typically to support dynamic addressing by extracting endpoints from messages or constructing them from some data within the exchange. I wouldn't try to modify your process definitions to have knowledge of your monitoring requirements. This should be external and if done properly then completely declarative.
If you're using Apache ODE within ServiceMix then you should be able to handle this with a Camel route. Have all of the endpoints for your process deployment target a small camel route where you can listen in or T the message or whatever behavior you're trying to monitor.
If you're using Apache ODE within a simple web container, then you can still bind the endpoints externally from the process to be the endpoint of your choosing. See their deployment descriptor documentation for more info.
Related
Is there a common way to establish a network connection from a CloudFoundry-Service to a CloudFoundry App which the service is bound to.
In typical fashion apps receive their bind credentials and establish network connections to provisioned service for example databases.
It would be very handy to establish a connection from a service to an app, so the service could scrape endpoints that are provided by the app.
Any thoughts on this, why is it / or isn't it possible, why could it be a bad idea.
Normally, you have your service and the application receives credentials from the service through the service binding (i.e. VCAP_SERVICES).
You want to reverse this arrangement, which is fine, but the service will need to have some way to know how to reach the applications. The way to do this would be through routes bound to your application.
I have seen something like this done before, this is roughly the process. I'm sure you can adapt it to your requirements.
Create a service broker. The broker is responsible for managing service instances and service credentials. The broker is notified when an instance is created and when a binding occurs. Your broker will need to handle these requests.
The broker, in addition to its normal responsibilities, is going to need to maintain state indicating which applications have instances & bindings. In addition, the broker is going to need to use the org/space/app guids it's provided through the service broker API and talk to the CloudFoundry API to fetch the routes for the applications that are bound to it. You don't usually get these through the service broker API, but since you want to talk to the applications from the service, you need this information. It gives the service a way to communicate with the application.
Your broker may also provide the service in question (i.e. talking to applications), or it can delegate to some other process/container/VM to provide the service. If your service does the latter, then you need a way to a.) create the process/container/VM and b.) pass along the information it requires to talk to your application.
Obviously, you need to code the logic that will take the routes for applications that have created instances and bindings and communicate with them.
There can be some limitations with using the routes. First, not all routes are public. For internal routes, it would be kind of complicated to allow the broker/service to talk to the app. The broker/service would need to be an application on CF and you would need to specifically allow that communication (would require more API calls). Second, some apps just don't have routes. Perhaps this won't happen in your case, but it's worth considering. Lastly, not all routes are HTTP, some can be TCP as well. Your broker/service would need to handle both of those.
A variation on the above process, instead of using routes or talking to the API, you could have your broker/service provide some mechanism through the credentials to the application such that it registers itself with the broker/service. Thus when your applications start, they'll read the service info, register with the service and then go about their business. In this way, the application would have some additional flexibility about what information it provides when it registers with the broker/service. The downside is that the app has to do some work to be compatible.
I am new to WSO2 ESB clustering, actually I'm still learning about it. I still don't understand the concept here.
In my case, I installed WSO2 ESB on 2 servers. My questions are:
1. Were both of the WSO2 ESB working as one application or as two separate applications?
2. If I configure one WSO2 ESB, will the other ESB have the same configuration?
3. If I configure a VFS proxy service the ESB to poll a file from specific directory, will it create a conflict when I poll a file? I think that both of the ESB will poll the same file.
Please enlighten me :) Thanks...
Check my answers inline.
Were both of the WSO2 ESB working as one application or as two separate applications?
In any cluster, applications or servers are working together to provide a high availability to the end users. It will work as one single server (application).
If I configure one WSO2 ESB, will the other ESB have the same configuration?
Yes. You can achieve this with the deployment synchronization. It will make sure all your changes are evenly distributed among other nodes of the cluster.
If I configure a VFS proxy service the ESB to poll a file from specific directory, will it create a conflict when I poll a file? I think that both of the ESB will poll the same file.
No. Since only one server is active at once. This should not be a problem.
You can learn more from the following link:
http://docs.wso2.org/display/CLUSTER420/Clustering+WSO2+Products
Were both of the WSO2 ESB working as one application or as two separate applications?
No, both ESBs are separate applications. The clustering is done mainly to ensure availability and scalability. So even a member in a cluster fails, others continue to operate.
If I configure one WSO2 ESB, will the other ESB have the same configuration?
Each ESB can get the same cluster configuration, but each will be separately identified by the LB that is fronting the cluster. Therefore, each member will get different IP addresses and even they can use different member-port to create cluster.
If I configure a VFS proxy service the ESB to poll a file from specific directory, will it create a conflict when I poll a file? I think that both of the ESB will poll the same file.
Each request is independently handled by separate ESB depending on the load balancer algorithm of the fronting LB. When two threads poll the same file, there can be conflicts. Since VFS transport deals with file operations, there are certain times that these can fail due to unavailability of some resources. In such a case, VFS transport is equipped with the following fault handling mechanism.
If you point the same directory in a clustered environment, both proxy services will try to poll files and cause issues. Therefore if you want to poll files in a clustered environment, best practice is to use inbound endpoints [1]. But if it is necessary to use proxy services you can apply the following property in your proxy, so that the proxy service will only operate in one server. Thus there will not be any conflicts between the two proxy services. Please refer [2] to further clarify this.
<parameter name="transport.vfs.ClusterAware">true</parameter>
[1]-https://docs.wso2.com/display/EI620/File+Inbound+Protocol
[2]-https://docs.wso2.com/display/ESB500/VFS+Transport
I am writing a biztalk orchestration that will need to call a web service, probably multiple web services, and probably more than once. I see two options before me; one, consume the wsdl in a separate code project, and call the web services from code in an expression shape, and two, consume it from Biz, get schemas, etc and call through request/response ports. What is the best practice here? On the one hand, if the wsdl is updated it will be easier to update the code than the schemas and ports, and it seems like a lot of clutter and work to build ports enough for multiple web service calls. On the other hand, all the tuning you can do at the port level(retries being one) makes it robust to call web service.
Also see this question here, which discusses a 3rd option, viz using add service reference in BizTalk as an alternative method to import XSD's.
IMO you would be defeating the point of using BizTalk by using .NET proxies to handle integration. For example:
You are hard coding the protocol (WCF), and now need to marshal request and response messages to / from your custom code. With a send port, any request-response mechanism can be configured at deployment time - especially useful for unit and integrating testing.
You will be losing all of the benefit of BizTalk's message delivery mechanisms, such as retries, backup transports, resume suspended messages, different maps for different ports, and arguably the whole pub sub ability, (e.g. what if multiple listeners want to listen to the responses from the called web services?)
Where will you store the WCF serviceModel config settings, such as the endpoint etc? i.e. You've lost the flexibility of binding files.
etc.
So, TL;DR Always use the WCF adapters in BizTalk
However, that said, am in agreement that updating generated items if the consumed service changes can be messy. FWIW, we mitigate some of this as follows:
Always create a separate, empty folder in which to import all the
imported generated artifacts.
Leave all the generated items 'as-is', i.e. don't be tempted to move the dummy .odx, or delete it (since it has the preconfigured Port Types)
Unfortunately this leaves the below actions which still need to be manually applied:
Remember to change the visibility of the Port Types to public if the artifacts are in a separate assembly to your orchestrations
Promoted and distinguished properties on the imported schemas need to be reapplied (e.g. remember to document screen shots after any change). Possibly this can be simplified or automated by saving and re-pasting in the <xs:annotation> section of the schma.
If you are using message contracts in your WCF service, and are reusing the same referenced messages across multiple applications, you will need to manually delete the duplicates created by the add generated items and then re-reference the existing schemas. (e.g. we have a standard 'response' message back to all BizTalk calls)
Interestingly, you can have a mixture of both infact. Check this out by Saravana Kumar!!!
It uses passthrough receive and consumes a webservice using the dll on the send port, without going through the pain of creating schemas and webports.
This gives all the power of Biztalk ( routing response, send port configuration, etc) and still the flexibility to change the schema without much fuss.
We have a system using EJB 3 Stateless bean which is also exposed as web service.
There's a integration request from other team that want our system to fire a notification to other system after invocation (by web services or other means). Since this is not totally related to our system I would prefer to have this feature loosely coupled with our own system instead of hard coding these features in to our system code.
Is there any feature on EJB or web services that can achieve what I desire? We would require a method level invocation listener so that when the EJB method/ web service get invoked, it can trigger a callback/message so we can do something according to it. I would expect it to be some kind of annotation/configuration for setting up JMS or something.
We are using JBoss as the application server. If there's any JBoss specific solution it's also welcomed.
I would suggest two options:
use JMS. When you mentioned loose coupling, JMS first crossed my mind - you can put a message on some queue/topic after method invocation and let the listener to perform futher actions. JMS messages can carry various kinds of objects - the only request is that class implements Serializable (ObjectMessage#setObject); other advantage is that you can (un)deploy your Stateless bean and other system independently. They can be on different JVMs.
use Interceptors. Technically, they would be invoked before your methods runs, but of course there is always some nice workaround :-) Here is the official documentation about Interceptors, but since you mentioned that you're using JBoss, there can be also found some interesting material on JBoss pages.
There is an excellent article by Young Yang that explains how to use wsimport to create web service client artifacts that have asynchronous web service calls. Asynchrony requires that the WSDL has the tag
<enableAsyncMapping>true</enableAsyncMapping>
in its bindings section. If you are using the bottom-up approach with JAX-WS annotated Java classes you can't do this directly in the WSDL because the WSDL is a generated artifact on the web server. Instead you use build tools like Ant or Maven to include this binding when wsimport is executed on the WSDL.
The generated client artifacts have asynchronous method calls that return a
Future<?>
or a
Response
which is a Future.
My question after reading Yang's article is why not just roll my own asynchronous web service calls using Executors and Futures. Do the artifacts created by wsimport offer some advantage that I can't see over a roll-your-own approach?
If anyone has experience or insight with both approaches I would appreciate your feedback.
In theory, the generated asynchronous clients wouldn't need to block threads. By passing an AsyncHandler, the system can use NIO to register for an event when the web service call is complete, and it can call that handler. No threads need to block at all.
If you put your synchronous web service call into an executor, it will still end up blocking a thread until the result arrives, although at least this blocking is limited to the thread pool in the executor.
As soon as you have many hundreds of threads floating around, your system performance will degrade due to context switching.
Whether the web service library under the hood actually uses NIO is another matter. It doesn't appear to be required by the JAX-WS specification. Using JDK 1.6 and setting a break point server side, I set 100 clients off to call the server. Using JVisualVM I attached to the client and could see that it had created one new thread per call to the server. Rubbish!
Looking around on the web I found that Apache CXF supports limiting the pool of threads used in async calls. Sure enough, using a client generated with CXF and putting the right libraries on the classpath as discussed here, a retest showed that only 25 threads were being used.
So why use the jax-ws API rather than build your own? Because building your own takes more work ;-)
I know that it does not reach the prompted question, but just complementing one information included on question:
"Instead you use build tools like Ant or Maven to include this binding when wsimport is executed on the WSDL."
It is possible generate the asynchronous client by a adding a custom xml file using the option -b to the wsimport:
Example:
wsimport -p helloAsyncClient -keep http://localhost:8080/helloservice?wsdl -b customAsync.xml
The customAsync.xml content:
<jaxws:bindings
wsdlLocation="http://localhost:8080/helloservice?wsdl"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws">
<jaxws:enableAsyncMapping>true</jaxws:enableAsyncMapping>
</jaxws:bindings>
It is just one more way to generate asynchronous client beyond by using ant or maven :)