I have being following this tutorial on Riena Remote Services. Is there a project or tutorial available so I can use Riena along with Declarative Services? I'm finding a bit of a challenge converting the above example into Declarative Services.
Related
I am trying to convert a normal monolithic web application into microservices structure using Spring Boot and Spring Cloud. I am actually trying to create Angular 2 front-end application and calls these my developed microservices in the cloud. And I am already started to break the modules into independent process's structure for microservice architecture.
Here my doubt is that, when designing the flow of control and microservice structure architecture, can I use only one single Spring Boot project using different controller for this entire web application back end process?
Somewhere I found that when I am reading develop all microservices using 2 different Spring Boot project. I am new to Spring and Spring Cloud. Is it possible to create all services in single project by using different modules?
Actually, it doesn't matter to package all those services into ONE project. But in micro-service's opinion, you should separate them into many independent projects. There are several questions you can ask yourself before transforming original architecture.
Is your application critical? Can user be tolerant of downtime while you must re-deploying whole package for updating only one service?
If there is no any dependency between services, why you want to put them together? Isn't it hard to develop or maintain?
Is the usage rate of each service the same? Maybe you can isolate those services and deploy them which are often to be invoked to a strong server.
Try to read this article Adopting Microservices at Netflix: Lessons for Architectural Design to understand the best practices for designing a microservices architecture. And for developing with Spring Cloud, you can also read this post Spring Cloud Netflix to know which components you should use in your architecture.
Currently I am working on microservices too, according my experience we have designed microservices as step below,
Maven
You should create the project with different project. But actually you can separate your project to submodule. So you will be easy to manage your project, the submodule you can use with other project too.
Build the Jar Library put your local repository. it can save your time, you have just find the same component or your functionality then build the jar file put in your local repository , so every project that use this function call point to download this repository, you don't have to write many project same same.
So finally I would like you to create different springboot project, but just create submodule and build local repository.
By creating your modules in different projects you create a more flexible solution.
You could even use different languages and technologies in a service in particular. E.g. one of your services could be NodeJS and the rest Java/Spring.
I am considering writing a new set of applications using OSGi, but they will need to interact heavily with existing non-OSGi applications.
To clarify, the new applications will need to call into existing non-OSGi code bases maintained by other teams (usually propriety services of varying protocols), and new non-OSGi applications will need to call the new OSGi services.
I am not seeing much documentation for how to do this.
Can someone please point me to the correct steps
It sounds like you want to embed OSGi into a larger application. A good starting point for this is a blog post I wrote some time ago: http://njbartlett.name/2011/07/03/embedding-osgi.html
The trick to creating visibility between OSGi bundles and the objects "outside" OSGi is to publish and/or consume services using the system bundle's BundleContext. The embedding code must be aware of the objects from the outer application that you want to make visible into OSGi, and it should publish them as services. Be aware that you need to export the service interface packages via the system bundle exports -- how to do this is described in the blog post.
OSGi services are only for communications inside the same JVM process. So I guess you want to communicate between processes. In this case you have all the usual remoting protocols like SOAP, Rest, RMI. On the OSGi side you can bridge from OSGi services to offering SOAP or REST endpoints using Distributed OSGi (DOSGi).
I’m currently “struggling” with OSGi services, or to be more specific, with the wiring between the services. I’m aware of the basics of DS, SCR and the general strategies for a component instance to acquire services. Anyway, here is my problem:
Following DS, components declare e.g. their provided and consumed services in a XML-file. In my case, I’m interested in the “consumed/referenced” services of a particular component (which are declared by the “Reference” tag in the component’s XML-file).
E.g. consider a running OSGi-application: a bunch of bundles collaborating with each other based on services (DS). Now, I want to pick a particular bundle and query all its references to the services it (may) consume - no matter if these services are currently available or not.
Referring to Apache Felix GoGo shell commands, like inspect requirements *, I do get information about the imported packages etc. but not a complete overview about the consumed services (-> both currently consumed services and services the component is waiting for).
I’ve read about the Framework API which provides insight in the registration, modification and deregistration of service but apparently, it does not provide the information about what services bundles are waiting for. Following the OSGi core specification, this could be achieved by a Listener Hook.
Isn’t there a way, where I just can query e.g. the SCR to get all referenced services of a specific bundle? Obviously, the SCR is supposed to read the bundle’s Service-Component-XML-file and to “register” some kind of “Service Tracker” to track the consumed/referenced services – hence the information of a bundle’s consumed/referenced services should somehow be available, shouldn’t it?
It would be great if you could help me with this.
Thanks,
Don
Checkout xray, http://softwaresimplexity.blogspot.com/2012/07/xray-again.html, from Peter Kriens.
My organisation is moving away from traditional EAR/WAR based applications and moving towards OSGi for building our business applications. The WSO2 platform provides a lot of support services (esb, governance, identity, etc) that we would want to leverage in our applications.
Is it possible to deploy our OSGi components directly to the WSO2 application server, or does it make more sense to deploy just to WSO2 carbon? Are there any issues that we should be considering with this approach?
WSO2 Carbon is the Core server for WSO2 platform which includes all common features used as the base for WSO2 products. Application Server is Carbon Server + Service Hosting features and few others which is used for service hosting aspect. You can use Carbon Server directly to deploy OSGi bundles. You can install any of the features you need through configure-->features
by just adding a P2 repository. if you do not need Service hosting features just start from Carbon server and add any features you need to fulfill your need. (feature is a collection of OSGi bundles which cater one aspect). You can build your p2 repository and install your features directly to Carbon Server as it is normally done. There are several methods to drop your OSGi bundle into WSO2 Carbon based servers.
Following link will help you to understand How OSGi is used inside Carbon Server.
WSO2 A.S. is based on a Carbon platform, like every other WSO2 instances, so it should not make much difference, but makes sense to use the Application Server.
I have not tried to deploy OSGI components but I know it is possible. Sorry I can't help more.
I am at the moment creating a matrix which is showing how far Knopflerfish, Equinox and Felix are OSGi 4.2 compliant.
So far I looked at the Knopflerfish documentation (Link 1, Link 2) to get an idea of how much of the Core and Compendium specs are actually implemented.
The core specification seems to be fully implemented, although there are some inconsistent statements about the Security Layer and the Declarative Services.
What makes me wonder is how much of all the Compendium specs are implemented:
Remote Services
Log Service
Http Service
Device Access
Configuration Admin Service
Metatype Service
Preferences Service
User Admin Service
Wire Admin Service
IO Connector Service
Initial Provisioning
UPnP Device Service
Declarative Services
Event Admin Service
Deployment Admin
Auto Configuration
Application Admin
DMT Admin Service
Monitor Admin Service
Foreign Application Access
Blueprint Container
Tracker
XML Parser Service
Position
Measurement and State
Execution Environment
To find out more I downloaded (Download page) the source code of Knopflerfish and had a look at it. It looks like some parts of the spec are implemented through the "original" framework provided by the OSGi Alliance (org.osgi.*).
One example is the UPnP package:
alt text http://img6.imageshack.us/img6/5853/screenshot20100403at212.png
Does this mean that missing parts which are not directly implemented by Knopflerfish are added through the "original" OSGi framework?
And does this also apply to other frameworks like Felix or Equinox?
Most of the OSGi specifications define interface classes for services. You can download these classes together with the specification directly from the OSGi Alliance's website.
Implementations such as Knopflerfish must provide the underlying functionalities, e.g. the actual implementation for the UPnP Service Admin you mentioned in your example. Some of the interface classes also provide interfaces that must be implemented by the developer of a user service, e.g. a BundleActivator.
All frameworks that claim to be OSGi compliant must provide implementations for these interfaces. There is no "original" OSGi framework (well, beside of the reference implementation, of course). The interfaces do not provide implementations.