I am aware that a Java client can register as a client in a client-server model and register the Regions it is interested in. Also, when the data changes on the server, the data will automatically be sent to the client.
Is it possible to have this with a C++ client and a Java server?
Regards,
Yash
Definitely. Gemfire has a C++ client that supports pretty much everything the java client supports, including getting updates pushed to the client. Check out the documentation here:
http://gemfire.docs.pivotal.io/docs-gemfire/gemfire_nativeclient/about_native_client_users_guide.html
Related
I want to know if their any way to invoke a windows service from SQL query ?
note that : the windows service is installed on the same SQL server
Thank you
No, because windows services cannot be invoked. A service is just a process that is started by the SCM and responds to the SCM commands, there is no such concept as 'invoking' a service. What you can interact with is the service API, which implies a communication protocol with the service. Depending on the API and protocol used, that may be possible to do from T-SQL. Eg. COM based APIs can be interacted using sp_OAcreate, managed APIs may be interacted using SQLCLR and so on. But is always a Bad Idea. T-SQL is not the proper layer to introduce dependencies on external services, it may impact the SQL performance dramatically and, most importantly, is almost always incorrect due to not proerly considering rollbacks.
Do any/all service interaction in the application layer, where it belongs.
I have explored the web on MULE and got to understand that for Apps to communicate among themselves - even if they are deployed in the same Mule instance - they will have to use either TCP, HTTP or JMS transports.
VM isn't supported.
However I find this a bit contradictory to ESB principles. We should ideally be able to define EndPoints in and ESB and connect to that using any Transport? I may be wrong.
Also since all the apps are sharing the same JVM one would expect to be able to communicate via the in-memory VM queue rather than relying on a transactionless HTTP protocol, or TCP where number of connections one can make is dependent on server resources. Even for JMS we need to define and manage another queue and for heavy usage that may have impact on performances. Though I agree if we have distributed and clustered systems may be HTTP or JMS will be only options.
Is there any plan to incorporate VM as a inter-app communication protocol or is there any other way one Flow can communicate with another Flow Endpoint but in different app?
EDIT : - Answer from Mulesoft
http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Yes, we are thinking about inter-app communication for a future release.
Still is not clear when we are going to do it but we have a couple of ideas on how we want this feature to behave. We may create a server level configuration in which you can define resources to use in all your apps. There you would be able to define a VM connector and use it to send messages between apps in the same server.
As I said, this is just an idea.
Regarding the usage of VM as inter-app communication, only MuleSoft can answer if VM will have a future feature or not.
I don't think it's contradictory to the ESB principle. The "container" feature is pretty well defined in David A Chappell's "Enterprise Service Bus book" chapter 6. The container should try it's best to keep the applications isolated.
This will provide some benefits like "independently deployable integration services" (same chapter), easier clusterization, and other goodies.
You should approach same VM inter-app communications as if they where between apps placed in different servers.
Seems that Mule added in 3.5 version, a feature to enable communication between apps deployed in the same server. But sharing a VM connector is only available in the Enterprise edition.
Info:
http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains
Example:
http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/
I am developing services which will be consumed by many different platforms like Java,PHP,C or C++ etc. I want to know what protocol or binding type should I use for these kind of services. There should be a common protocol which can be used by all kind of technologies or most of them. I used BasicHTTPBindig for this purpose but this does not support transactions on client application. The supported Binding types are wsHttpBinding and others. I can use transactions supported types which are available with WCF but I don't know other technologies support them or not.
So the Question is What is the best Recommended Protocol or Binding type which support most of major technologies to consume WCF services.
Any kind of help/suggestion will be appreciated.
I expect that by client side transaction you mean distributed transaction (flowing transaction started at client to server). This is quite challenging because interoperable support for distributed transactions requires WS-AtomicTransaction and WS-Coordinator protocols to be implemented by the platform. In short almost none service stack provides these protocols (except WCF and several Java stacks). So you will probably make this work with .NET, Java, C/C++ (but the configuration will not be easy) but you will have a hard time to use it in PHP, Python, etc. These protocols are also not supported on mobile devices.
Distributed transactions are considered as internal server to server feature. So if you are going to make public service you should change your design. If you are going to make public service / service consumed by client applications (not servers) then you should choose basic HTTP binding (or create REST service) for maximal interoperability.
I haven't looked at WCF for awhile (I don't know what - if anything - has changed in .Net 4.0, for example) ... but if you wanted to interface to non-MS/non-WCF clients, you used to need WSE (Web Services Enhancements).
Here's a good link:
http://msdn.microsoft.com/en-us/library/ee958158.aspx
Just a technology update, now that .NET 4.0 is out.
I write an application that communicates to the server through what is basically a message bus (instead of method calls). This is based on the internal architecture of the application (which is multi threaded, passing the messages around).
There are a limited number of messages to go from the client to the server, quite a lot more from the server to the client. Most of those can be handled via a separate specialized mechanism, but at the end we talk of possibly 10-100 small messages per second going from the server to the client.
The client is supposed to operate under "internet conditions". THis means possibly home end users behind standard NAT devices (i.e. typical DSL routers) - a firewalled secure and thus "open" network can not be assumed.
I want to have as little latency and as little overhad for the communication as possible.
What is the technologally best way to handle the message bus callback? I Have no problem regularly calling to the server for message delivery if something needs to be sent...
...but what are my options to handle the messagtes from the server to the client?
WsDualHttp does work how? Especially under a NAT scenario?
Just as a note: polling is most likely out - the main problem here is that I would have a significant overhead OR a significant delay, both aren ot really wanted. Technically I would love some sort of streaming appraoch, where the server can write messags to a stream while he generates them and they get sent to the client as they come. Not esure this is doable with WCF, though (if not, I may acutally decide to handle the whole message part outside of WCF and just do control / login / setup / destruction via WCF).
For bidirectional communications, your best bet is NetTcpBinding, rather than the http bindings, if they're available.
This has the advantage of only requiring that the client can initiate a connection with the server.
I would go with Windows Azure Service Bus. See my answer in the following question:
WCF, 4.0, Bidirectional
Take a look at Windows AppFabric, good place to start is Here. It fundamentally wraps up WCF and WF into an application server, with WCF activation supported through WAS. Its where I would host this type of app. It offerd full duplex connection orientated, p2p or sessions between client and server. Don't confuse the Windows appfabric with Azure appfabric, (formely called Azure Service Bus).
As regards bindings above, both NetTcpBinding and WsDualHttp offer callbacks, but the ws binding you get a lot for your cash, especially if it's a mixed programming environment and you have to flatten the wsdl to make interop work. I also think that WsDual is easier on routers traversal, although I understand talking to friends, that Windows AppFabric mitigates this, with new Relay Services, (which i've not seen, and I think have now been renamed).
Hope that helps.
I understand to an extent that it helps applications communicate regardless of their location. Why is it important and what is an example of a real-world use of WCF?
WCF is a generic communication mechanism that allows you to setup generic client/host communication between two parties. The neat thing about WCF is that is allows you to configure service properties such as transport (http/pipes/tcp/Tibco EMS), security models (any of the W3C standards), compression, encoding, timeouts, etc, without changing ANY code. That is powerful. Best of all, you can configure it so that you can have a service in C# and a client in Java (or any other language or the other way around), as long as they both talk using the same mechanisms.
You can create a standard HTTP SOAP web service using WCF and one day decide to switch it to use the faster named pipes for local communication. You can create web services that talk over TibcoEMS and have easy failover on the queue level. You can create a file streaming web service that distributes all kinds of images/videos to your application.
Here Are some brain dump i think might be useful to understand the whole scenario.
Reason of Creating WCF : Background
Modern Application[Distributed Application] development we use different architechtures and technologies for communication
i.e:
COM+
.NET Enterprise Services
MSMQ
.NET Remoting
Web Services
As there are various technologies. they all have different architechtures. so learning all them are tricky and tedious.
one need to focus on each technologies to develop rather than the application business logic
so microsoft unifies the capabilities into single, common, general service oriented programming model for Communication. WCF provides a common approach using a common API which developers can focus on their application rather than on communication protocol.
Now-a-days we call it WCF.
N.B: image collected from - http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
What Exactly WCF Service Stands For?
WCF lets you asynchronus messages transform one service endpoint to another.
The Message Can be simple as
A Single Character
A word
sent as XML
complex data structure as a stream of binary data
Windows Communication Foundation(WCF) supports multiple language & platforms.
WCF Provides you a runtime environment for your services enabling you to expose CLR types as Services and to consume other Services as CLR Types.
A few sample scenarios include:
A secure service to process business transactions.
A service that supplies current data to others, such as a traffic report or other monitoring service.
A chat service that allows two people to communicate or exchange data in real time.
A dashboard application that polls one or more services for data and presents it in a logical presentation.
Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
A Silverlight application to poll a service for the latest data feeds.
Why on Earth We Should Use WCF?
from a Code Project Article, thanks to #Mehta Priya I found the following Scenarios to illustrate the concept. Let us consider two Scenario:
The first client is using java App to interact with our Service. So for interoperability this client wants the messages in XML format and the Protocol to be HTTP.
The Second client uses .NET so far better performance this clients wants messages in binary format and the protocol to be TCP.
Without WCF Services
now for the stated scenarios if we don't use WCF then what will happen let's see with the following images:
Scenario 1 :
Scenario 2:
These are two different technologies and have completely differently programming models. So the developers have to learn different technologies
so to unify & bring all technologies under one roof. Microsoft has come with a new programming model called WCF.
How WCF Make things easy ?
one implement a service and he/she can configure as many end points as it required to support all the client needs .
To support the above 2 client requirements
-we would configure 2 end points
-we can specify the protocols and message formats that we want to use in the end point of configuration
References:
WCF : What , Why and When https://vishalnayan.wordpress.com/2010/12/31/wcf-what-why-when/
Why we use WCF Service? http://www.codeproject.com/Tips/815742/Why-We-Use-WCF-Service-and-Sample-of-WCF-Service
What Is Windows Communication Foundation https://msdn.microsoft.com/en-us/library/ms731082(v=vs.110).aspx
Windows Communication Foundation Basics http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
There's little to add to the responses so far, especially the one from "siz".
One thing to add is that WCF is the current way to do web services on the .NET platform. It's not the "new" way, it's the current way. ASMX web services are the old and just barely maintained way. One Microsoft employee has publicly stated that only critical security fixes will be made to the ASMX platform, so if you intend for your services to be useful more than a year from now, don't use ASMX.
In addition to the typical "web service" use cases, WCF handles atypical cases, like binary communication over named pipes, message queues, etc. To a very large extent, the service you write to support something simple like SOAP over SSL can also support these other protocols, with no changes to the code.
To answer the "real world" bit, I'm just finishing up a dispatch system by which a Visual Basic 6.0/access alarm receiver, a WPF/SQL ERP system and an iPhone application all share information to schedule and execute jobs.
Essentially the use case is where you want two separate applications to talk to each other somehow and their locations are unknown (could be same machine (but different application domain), same network or on the other side of the internets)
You can easily embed it into a Windows Forms application. That was a nice thing to discover. It is so much easier than .NET Remoting too.
There are a number of reasons why it is advantageous over classic ASP.NET web services (.asmx).
A couple of these off the top of my head are:
The ability to have multiple bindings for the same service call means the message doesn't have to serialise into XML and back if you simply want to communicate inside a web farm.
The way contracts are defined is much more forgiving when it comes to multiple versions of the same contract.