Sent: Sunday, March 15, 2015 at 5:00 PM
From: osgi-dev-requ...@mail.osgi.org
To: osgi-dev@mail.osgi.org
Subject: osgi-dev Digest, Vol 101, Issue 24
From: osgi-dev-requ...@mail.osgi.org
To: 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
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
You can reach the person managing the list at
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>
To: osgi-dev@mail.osgi.org <osgi-dev@mail.osgi.org>
Subject: [osgi-dev] persistence, lazy loading and service dynamic
Message-ID:
<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>
------------------------------
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
End of osgi-dev Digest, Vol 101, Issue 24
*****************************************
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
You can reach the person managing the list at
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>
To: osgi-dev@mail.osgi.org <osgi-dev@mail.osgi.org>
Subject: [osgi-dev] persistence, lazy loading and service dynamic
Message-ID:
<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>
------------------------------
_______________________________________________
OSGi Developer Mail List
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...?)
- 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"));
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();
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'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
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'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
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 https://mail.osgi.org/mailman/listinfo/osgi-dev
