so I have been reading Mule in Action for some time and have gained some knowledge on the features of Mule Studio. I have several questions regarding some specifications of a project(that utilizes web services) I am working on and I would be very grateful if someone could help understand how to implement them:
-Service management: I am required to investigate the possibility of having multiple versions of a same service. Meaning if an admin decided to add a different version of the same service it should be possible to alternate between the new and previous one.
-Using Mule studio the messages should be handled by priority. I think this can be done using JMS filters.
Thank you in advance for your time and help.
For versioning services you should try API Manager, it is an enterprise product.
About priorities, you are right, you can use a JMS selector in your flow to only consume messages of a certain priority:
<jms:inbound-endpoint queue="important.queue">
<jms:selector expression="JMSPriority=9"/>
</jms:inbound-endpoint>
Related
Im currently evaluating different middleware and WSO2 is coming up in the top as it has almost all feature we need to automate and integrate business processes, without need for wiring many different tools together: BPM, IM, Forms creation, API Management, BPMN runtime, etc. However, we are a relatively small company and I cant justify the costs of acquiring a subscription at the moment. Question is, is there anyone using WSO2 without subscription and just doing support/maintenance themselves on a production environment? Any hurdles to be aware of?
is there anyone using WSO2 without subscription
You can use them free as an open-source product without any subscription. There are many companies doing so.
Any hurdles to be aware of?
Part of the subscription service WSO2 issues patches and security updates, you should follow and apply the updates yourself (well, nothing forces you to do so, but I'd recommend to do it)
Looking at the number of questions we can see on Stack Overflow, there seem to be many companies that are using the free and open-source version of WSO2 products.
I am not sure if this is the appropriate place for this, but I have come up with a "conceptual" modular design architecture that separates the logic out into individual services to allow an almost plug and play type scenario whereby there are no dependencies between the services. Think a list of features and only enabling the ones that you want.
To facilitate this I realise that I will need some type of middleware that will connect these all together and control the flow of data. However I am not sure of the specifics around what would be appropriate to achieve this.
I plan on implementing the services using .NET soap based services, so is this a case of using something like Tibco?
Any suggestions around what would be most appropriate or even where to start looking would be great.
If the above description didn't make sense hopefully this image is a bit clearer in describing the relationship between the services.
Thanks.
Depending on your needs you could use NServiceBus (http://particular.net/nservicebus). NServiceBus is communication middle ware which can be used with different types of queuing systems like MSMQ, RabbitMQ and others. It is essentially a servicebus which is very developer friendly and focused. It does not only facilitate asynchronous message based distributed communication but also:
Publish / Subscribe that is transport agnostic using automatic registration
Transports: Can be used with MSMQ, RabbitMQ, Azure Storage Queues, etc.
Security: Supports encryption of messages
BLOB's: Has support for storing large message payloads transparently with the data bus to allow for communicatie message larger then the transport allows.
Scalability: Out and upscaling to increase throughput
Reliability: Deduplication, idempotent processing without having distributed transactions.
Orchestration: Sagas can help in controlling message flow and routing.
Exception handling: Exceptions get automatically retried in two different stages.
Monitoring: Tools like Service Pulse, Service Insight and Windows Performance monitors to monitor performance and errors. See what errors occurred and
Serialization: Can use different serializers that support formats like xml, json, binary
Open Source: All source code is available
Auditing: Can move all processed message to an audit queue for archiving or audit requirements
Community: Has a large community of developers that are active on the forums but also supply additional transports, serializers and other features.
I must mention that I work for Particular but also that there are other options to consider. NServiceBus does not use SOAP for message exchange but a lightweight message in a format of choice as mentioned as the serialization bullet. It can integrate with services that require SOAP. It has the ability to expose an service (endpoint) as a WCF service for easy integration and it can use SOAP from within code to call external SOAP services using the features that the .net framework and visual studio provide.
Good luck in choosing the right technology for your project.
I want to deploy an event processing stack, based on WSO2, but can't figure the Feature installation process.
I've downloaded latest Carbon (4.0.2) and want to install probably ESB, BRS, CEP, BAM and maybe later API Management.
I've connected to the Turing feature repository
2 questions:
in the available features list I don't see BAM or BRS, although ESB, CEP and API are there. What do I need to see these other parts ?
when I select CEP and ESB for installation I get a "install modified" and no features are selected.I imagine this is something to do with feature version incompatibility
if I just select ESB, the installation seems to proceed but the server won't restart (hangs waiting for one of the Synapse services.
It feels like I have the wrong process to determine what set of features/versions I need. How should I proceed ?
Carbon does not like to play well with it's other components. I've never been able to successfully use Carbon to manage any WSO2 stack. Each time I've setup/deployed a WSO2 stack I've ended up manually configuring the separate components config files individually. Usually starting with the ESB first, then adding in the CEP then the BAM.
You must also make sure they start in the correct order and that the config files don't stomp on each other (make sure your port offsets are set).
You don't need Carbon to run any instance of the WSO2 stack, simply 'install' it (unzip the wso2X.zip file) then make sure the service starts (call wso2X/bin/wso2server.sh start) and that's about it for the general setup, after that you need to configure each component to play nice with each other component (meaning you need to hook your BAM and CEP into your ESB, etc.) there isn't a lot of 'auto' config or discovery so it's usually easier to go the manual route with WSO2.
Also note that WSO2 products are Java extensions (essentially wrappers) around other Apache products (like Tomcat/Synapse) so usually if you are having a problem with WSO2, its because the underlying system (Tomcat/Synapse) was not properly configured (though that is no fault of your own as the WSO2 documentation does not make any mention of ensuring the base system is configured properly).
Also note that in my testing of WSO2 products, they consume huge amounts of memory (could not run more than the ESB and BAM on one machine because of the 8GB+ memory eaten by each) and a trouble ticket had to be put in to rectify a memory leak found in WSO2's Java modules, not sure if that was ever fixed.
Not trying to negate WSO2, but just be warned that it's not a pretty undertaking and you might fare better with other 'cloud' options if you have a choice.
edit: I've had to test out different 'cloud' stacks (with different types of 'plugins' or web services if you will) and how interoperable they were; as it turns out, they're pretty interoperable if YOU have total control over the individual stacks, otherwise the biggest downfall of any of the stacks that I found was simply documentation ... I don't care if a program has bugs or issues, as long as they are properly documented with possible workarounds (if any) so that I am aware of what is happening on my stack. Since WSO2's products were just Java wrappers for the Apache versions of their offerings (i.e. WSO2's ESB == Apache Synapse), any problems that occurred where usually solved in Apache's documentation (what little they had for certain problems) while WSO2's documentation had a lot of copy/paste issues (if they had any documentation beyond version 1). It was usually easier to just download and install the actual Apache offerings over WSO2's offerings then afterwards install WSO2's products and point them to the valid Apache configs/installs.
I did some testing with the Microsoft stack with Azure and general IIS/.NET offerings of equivalent services (The IIS/.NET equivalents of an ESB/CEP/BAM/etc. for what could be found). On the MS side, the documentation was enough (and there's enough people buying into the hype of cloud right now) that I could stand up most of the services semi-easy. I say semi-easy because of the misnomer (or my misunderstanding) of the 'ease of use' of 'cloud' services. I also found a product called Neuron ESB which is a .NET ESB offering, though I didn't do any thing with it during my testing so I can't speak to it.
Testing Amazon's offerings turned out the be some of the easier to setup and configure; the biggest issue with what I was testing for AWS was general internet latency.
Most of this is personal conjecture and I highly recommend you evaluate each as the 'cloud' space is constantly changing and each cloud platform has something slightly different to offer.
TLDR: the cloud space has a lot to offer and one should really consider what it is they are trying to achieve in the long run then evaluate each platforms offerings to see which fits. That being said, documentation and internal vendor interoperability (i.e. the vendor's products ability to easily communicate with each other) definitely help a product's 're-usability' factor.
Turing feature repository is not compatible with Carbon kernel 4.0.2. You can download Carbon kernel 4.2.0 and connect to Turing feature repository.
Do any of the major open source ESBs such as Mule or ServiceMix properly support web service transaction specifications (like http://en.wikipedia.org/wiki/WS-Atomic_Transaction)?
I've just briefly looked but it seems like support is not very good.
I would like to use the ESB to build macro services by composing from modular smaller services. I think this would be a pretty typical use of an ESB, and I don't see how you can implement anything practical if you don't have transactions.
WS Atomic Transaction is not in the list of supported WS-standards for Mule, so no luck here.
In term of design, the "transaction over SOAP" paradigm never really took off. Approaches likes stateful conversations with idempotent retries and compensations is usually what people prefer when integrating services over HTTP. It sure is more work than simply flipping the "transaction" switch on.
I have been fighting with this for a while now. I need to prototype SOA, and with it, the registry. I have been fiddling with jUDDIv3 on JBoss SOA Platform 5, but there don't appear to be any tools that allow me to publish to a v3 jUDDI registry. See my related questions here and here.
I realize after reading comments on those questions, and some articles on the internet (like this one) that UDDI is failing or dead, however my organization has some legacy tech we need to work with.
Also, my supervisor (I'm an intern) is adamant about sticking to standards. In principle, I agree with this, but perhaps a dead standard really isn't a much of a standard if nobody uses it.
In short, I need to provide the registry component of Service Oriented Architecture. It probably needs to be UDDI, so that it fits with the legacy tech, and satisfies the standard. Whatever the solution, it would be best if there were tools available that allow me to publish web services to that registry.
This problem has dragged on much longer than I would have liked. Any small piece of advice is really appreciated.
You may use WS-Discovery. WS-Discovery is a standard protocol for discovering services and service endpoints. This enables service clients to search for services based on a given criteria and bind with the discovered services. There are tow modes of WS-Discovery,
ad-hoc - servers advertise the services they have using a UDP multicast protocol
managed mode - servers and clients use an intermediary known as the discovery proxy for all service discovery purposes.
You can simply try this out with WSO2 Platform (free and open source under apache2 license). Please follow [1] to see a simple scenario of WS-Discovery in managed mode.
[1] http://charithaka.blogspot.com/2010/04/ws-discovery-with-wso2-carbon.html