Another way to look at the picture and remind about the triangle direction would be to see it as a megaphone. The provider shouts out to the “world” that there is a new service available. ☺
Mit freundlichen Grüßen / Best regards Dirk Fauth Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com<http://www.bosch.com> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Peter Kriens via osgi-dev Gesendet: Donnerstag, 28. Juni 2018 17:45 An: Dirk Fauth <dirk.fa...@gmail.com> Cc: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Betreff: Re: [osgi-dev] OSGi Specification Question I think this is the same confusion that exists for the UML interface symbol. Lots of problems that have a client-publisher relation have a hard time with a good symbol since the relation is symmetric but not really. Imho once you take a bit of time to see that the arrow points in the dependency direction you tend to never forget it. I’d love to change it for another symbol but never found a better one. UML interfaces are not services (and probably even more confusing) and I’ve never so far seen a symbol for micro-services, where I guess they have the same need for a symbol. Most symbols tend to draw something on the publisher. [cid:image001.png@01D40FA8.31866280] However, in OSGi that does not make sense since we have independent publisher. In OSGi, the service is its own entity. Nobody else but OSGi seem to make that distinction. We reified the service and the service object(s) because they are independent of the provider and the consumer. Our dependency versioning is based on the version of the API, NOT the provider nor the consymer. (At the time I tried to get the Semver people to understand that they should add support for the compatibility rule differences between providers and consumers and failed.) The service broker model in OSGi is very innovative but unfortunately badly understood since it is so outlandish. Ah well, story of my life. Kind regards, Peter Kriens On 28 Jun 2018, at 16:56, Dirk Fauth <dirk.fa...@gmail.com<mailto:dirk.fa...@gmail.com>> wrote: Thanks a lot for the answers. Then I updated my slides last year correctly after the feedback from Tim. I just didn't remember. :) The confusion seems to be quite big. I need to update my getting started with DS tutorial. And the incorrect picture is also posted on the Concierge website https://www.eclipse.org/concierge/ Peter Kriens via osgi-dev <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> schrieb am Do., 28. Juni 2018, 16:23: Not sure it is a good idea to repeat this picture for future confusion on a mailing list? Peter Kriens On 28 Jun 2018, at 16:10, Tim Ward via osgi-dev <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> wrote: I think it is this picture that causes the confusion: <enRoute1.png> In this picture the “register” action is between A and S. This appears to suggest that the service S is registered by bundle A. If that is the case then the pointy-end of the triangle needs to point at A. Similarly the “get” and “listen” actions are coming from bundle B, which would appear to make it the consumer of S. The consumer should have the fat end of the triangle. Note that almost all OSGi diagrams put the consumer on the left and the provider on the right. Best Regards, Tim On 28 Jun 2018, at 15:04, Neil Bartlett via osgi-dev <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> wrote: The spec is correct, and either Tim misspoke or you misheard him. The service should look like a big arrow pointing from the consumer to the provider. Neil On Thu, Jun 28, 2018 at 2:57 PM, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> wrote: Hi, maybe a stupid question, but I am preparing my slides for the Java Forum Stuttgart about Remote Services, and remembered that Tim told me that my diagrams are incorrect, as the triangle is directing into the wrong direction. The big end should be on the producer side, while the cone end points to the consumer bundle. https://enrouteclassic.github.io/doc/215-sos.html https://jaxenter.de/osgi-enroute-1-0-hintergruende-architektur-best-practices-39709 The architecture picture in the Remote Services chapter show the triangles differently. https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html Where is my misunderstanding? Is the picture incorrect, or does the picture show something different? Mit freundlichen Grüßen / Best regards Dirk Fauth Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com<http://www.bosch.com/> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
