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.
Related
I am new to micro services and I am keen to use this architecture. I am interested to know what architecture structure should be used for systems with multiple customer interfaces where customer systems may use one or many of the available services. Here is a simple illustration of a couple of ways I think it would be used:
An example of this type of system could be:
Company with multiple staff using system for quotes of products
using products, quotes and users mirco services
Company with website to display products
using products micro service
Company with multiple staff using system for own quotes
using quotes and users micro services
Each of these companies would have their own custom build interface only displaying relevant services.
As in the illustrations all quotes, products and users could be stored local to the mirco services, using unique references to identify records for each company. I dont know if this is advisable as it could make data difficult to manage and could grow fast making it difficult to manage.
Alternatively I could store such as users and quotes local to the client system and reference the micro services for data thats generic. Here mirco services could be used just to handle common logic and return results. This does feel someone illogical and problematic to me.
I've not been able to find anything online to explain the best course of action for this scenario and would be grateful for any experienced feedback on this.
I am afraid you will not find many useful recipes or patterns for microservice architectures yet. I think that the relative quiet on your question is that it doesn’t have enough detail for anybody to readily grasp. I will make a wag:
From first principles, you have the concept of a quote which would have to interrogate the product to get a price and other details. It might need to access users to produce commission information, and customers for things like discounts and lead times. Similar concepts may be used in different applications; for example inventory, catalog, ordering [ slightly different from quote ].
The idea in microservices is to reduce the overlap between these concepts by dispatching the common operations as their own (micro) services, and constructing the aggregate services in terms of them. Just because something exists as a service does not mean it has to be publicly available. It can be private to just these services.
When you have strained your system into these single function services, the resulting system will communicate more, but will be able to be deployed more flexibly. For example, more resources &| redundancy might be applied to the product service if it is overtaxed by requests from many services. In the end, infrastructure like service mesh help to isolate the implementation of these micro services from the sorts of deployment considerations.
Don’t be misled into thinking there is a free lunch. Micro service architectures require more upfront work in defining the service boundaries. A failure in this critical area can yield much worse problems than a poorly scaled monolithic app. Even when you have defined your services well, you might find they rely upon external services that are not as well considered. The only solace there is that it is much easier to insulate your self from these if you have already insulated the rest of your system from its parts.
After much research following various courses online, video tutorials and some documentation provided by Netflix, I have come to understand the first structure in the diagram in the best solution.
Each service should be able to effectively function independently, with the exception of referencing other services for additional information. Each service should in effect be able to be picked up and put into another system without any need to be aware of anything beyond the API layer of the architecture.
I hope this is of some use to someone trying to get to grips with this architecture.
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>
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.
I'm trying to choose one of forgerock identity management solution (openAM, openIDM) and wso2 identity server for implementing Identity and Access Management solution.
I'm interested in using following features:
Single Sign-On (SSO)
Policy based access control
Managing user identities
Connecting to central repository like Active Directory, OpenLdap, Oracle Internet Directory etc.
Etc..
Both open source products looks viable. I'm interested in having all of the above features along with good API to implement these features, along with active community support.
Which one would be the best amongst two ?
Thanks.
I am an architect from WSO2 - mostly leading WSO2 Identity Server. I am trying to be not bias as much as possible :-)
Both products bring you a comprehensive Identity Management platform - having support for SAML2, OpenID, XACML 3.0, OAuth 2.0, SCIM, WS-Security standards.
Few unique features that I would like to highlight on WSO2 Identity Server are...
Decentralized Federated SAML2 IdPs (http://blog.facilelogin.com/2012/08/security-patterns-decentralized.html)
Distributed XACML PDPs
User friendly XACML PAP wizard
High scalability (We have a middle-east customer using WSO2 IS over an user base of 4 million for OpenID support.)
Cassandra based User Store ( To be used over 800 Million user base by one of our production customers)
Light-weight and Very low memory footprint. The stripped down version of WSO2 IS can be started with 64MB Heap Size and the standard versions runs with 96MB Heap.
Highly extensible. The architecture behind WSO2 IS is highly extensible. You can easily plugin your authenticators, user store, etc...
Support for multi-tenancy.
Suport for multiple user stores (AD, LDAP, JDBC)
Interoperability.
Part of a proven SOA product platform provided by WSO2.
Also, we are planning to add support for OpenID Connect this year with a set of improved Identity Management capabilities.
You can also read more about WSO2 Identity Server from http://blog.facilelogin.com/2012/08/wso2-identity-server-flexible.html
You will not get an unbiased answer from me for your question :-) "Which one would be the best amongst two ?". You will aso get answers from Forgerock and other folks here. Best would be to evaluate and decide.
I'm a product manager at ForgeRock, but not for the products you're mentioning (OpenAM, OpenIDM).
ForgeRock Open Identity Stack has complete support for all your requirements, based on existing standards such as the ones mentioned by Prabath. It presents a single, common REST API to interact across the platform.
It's easy to deploy, modular, lightweight and yet highly extensible.
But in my opinion the key point is that it's a proven solution, deployed by hundreds of organizations, with built-in internet scale. The solution has been chosen by telecom service providers, medium and large enterprises for internal or customer facing services.
And I agree with Prabath, now that you've got answers from ForgeRock and WSO2, best would be to evaluate and make your own decision.
Regards.
Ludovic.
I am currently evaluating WSO2. It has a more permissive APACHE LICENSING Model and a more friendly management model from my having met with ForgeRock people.
Abdul, please share your findings as I am looking at both as well. We implemented OpenSSO in production a couple years ago just prior to its transition to OpenAM. It was an excellent product with thought leadership and decent execution. Unfortunately the pending transition to OpenAM was too unnerving for some of us and we switched to another product at great, unnecessary cost and continue to look over our shoulder. Some downsides at the time were ability to migrate policy through lanes from dev-test-stage-prod, keeping configurations in sync, and issue resolution. Also, fine-grained policy was very new. So my info is a bit dated and I know they have matured since then.
Just starting with WSO2. It has strong thought leadership and good execution with several platforms per other reviews. Their base architecture looks solid and it's allowing them to create and consume/improve open source technology very quickly into integrated, commercially supported solutions.
Sorry for the very involved question, but this is something I've been researching for a while now and it is really frustrating me. I feel like in today's age we have a million and one ways to implement services tat are cross-platform (SOAP) and easy to build (thanks to .NET, java, and other frameworks). However, these technologies have been in the community for 5-10 years, but we are (or at least I am) constantly plagued with the same issues:
Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs.
Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this?
Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc.
Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers
Each one of these problems requires some type of custom solution implemented by the organization. Documentation and UDDIs for #1. Virtualization and load balancing hardware / software for #2. Tracing, writing exceptions to databases / logs, etc for #3. Custom deployment software for #4. I work for a mid-sized organization. I can't even imagine how a company the size of Sun, Google, or Microsoft would tackle these dilemmas.
Maybe my vision is unrealistic, but I dream of having a Framework per se that lives on top of a server cluster that manages all of the above. I was ecstatic to read about Microsoft's AppFabric since it really seems to extend some of the functionality of BizTalk to WCF service implementors: Caching, Hosting, Monitoring, etc. However, from what I've seen, I still don't feel it lives up to my dream for an all-in-one solution that assists the developer and organization in writing services that are scaled across clusters easily, deployed into the cluster easily, and identifiable, possibly even version-able.
So, I don't mean this post to be about my dream. I do actually have a question. For starters, is my dream / want completely unrealistic? Furthermore, what solutions are there available that attempt to solve these problems without confining us to a new and more proprietary way (BizTalk) of developing services? An lastly, in concern to a complete SOA / ESB solution, where do we see the most potential in the market right now or in the future?
I think that you are talking about different kinds of problems here.
1). Developers who don't read documentation. This is an endemic problem, not limited to SOA - just look at some questions on StackOverflow. At least the developer is asking you whether there is a service, rather then just duplicating logic in their own code. I don't see any technical solution to these kinds of problems, you've already provided good registries and documentation, but some developers prefer to talk to people. Maybe, even, this is actually a good thing - human interaction has value above the technical content of the interaction. Or maybe, you're too nice: "No, I won't answer that question, look it up."
2). Scaling. There are technologies addressing this issue. (Disclaimer I work for IBM, who sell some, so I'll reference these - I'm not intending to imply that IBM are the only vendor with solutions in this space.) There are products such as this that can provision a new machine, install a software stack and add it to a cluster to address workload changes. Then at a finer grained level of control in the Java EE world the Application Server can dynamically shape traffic and adjust clusters. See WebSphere Virtual Enterprise
3). Monitoring. I don't "get" what you expect here. In all likelyhood such tricky bugs will require application level trace. For some problems such as finding memory leaks and performance bottlenecks there are very good tools, at least in the Java EE world.
4). I can't speak to the .Net world, but I'd say that Java EE app servers do a reasonable job of deploying the apps across clusters smoothly, and in the cases where we use JNI and need DLLs deploying then we can use products such as the Tivoli stack I mention to manage this.
So, in summary, I do think that vendors are trying to address these issues. And I don't think your life would be simpler without SOA. Imagine instead the same problems applied to myriad separate, independent applications.
Here's my two cents.
I've been a developer at a company that used SOA incorrectly. The worst solution they implemented was field level validation of form elements on a desktop app using SOA. To perform acceptably these require very low latency. A 2-4 second wait to change to a new field gets old fast. The service ran over the network on a biztalk server. Everyone hated it.
If you're going to do this you really need to spend a lot of time dealing with network latency, service failure, timing, and timeout issues.
Don't get carried away and think SOA is the solution to every problem. Used at a high level it's great, used at a low level it makes your applications fragile, slow, and impossible to debug.
If you talk to IBM or one of the big SOA vendors, they got a products that cover each scenario.
Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs.
Registry and Repository server. Nice thing is that it does governance (promotion, demotion, versioning, approval) and your ESB typically does a "lookup" for the latest and greatest against the register server.
Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this?
Transaction monitoring software like IBM Tivoli Composite Application Manager for SOA. Basically, it tracks things from a horizontal point of view and to see if there is a service disruption from a end user/end app point of view.
As far as your clustering.... you have to pick good middleware and architecture. Personally speaking, get stuff that is "cloud" ready. App Servers with NoSQL connected by MOM.
Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc.
Enterprise standards for your developers and for your vendors. Integration of all business and system events into a single dashboard. (Most companies spilt them). This is done already at most enterprise shops.
Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers
Ahh.. Microsoft IIS Web Deployment Tool 2.0. You can sync 100s of MS servers by just updating the master. It's really easy.