Hi Ray, I guess you are right!
I used Blueprint in our last software projects because I prefer constructor injection and I was attracted by the convenience of its dynamic proxies. This overshadowed the beauty of DS J. But obviously DS enables more control over service dynamic. Thanks for your advice. Best regards, Andreas -----Ursprüngliche Nachricht----- Von: Raymond Auge <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com> > Gesendet: Mi 25.03.2015 15:44 Betreff: Re: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz) Anlage: inline.txt An: OSGi Developer Mail List <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >; Would you really need a subsystem though? For instance, if you have a service graph based on DS where the outermost component is reachable to the user, and the lowest level is something that could go away, with properly defined relationships (i.e. the most basic being all static references) the outer most would technically go away before the lowest level actually does. This is the beautiful nature of DS. It's not like you're tearing away layers from the inside... it's kind of like peeling an onion! Am I mistaken? - Ray On Wed, Mar 25, 2015 at 9:58 AM, Andreas Klotz <andreas.kl...@n-design.de <mailto:andreas.kl...@n-design.de> > wrote: Hi Hervé, thank you for your comprehensive response. My conclusion concerning service dynamic is to deal with it in two different ways: 1. Case: The service represents a feature of an application and is on the top level of my layered architecture. If I stop the service, I want my GUI to disable the feature so that Users are aware that the service is not available. I want my application to handle service dynamic as “switch on / switch of” off features. 2. Case: The service represents a lower architectural layer (e.g. persistence layer as part of a feature). If this service is stopped without stopping the layers above an unsuccessful call is treated as a runtime failure (e.g. database not reachable). So as Chris an Peter said, in any of these cases I expect that a service call can fail and the software has to deal with it. Additionally I want my application to react actively on disabling certain features. To achieve this I try to group all bundles belonging to a feature in a subsystem. Best Regards, Andreas Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> [mailto:osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> ] Im Auftrag von "hervé vivien" Gesendet: Dienstag, 24. März 2015 16:00 An: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> Betreff: [osgi-dev] persistence, lazy loading and service dynamic (Andreas Klotz) Sent: Sunday, March 15, 2015 at 5:00 PM From: osgi-dev-requ...@mail.osgi.org <mailto:osgi-dev-requ...@mail.osgi.org> To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> Subject: osgi-dev Digest, Vol 101, Issue 24 Send osgi-dev mailing list submissions to osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body 'help' to osgi-dev-requ...@mail.osgi.org <mailto:osgi-dev-requ...@mail.osgi.org> You can reach the person managing the list at osgi-dev-ow...@mail.osgi.org <mailto:osgi-dev-ow...@mail.osgi.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of osgi-dev digest..." Today's Topics: 1. persistence, lazy loading and service dynamic (Andreas Klotz) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Mar 2015 17:41:33 +0100 From: Andreas Klotz <andreas.kl...@n-design.de <mailto:andreas.kl...@n-design.de> > To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > Subject: [osgi-dev] persistence, lazy loading and service dynamic Message-ID: <zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info <mailto:zarafa.550464bd.528b.4aa9fb7f20b70...@s15865907.onlinehome-server.info> > Content-Type: text/plain; charset="utf-8" Hi all, ? I have an use case where I want the dynamic of a service to be bound to another higher level service. Maybe I need Subsystems...? ? I think it is a good design of an OSGi-service if it just provides data in contrast to provide objects on which an operation can be performed that is using resources of the underlying bundle. Although the second variant would be possible, I think that handling service/bundle dynamic becomes very complex or even unmanageable. ? However there is a use case where I can't deliver just data by a service. I think of lazy loading when dealing with persistence. I usually define interfaces for the data access layer. So I get a Bundle-Setting like this: ? - Entity-Bundle (contains Entities) - DataAccessAPI-Bundle (contains DAO-Interfaces) - DataAccessImpl-Bundle (provides Services implementing DAO-Interfaces) - DomainService_A-Bundle (contains domain Logic for e.g. a GUI, uses DAO-Services; would be separated in API and impl of course) - DomainService_B-Bundle (contains more domain Logic, uses same DAO-Services as DomainsService_A) ? DomainServices A and B are clients of DAO-Services. A DAO-Service may provide an entity with some lazy loading properties. The transactions of the data accesses are defined by the DomainServices. So it may occur, that a call by the DomainsService on a property of an entity happens when the DAO-Service is not available anymore. That would lead to an unsuccessful attempt to load the property lazily (assuming that connections to the database are managed by the DAO-Bundle and not by a separate e.g. EntityManager-Service). So the DAO-Service delivered an object that tries to perform an operation on its delivering service. ? What options do I have to safely load the entities? - Do not use lazy Loading? I know cases where this would load the whole DB in to the RAM... - Make assumptions about certain properties a client might need and load them explicitly in the DAO-Layer? This will not work if I have different clients for one DAO-Service. - Is there a possibility to package DomainServices A and B as different Subsystems with the DAO-Service as a shared capability? Would this have the effect that the bundle providing the DAO-Service will only be stoppable, if both DomainServices are stopped? ? To be more general: In our OSGi-projects we use micro-services intensely to loosely couple not only domain logic (vertical) but also the architectural layers (horizontal). And I often feel that I only want dynamic for the vertical bundles/services. ? I am very interested in your opinion and how you deal with lazy loading or equivalent cases. ? Thanks and best regards, ??????????????? Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.osgi.org/pipermail/osgi-dev/attachments/20150314/a7b2eca1/attachment-0001.html <http://mail.osgi.org/pipermail/osgi-dev/attachments/20150314/a7b2eca1/attachment-0001.html> > ------------------------------ _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev End of osgi-dev Digest, Vol 101, Issue 24 ***************************************** Hi dear Andreas, sorry for responding to you so late on this topic "persistence, lazy loading and service dynamic". hint: please do enumerate your problems or your questions, so as to simplify,clarify them to us readers. Let's Try to summarize your requests if possible, to relevantly meet your needs. 1- I want the dynamic of a service to be bound to another higher level service 2- provides data in contrast to provide objects on which an operation can be performed 3- I can't deliver just data by a service. I think of lazy loading when dealing with persistence. 3.1-So the DAO-Service delivered an object that tries to perform an operation on its delivering service 4- What options do I have to safely load the entities? 5- This will not work if I have different clients for one DAO-Service. 6-Is there a possibility to package DomainServices A and B as different Subsystems with the DAO-Service as a shared capability? 6.1- Would this have the effect that the bundle providing the DAO-Service will only be stoppable, if both DomainServices are stopped? 7- And I often feel that I only want dynamic for the vertical bundles/services. 8- I am very interested in your opinion and how you deal with lazy loading or equivalent cases. MY OPINIONS: PART I : intro and fundamentals INTRO Implementing a system based on OSGI is a good choice.however one has to have in mind that OSGI is a specification, that is, being implemented differently by Container Providers (org.apache.felix,org.eclipse.equinox,etc.). e.g registering a service: hardcoded vs xml(blueprint,DS...). As you are organizing your system environment, make sure to be aware of some basic OSGI behavioural and structural fundamentals, as follow : OSGI fundamentals: - bundle, context, services platform - object (class) =/= bundle service =>(component->environment) - bundle -> modularisation, dependency - bundle service -> the externalization of some operations (services -> utility,domain or business) - lifecycle : bundle Activator (start/stop) =/= bundle service Activation and Registering (activate/deactivate, bind/unbind).NO INSTALLED = NO STARTED(ABLE) = NO USABLE - start-level: SL =/= lifecycle. WHEN START ? -> the start-up priority. e.g. who runs first to the bathroom (dad, mom, yoki,yaki...?) PART II : responses for enumerated questions 1- services are made to be bound to one another. But dynamically binding a service to another, you need org.osgi.util.ServiceTracker or SRC service runtime component (DS declararative service or blueprint). 2- an osgi service can be designed to provide any resources (data, simple entities, streams,files) to external worlds (other bundles). but first of all, your bundle has to declare the service(s) responsible for exchanging/communicating with other bundles, as of operations matter. e.g DAOservice 3- yes you can deliver just data by a service ----- class DAOImpl class DAOImpl impl DAOservice { @override List<Person> getData(){ //or List getData(){ to return any data //case sql statement while(resultSet.next){ personList.add(0,resultSet.getString("id")); personList.add(0,resultSet.getString("name")); personList.add(0,resultSet.getString("age")); personList.add(0,resultSet.getBoolean("sexy")); } //case entity persistence person = entityManager.find(object); or personList = entityManager.createQuery("sql").getResultList(); //here are data returned return personList; } } ----- class DomainService_B DAOservice daoService; dosomeThing(){ ////daoService or getDAOservice() //now get all data fetched apersonList= daoService.getData(); } //in case of DS implementation DAOservice getDAOservice(){ } 3.1 A service registered (published) by a bundle X , and referenced in another bundle Y can perform operations on its own objects or on any. please use a classic "interface" instead, to have an object perform an operation on it. e.g objectInBundleX.waitmeUP(ITimer), however in another bundle that referenced a service "TimerService", it may call objectInBundleY.waitmeUP(TimerService) {timerService.waikup()} 4- To safely load the entities: in a system, the architecture (information,application,technology,resource) and the workflow are critical.see 3, 3.1 and next. 5- you can have different clients served by a single service.The question is about the activities' domain and the State of that single service at a time in a domain activity. how many business (activities) domains you are dealing with. is that domain specific, private ? don't share its DAO. is that domain common ? don't run the risk of overlapping data in a domain. keep in mind the UNICITY of the information in a system. otherwise, build a stateless service, a utility service that get a new instance of an object needed... e.g. dao = new dao(); dao.loadDataByCustomer(customerID) 6- the subsystem DAO-Service bundled as a shared capability is a best practice design,But be careful to get new instance of that service or of some objects if necessary. separating the Logic from the UI is recommended, in each bundle is fully recommended and best practice. 6.1- it's not automatic to have that effect, see osgi spec. a bundle can stop/start anytime, as does (activate/deactivate) a service. a bundle lifecycle has precedence on service lifecycle. However if a service is running, stopping a bundle will issue errors in a system (dependence matters). and you set up osgi service's properties to automate how a service "component" will operate. 7- see PART I for OSGI fundamentals: OSGI bundle stands for Modularization.that's the master word. How the-way-NASA you want to design your system. Nowadays, modularizing a system infrastructure is for flexibility and agility.a system not modularized is like a concrete block, you must rebuild it once crashed impossible to see inside it, awful. e.g. the earth: you can not repair the sky alone, the sea alone.it <http://alone.it> 's a whole and not modularized, but deeply wise... vertical or horizontal, no matter. the question is what should be modularized, for what. response: maintenance, flexibility,agility, re-usability,responsibility, encapsulation,dynamics... e.g. to change a ui theme, to provide a new business's entity model, provide AOP support to a system, maintain the White House carpet,change a doctor,etc. 8- lazy loading data =/= lazy activating a service you mean lazy loading data. lazy vs eager first annotate your entity class's property : @Basic(fetch=FetchType.LAZY), if optional @Basic(fetch=FetchType.LAZY,optional=true) @Entity @Table(name="person") --- class Person @Basic(fetch=FetchType.LAZY) @Column(nullable=false, length=ten) private String name; I hope i help, best regards, _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev -- Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect Liferay, Inc. <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
