hello again, WSO2 community.
My last question about your architecture for my research is not a technical question, but a future-oriented one instead.
I was thinking about the OSGi approach the Suite has, that is one of the most interesting abstract things about SOA in general and WSO2 in particular I have found. An OSGi is sure a puzzling puzzle.
Thinking about pieces connected together reminded me about Service Component Architecture: a mean to see all the pieces as a whole easier.
Well, my question, son of my thoughts, is: "Why not to enable SCA for WSO2, when all the pieces have Carbon as a common denominator?" Carbon seems to be a nice candidate to be SCA.
The architecture could have only one instance of Carbon underneath, and WSO2 components above. The user should be able to interact with Carbon through only one interface and see all the pieces and their installed feature.
Is it possible? If it's not, why?
I hope I've been of some use through all the way here, and I thank you for having accompanied me to the end of my journey!
I hope there will occasions to collaborate or simply sharing ideas again!
It is conceptually similar to what it does with OSGi and Endpoint References in Carbon App model. Possibly can look at SCA Assembly as an alternative wiring model.
Related
I was going through design principles but could not understand this principle(avoid Micro layers), what would the significance be. I tried to google it but could not find any examples or explanation for this design principle. Could it possible for someone to explain this with example,what advantages it has in which scenarios? Does layering not localizes changes and reduces ripple effect of changes in software?
You’ve misinterpreted the way the principle is written. The author wasn’t trying to say “avoid micro services”. They were trying to say “When dealing with a micro service, don’t keep adding features or functionality to it. Instead, add an additional micro service to deliver the new functionality.”
The intent is to help you keep each micro service focused on a single task. This simplifies any system that depends on your service. And, it means you can more easily update your service — possibly by quickly rewriting it if you come up with a better performing design, for example. It’s hard to say “we’re going to rewrite our server” if that’s a six month task. It’s much easier when it’s only a one- or two-sprint task.
This thread needs a reboot coz of 2 reasons.
The Clean Code book that I have doesn't have a mention of Micro Layers. So not sure where the now "omni"-downloaded Clean Code cheat sheet got this from.
It would help if someone can guide me to where in the Clean Code book I can read on this one.
Am not fully satisfied that we re discussing Micro Layers in the scope of Micro Services. Bringing in an arch pattern Micro Services is not helping discuss a topic in a book that was written at a base level of Code and OOAD and a bit of design.
Instead for practical illustration purpose a code level example of the above statement is needed.
referred to some posts and videos for Microservices that how it works and what is the benefit of it but none of the examples or videos satisfy my confusion. can anyone help and can share some live examples which can be related to the App development methodology.
It isn´t essential but it is necessary according to the problem you are trying to solve. The fact that microservices becomes a popular way to build application does not mean it solve all the problems.
There are cases where you should rethink the use of microservice and to build a monolith application can be good enough for your scenarios or you will end with a distrbuted big ball of mud.
The Law of the instrument says something like:
If the only tool you have is a hammer, everything looks like a nail.
So, we can not make the assumption that microservice is essential for all scenarios in application development.
I have this question that keeps popping up and looking through my notes and slides I cannot seem to find the answer.
The question that's been asked is:
"In OSGi, how does a bundle make its interfaces known to the gateway. How is
this information used by the gateway"
I understand the principles of OSGi framework but I'm not sure how the interface becomes known.
Any help would be really appreciated :)
Thanks :)
It's called the Service Registry. Providers register their services, and consumers get their services from this facility.
It is an implementation of something called a Whiteboard Pattern, the gist of which is that providers and consumers don't directly interact or depend on each other. They have their offerings and requirements satisfied by a mutual 3rd party via published contracts (i.e. the interfaces).
As per title. I don't know if this is the right place or way to ask this, admins feel free to edit/move/close the question if appropriate.
I'd like to get pointers to recent material clarifying the market trends, as well as real life examples. Even pseudo-pundit, Gartner-like stuff is OK. Thanks.
I am curious about the second part of the question. What is the basis of your statement that 'the ESB thing' appears to be fading? I don't believe it is.
The problem with ESBs however is that some vendors call their product an ESB, but it actually is much much more than that. In some companies this happened with their integration product just because Gartner or some other analysts company says that ESB is hot. Marketing strategy is changed: The product is called ESB and maybe somethings are added that are expected in an ESB.
Paul Fremantle of WSO2 wrote a very good article about what an ESB really is [1].
As for OSGi: The first company I saw using it in their middleware was WSO2. I have heard, that TIBCO, another middleware vendor, is also moving or has moved towards using it in their Active Matrix platform.
OSGi may help in various ways. The most important is that it decreases the effort of the installation of the platform. Install a minimum on each system used to deploy the application, and during deployment the components required to run the application will be added. You do not have to worry about having installed the right plug-ins, add-ons and what not. This is what both WSO2 and TIBCO are doing.
With some vendors, you see that you need to install an awful amount of software, of which you in the end may be using just a small part (e.g. IBM WebSphere). Because of this, you may have to use over-dimensioned systems, which adds extra costs.
OSGi may prevent this.
Have a look at the presentation of WSO2 about the WSO2 Carbon platform [2].
The statement at the end of the presentation says it all:
Adapt the middleware to your architecture, not the architecture to the middleware
So yes, I think OSGi has a future in enterprise apps.
[1] http://wso2.org/library/2913
[2] http://www.slideshare.net/wso2.org/the-carbon-story-presentation-855666
Disclaimer:
I am in no way affiliated with WSO2, TIBCO or IBM. I am a certified TIBCO BusinessWorks Developer and have been developing applications for the IBM WebSphere Process Server platform. Above all, I am a WSO2 Enthusiast.
I would say yes..WSO2 has proof for that..Check the following links
http://osgi.dzone.com/articles/carbon-osgi-and-soa
http://www.infoworld.com/d/developer-world/wso2-upgrades-osgi-middleware-695
I'm studying business layer and need a complete reference which covers issues about "how to manage dependency between business layer and other layers", "how many ways are there to send data between layers" and most important for me "how to group business logic and make business component and talk about possible ways....".
do you know any reference?
EDIT:
I would be delighted if you introduce some e-book for it.
Thank you
the best (in my opinion) approaches to decoupling layers it to use a message passing metaphor. This way communication between the layers is done with messages that are types that contain information only pertinent to the communication. These light weight types are then interpreted by each layer as they see fit.
In essence don't pass things that are not needed. If both layers need a piece of information then there is a high likely hood that some other entity should be brokering access to that information (for example persisted data in db).
I recently stumbled onto this one and found it to be a great read (free ebook in PDF, or read it in MSDN), got the printed version on Amazon shortly after.
Microsoft Patterns & Practices Application Architecture Guide 2.0 -
http://apparchguide.codeplex.com/
EDIT: Here's the section on Business Layers in the MSDN version: http://msdn.microsoft.com/en-us/library/ee658103%28v=PandP.10%29.aspx
I think you should consider reading these books.
(source: infibeam.com)
How about something like
Three-Layered Services Application
(source: microsoft.com)
and
Layered Application