Anyone aware of any good examples/resources using WCF to interact with Oracle AQ (Advanced Queueing), possibly even a custom binding?
Thanks.
To my mind WCF solves the same problems as OracleAQ can provide. WCF is tightly coupled by data contracts and can be bound to multiple transport types. OracleAQ is configurable by data contract (via registered XSD) or use a RAW xml queue. I am not aware of customer binding to differing transport mechanisms for OracleAQ and is very well documented and supported by ODAC. This wasn't the case for OO4O chatting to 9i but that's another story...
I would consider expending effort on implementing OracleAQ support within the client connection as this follows a similar overall pattern to WCF. Putting a service in between OracleAQ and the client endpoint to translate bindings doesn't appear to make sense other than introducing a level of complexity.
Related
I was searching for some STOMP/Websocket examples with Spring and I found a lot of chats or news applications like this:
I would like to know why the client is coupled with the broker (look at the arrow from Request channel to Simple broker) instead of interacting only with the Spring application. Also, beyond the coupling between client and the broker technology, I think that this architecture allows the client to publish in the broker bypassing the application (that, for instance, maybe it would like to implement some spam filter).
In some sense, this is like using the endpoints of some application and at the same time be able to query the application's database. It looks like an antipattern and I cannot find any advantage, only disadvantages like no decoupling and security issues.
I saw a lot of architectures using STOMP/Websocket designed in this way so probably I am not seeing something.
Thanks in advance.
the technology stack in our company are:
Java, Spring MVC, Spring Boot, Jaxws etc..
and we provide webservices for the client to querying our services.
in terms of securing the SOAP service. some of the webservices uses spring OAuth security and some of them uses the Spring Basic Auth
recently one of the client flooded our server by sending huge amount of request in the short period of time.
we are going to implement something to provent this to happen. ideally a
per client based calling interval. which can recognize the high calling frequency. then ban the client or force the client to wait
before we code this from the scratch, I wonder if there are libraries we can reuse. Spring normally very good at providing solutions for most of the enterprise issues. but so far I have't found any thing. any hint, ideally a working sample. would be great!
EDIT1: ideally we want to implement this instead of fully rely on the HTTP server e.g tomcat or apache to handle this. because our own implementation would offer more fine grained rules, such as how long the interval should be,
what kind of customised message we can return, more important we can implement our own monitoring mechanism, and treating different client with different traffic allowance etc...
A lot of materials about Service Bus mention that it uses AMQP 1.0. However, examples I have found use libraries that hide away AMQP layer, so it is not obvious how would one use generic AMQP 1.0 client and do things
that are listed in this Service Bus example
Being able to use independent AMQP client instead of supplied higher level clients might be important in several scenarios. For instance supplied clients might not be available at some platforms, or generic clients might provide more suitable way of working for particular problem.
Possibly related question
Little bit further from .net example I had linked in question I have found following example of how to access Service Bus with Proton AMQP 1.0 Python library. It shows how to send and receive messages.
What is lacking in that example, is how to create and manage queues and topics. It appears that this is not possible from AMQP interface, and needs to be done out of the band through either web azure console, or through REST interface.
I would like to deploy ActiveMQ in order to connect and communicate with other MOM implementations of jms such as WebsphereMQ, Tibco EMS, Oracle WebLogic JMS etc.
As far as I have researched online this seems to be possible by building a so-called bridge on top of activemq that will be able to communicate with the other end, regardless of the underlying wire protocol each jms implementation uses.
Examples though are scarce and often times minimal and so a point of confusion is whether I need to include jms client jars from each such implementation (Weblogic, WebsphereMQ, TIBCO EMS etc) in my classpath and bridge configuration. Can this be done without any such jars?
Since the goal is to connect to separate organizations MOMs I would like to avoid using any 3rd party, potentially licensed, jar.
...a point of confusion is whether I need to include JMS client jars
from each such implementation (Weblogic, Websphere MQ, TIBCO EMS etc)
in my classpath and bridge configuration. Can this be done without any
such jars?
TL;DR: You need the vendor's proprietary classes.
JMS defines the API and leaves the wire format and other implementation details to the transport vendor. Furthermore, in the proprietary implementations the wire formats can change significantly version to version. (One of the advantages of proprietary code is the ability to make such large structural changes when doing so improves performance, reliability or function.)
The one place where two JMS implementations have commonality is when the messages are in memory. Since all of the transport vendor's implementations inherit from the same Java JMS classes, it is usually possible to instantiate message objects from two different transport vendors and copy from one to the other. To do this, you must have the jars of each supported transport provider.
In fact, this is how most JMS bridge products that I've used work. The bridge code uses fully-qualified class names to reference the classes from two different vendors. It then creates two connection factories, one for each transport, and two different destinations, also one for each transport. It then reads a message from a queue on one provider, copies it to the message object on the other transport provider, then writes the message.
There are of course many "gotchas" with this approach. I'll list a few of the obvious ones:
Mapping destinations across providers is manual.
Identity propagation is not enforceable and requires the bridge to have quasi- or full-admin rights.
Transactionality across the providers is at best difficult, at worst impossible.
Correlation identifiers must be mapped by the bridge if they are mapped at all. This makes the bridge more complex and requires it to use a database or other persistent storage.
The vendor-specific classes often have a superset of the attributes and methods specified by the JMS spec. If used, these are stripped away during the copy.
Due to message segmentation, grouping and other affinities, there may not be a 1:1 correlation across the bridge.
Due to differences in implementation of such things as high availability, the physical network structure of one transport provider may not map 1:1 to that of another transport provider. This tends to limit the bridge function to the simplest common denominator of the two transports.
The issues raised by a general-purpose bridge include all of the issues of a 2-party bridge, raised as the exponent of the number of transports supported. So if a 2-transport bridge is of difficulty x, then for planning purposes assume a 5 transport bridge is of difficulty (x)**5.
That's not to say "don't code a bridge" since these turn out to be very useful. Just be aware, it's not a trivial task.
I am afraid that's not possible at least on the IBM MQ end. JMS is just an API and each provider is free to implement it the way they see it fits (as you rightly said its not a wire protocol). provider jars are essential to connect to a JMS product.
We have concept called Virtual destinations, try that
I have just read about CORBA and JMS, they both seem to be used to implement
Broker Architecture/Pattern.
I have few questions regarding them
1.The differences between them are still not clear to me, anybody please explain ?
2.Is CORBA is used in today's IT Solutions ? Or is it losing charm ?
3.Does JMS can replace every aspect of CORBA ?
Ramon Gil Moreno is right in stating that
JMS is the Java API that allows building applications to send and
receive messages. IBM MQ or ActiveMQ are samples of JMS vendors that
implements this API.
CORBA on the other hand is a specification that specifies how objects can interact with each other over a network across programming languages and run-time platforms.
The standard includes many APIs and infrastructure definitions (language bindings, marshalling, naming etc.), that are needed to support this. CORBA is still being used, and is Open Source as well as commercial (hard to find!)
Implementations exist, but I doubt if any of them covers 10% of the standard. Ramon's statement that CORBA is closer to RMI is a bit too simple - CORBA 2.4+ definitions include a CORBA Messaging definition that allows asynchronous and (reliable) queued communication.
CORBA, which is not hot nowdays, allows objects to be used remotely by different systems. It is more similar to RMI.
JMS is the Java API that allows building applications that send and receive messages. IBM MQ or ActiveMQ are samples of products that implements this API.