Hi Dan! Thanks for this proposal.
Just some thoughts. i don't see compatible an option called "UI_VIEW" in a "domain" object. Perhaps just "VIEW"? If that's the case, what would differentiate it from a @ViewModel? That said, it would keep "JDO_ENTITY", "EXTERNAL_ENTITY" (I love that concept :). Regarding the "VIEW" option, if implementation is nearly the same as @ViewModel the only reason to keep it would be the consensus. So it ok for me. If that wouldn't be introduced, the only options available would "JDO_ENTITY" and "EXTERNAL_ENTITY" given as a clear indication that the annotation could be named @DomainEntity ... :)) What a pity!!! > El 3/1/2015, a las 12:59, Dan Haywood <[email protected]> > escribió: > > Folks, > > Thank you all so much for your contributions to this thread and also one I > created on [email protected] [1], discussing simplified a new set of > annotations, as suggested in ISIS-970 [2]. > > I've decided to continue the discussion on this thread as it's hosted most > of the conversation to date. If you reply then please include both users@ > and dev@ so both users and contributors are kept in the loop. > > ~~~~~ > It seems to me that there's no clear consensus as to what set of > annotations we should go with; any decision will be seen as not ideal by at > least some users. The most debate has been about whether to retain > @ViewModel, or whether or not to merge it into @DomainObject. > > Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a > preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all > preferred removing @ViewModel and merging it into @DomainObject (though > some of those opinions were made prior to the spirited debate that > followed, so I don't know if anyone in this second list has revised their > opinion). > > If @ViewModel is retained, then there was a subsidiary idea as to whether > to replace @DomainObject with @DomainEntity (so it would be @ViewModel and > @DomainEntity). One or two have been in favour of that idea, but it's not > had overwhelming endorsement. > > Ged offered the opinion that a view model is more like a domain event. No > one else replied to that idea. For myself, I don't think that's correct, > but it got me thinking. Rather, domain events are what we emit through the > (current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction > annotations. In ISIS-970 I proposed replacing @ActionInteraction with > @Action(interaction=...) etc. Ged's mention of domain events makes me > think it should instead be @Action(domainEvent=...). I've updated the > JIRA ticket accordingly. > > I also made a proposal about adding "Domain" as a prefix to @Property, > @Collection, @Action... but no-one seems particularly in favour of that. > > ~~~ > Before I go onto my own proposal for resolving this debate, let me just > remind everyone that in Isis it's possible to write metamodel validators. > We use these to check for no orphaned methods such as disableXxx(); I'm > sure many will have encountered this. But it's also possible to write and > register your own metamodel validators via isis.properties. > > Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows > the metamodel validation to be performed as part of the build, rather than > rely on running up the app or its integration tests. There's an example of > this in the simpleapp example [3] (and thus, will be part of the 1.8.0 > archetype). > > I mention this because it opens up the concept of "dialects" of the Isis > programming model, enforceable through the build pipeline. Out-of-the-box > Isis can provide support for all dialects, but individual projects can > constrain these by registering appropriate metamodel validators as they see > fit. > > ~~~ > So, my proposal is as follows: > > for the UI/app layer, retain/introduce: > * @ViewModel > * @ViewModelLayout > > for the domain layer: > * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW) > * @DomainObjectLayout > > for both: > * @Property(domainEvent=..., ) and @PropertyLayout > * @Collection(domainEvent=..., ) and @CollectionLayout > * @Action(domainEvent=..., ) and @ActionLayout > * @Parameter and @ParameterLayout > > Those that want to draw explicit attention to UI/app layer view models > should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW). > These folks might want to use a metamodel validator to ensure that > @DomainObject(nature=UI_VIEW) is not used anywhere in their codebase. > > Conversely, those that consider that its all just "domain objects" should > ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These > folks might want to use a metamodel validator to ensure that @ViewModel is > not used anywhere in their codebase. > > The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted > entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that > are managed by some external system. Internally Isis installs a > ViewModelFacet for these so that it knows how to manage their ongoing > identity (in essence corresponding to the external system's URI for that > entity), but that's an implementation detail. > > @ViewModelLayout and @DomainObjectLayout are basically identical. > > The above proposal does NOT include the introduction of @DomainEntity. > > ~~~ > Opinions? I'm kinda hoping this will get us to some sort of consensus ... > > Thanks > Dan > > [1] http://isis.markmail.org/thread/ng22jsmxeq55ewny > [2] https://issues.apache.org/jira/browse/ISIS-970 > [3] > https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136 > > >> On 3 January 2015 at 11:23, David Tildesley <[email protected]> wrote: >> >> Hi Oscar, >> Seems to me it's the same thing: >> Let me add some clarity to that DDD example you shared: >> Port ---> Domain Model <---Adapter >> is just a different set of terms for the same layers: >> User Interface --> Problem Domain <--- System Interface >> Chaining applications together in an integration you get Adapter "A" of >> AppA calling Port "B" of AppB and so on - which I am guessing is what you >> meant by "Inter Domain". >> Clearly ViewModel fits into "Port" quite nicely. In fact it's the only >> place it belongs. >> But "Intra Domain"? Does ISIS in some way prevent a domain object calling >> another domain object's operation directly? Anyway I suspect that's a >> separate discussion. >> The bottom line is that we can't stop people bleeding domain model >> behaviour out into viewmodels, however what we can do is to make it as >> clear and unambiguous as possible by avoiding/reducing overloading of >> terms/concepts and suggesting the correct approach to building an >> application. >> My single piece of advice to folk: If you want to avoid a disaster then >> make sure you model your problem domain in a "just enough" consensus >> modelling exercise before your team goes anywhere near "View Models" or any >> other part of the UI layer. ISIS offers nothing new that would change this >> advice. >> However "View Models" could be the scaffolding that you end up hanging >> yourself and your team on if you don't understand that they are not part of >> your domain model. >> I guess I should shut up now as I am just repeating myself. >> In summary: Big Tick for the addition of: "@DomainObject (External)" so >> that we don't have to misuse "@ViewModel" >> Regards,David. >> >> >> On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR < >> [email protected]> wrote: >> >> >> Hi David! >> >> What it's clear is that properties/collections can be useful not only for >> domain layer objects, so the @Domain prefix should not be added. >> >> Regarding the Application Layer, I agree that sometimes it can be a clear >> indication of an anemic domain. But properly implemented and used, it's >> well accepted on the DDD community as a way to create a layer over domain >> entities for orchestrating them. They're useful for representing Domain >> Entities the way is most useful for the end-user as perhaps the Domain >> Entities have been designed from another perpective different from that >> concrete use case. >> >> There are some examples on the latest book, "Implementing DDD" by Caughn >> Vernon. >> >> That use case is really similar to the most common use in Apache ISIS, >> with the advantage that the UI is automatically generated from it >> >> Anyway I don't advocate for using ViewModels only for the Application >> Layer, but in all case where "views" can be useful, including intra-domain >> or inter-domain use cases (for example, for modeling the integration >> patterns described on the "Implementing DDD" book such as Ports and >> Adapters. >> >> as an example sure you will find interesting this sole implementation made >> by Vernon, and how they could be implementing by Apache Isis[1]. >> >> So yes, as you said we must be careful with anemic domains :)) >> >> Regards, >> >> Oscar >> >> [1] >> https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration >> >> >> >> >> >> >> >>>> El 1/1/2015, a las 20:45, David Tildesley <[email protected]> >>> escribió: >>> >>> Hi Oscar, >>> >>> I think we may be looking at the "tail wagging the dog" in this part of >> the thread. I.e. the reason why Jeroen has found ViewModels for some of the >> scenarios he outlined (e.g. "External Entity service" integration) so >> useful was because there was no alternative available to him. This is where >> Option 1 tidies things up from a conceptual layer point of view, as >> discussed earlier in the post, but doesn't in any way prevent you from >> doing what you suggest below if that is what you believe is correct i.e. >> there would nothing forcing you to use "@ DomainObject (External)" - you >> could instead carry on using "@ViewModel" within your domain layer if that >> is what you think is correct. For those of us that believe this is >> conceptually wrong, Option 1 keeps us happy because now we have "@ >> DomainObject (External)" available to us and furthermore, it allows >> "@DomainObject (External)" to evolve independently of "@ViewModel" sometime >> in the future. >>> >>> i.e. Option 1 removes the layer overloading as Dan already points out. >>> >>> On a further note, I don't like to use the concept "Application Layer" - >> this layer was invented by those that ran into difficulty when forced to >> use EJB 1 & 2 and unfortunately persisted even when the POJO movement >> started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). >> I.e the presence of an "Application Layer" concept is a very strong >> indicator of the presence of "Anemic Domain Model" anti-pattern [1] and >> this is pointed out by Martin Fowler. Assuming a rich domain model then, >> what may be thought of as the "Application Layer" is really just part of >> the UI layer. >>> >>> [1] bliki: AnemicDomainModel >>> >>> >>> >>> >>> >>> >>> >>> >>> bliki: AnemicDomainModel >>> If you use an object-oriented domain model, and you don't put behavior >> in your objects, you're missing out on most of the benefits of that pattern. >>> View on www.martinfowler.com >>> Preview by Yahoo >>> >>> >>> >>> Regards, >>> David. >>> >>>> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou < >>> [email protected]> wrote: >>> >>> >>> Hi folks!! >>> >>> Happy New Year to all those following the Gregorian Calendar !!! >>> >>> >>> As David mentions, we can think about ViewModels to be like "views". >>> >>> In that case, as Jeroen has commented, those "views" can be useful both >> at the Domain layer and the Application layer. >>> So we cannot assume that View Models are going to be useful only for the >> Application layer, but also for the Domain layer. >>> And not only they are "views" from this system's domain objects. As he >> points out, Views can also be used to represent external systems entities. >>> >>> As Isis managed Properties/Collections can belong to any class of this >> Bounded Context / Domain or External Systems Domains objects (being a >> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the >> ApplicationLayer, a ViewModel representing entities managed by External >> Systems) they shouldn't be prefixed with a layer-specific term, IMHO. >>> >>> >>> Oscar >>> >>> >>> >>> >>> >>>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] < >> [email protected]> escribió: >>>> >>>> At least it wasn’t DOA =] >>>> >>>> That helps me understand the evolution of Isis better, and It makes >> sense the PD would never depend on the UI. >>>> >>>> So having separate annotations [@ViewModel and @DomainEntity] would >> help maintain the distinction between UI and PD. >>>> Where a single annotation [@DomainObject, @Model, or whatever else] >> would blur the lines of responsibility. >>>> Do I understand this correctly? >>>> >>>> Jeremy D. Branham >>>> Tel: **DOTNET >>>> >>>> >>>> -----Original Message----- >>>> From: David Tildesley [mailto:[email protected]] >>>> Sent: Wednesday, December 31, 2014 4:36 PM >>>> To: [email protected]; [email protected] >>>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a >> chance... >>>> >>>> Sorry - too many new years eve beers - I typed DOI when I meant DI >> (fuddled with IoC in my brain). >>>> >>>> On Thursday, 1 January 2015 11:04 AM, David Tildesley < >> [email protected]> wrote: >>>> >>>> >>>> Hi Jeremy, >>>> The intention of "ViewModel" is provide a Use Case specific mechanism >> to aggregate/present/"cut and dice" a view of the problem domain. In this >> respect it is certainly not part of the domain layer and logically belongs >> the "UI" layer. It was invented as part of ISIS as the mechanism for >> significantly influencing the UI. In this way, it is a departure from the >> original concept of Naked Objects from which ISIS evolved, however if you >> choose not to use ViewModel then you are left with the original concept of >> Naked Objects and therefore ISIS remains true to Naked Objects. >>>> The domain layer has long term enduring value to the business who paid >> for the application to be built and should never depend on other layers. >> The "UI" layer should be thought of as "disposable" and will mutate at a >> high rate, whilst the "domain layer" should remain stable in "shape" and >> independent of the other layers. There is nothing inherent about ISIS that >> would give you a valid reason to ignore this architecture pattern. If we >> ignore the data management layer which is no longer of significance due to >> persistence frameworks like DataNucleus, JPA, Hibernate, Toplink, etc., >> then there are only the traditional three layers in consideration for the >> developer (if they choose not to stick to the pure Naked Objects paradigm >> for user experience) and the below represents these with the direction of >> dependency shown by the arrows: >>>> UI --> PD <-- SI >>>> Where: >>>> UI = User Interface (system or human)*PD = Problem DomainSI = System >> Integration. >>>> * UI layer Includes both the ViewModels and the generated UI(s). Where >> things got messy for ISIS was when Domain Objects in the domain layer were >> required not to be locally persisted but instead required DOI based >> integration with an external system (integration). The ISIS Domain Objects >> were "locked" into local persistance and that was because that was where >> the initial focus was (necessary because you have to get this right as >> priority because this is the majority scenario). Then in this vacuum, folk >> started proposing to use "ViewModel" as Domain Objects that required DOI >> based external system integration because "ViewModel" was free from the >> local persistance lock-in. Other proposals were also on the table (e.g roll >> your own datanucleus persistance plugin) that came with their own headaches. >>>> Option 1 then tidies this up and nothing is lost. >>>> Speaking to Jereon's point - yes there are some "trivial" system >> integrations where it is valid to bypass the PD layer and have a direct >> integration from UI layer to SI layer (e.g fetch a controlled value list >> from some other system) although I would say that ISIS negates the need to >> do this anyway by lowering development cost. >>>> A step in the right direction is to first sort out the semantics with >> Option 1 and then later when folk feel comfortable, to have ISIS enforce >> the UI --> PD dependency direction (i.e. disallow PD --> UI). >>>> Applications should reinforce the layer separation via package naming >> convention. e.g. >>>> com.mycompany.myapp.pd.*com.mycompany.myapp.ui.* >>>> David. >>>> >>>> On Thursday, 1 January 2015 3:24 AM, "Branham, Jeremy [HR]" < >> [email protected]> wrote: >>>> >>>> >>>> What would it look like with @Model? >>>> Giving more specificity than ‘Object’ but opening the interpretation to >> Entities and ViewModels. >>>> >>>> Or am I overlooking something? [I am new to Isis] >>>> >>>> (fyi - there is a name clash with Model in Spring-MVC) >>>> >>>> >>>> Jeremy D. Branham >>>> Tel: **DOTNET >>>> >>>> From: Jeroen van der Wal [mailto:[email protected]] >>>> Sent: Wednesday, December 31, 2014 7:37 AM >>>> To: dev; users >>>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a >> chance... >>>> >>>> I like this discussion because it's defining where Apache Isis is right >> now. Personally I think Isis has grown far beyond the concepts of DDD so >> sticking to it's grammar would limit ourselves. >>>> >>>> In the applications I'm developing things aren't black or white: we >> have view models that represent documents in a CMIS document store but in >> DDD terms they are domain entities. We have view models that are based on >> entries in a database view but in DDD terms these are domain entities. We >> have view models that are created on the fly and never get persisted but in >> DDD terms they are domain entities. >>>> >>>> As you might expect I opt to simply call everything a domain object. >> Residing in the application's domain object model. Very easy to explain to >> newcomers too. >>>> >>>> Cheers, >>>> >>>> Jeroen >>>> >>>> >>>> On Wed, Dec 31, 2014 at 1:13 PM, GESCONSULTOR - Óscar Bou < >> [email protected]<mailto:[email protected]>> wrote: >>>> Hi to all. >>>> >>>> >>>> I'm thinking about it but still convinced of option 1 ... >>>> >>>> In my opinion, annotations are going to be "our main API". So they must >> be thought from the user's perspective, more than from the implementation's >> perspective. >>>> >>>> In that way, aligning with DDD concepts (that are the most widely >> spread) is more important to me than implementation criteria. >>>> >>>> So I would keep my vote for implementing: >>>> >>>> @DomainEntity >>>> @ViewModel >>>> @DomainEntityLayout >>>> @ViewModelLayout >>>> >>>> >>>> >>>> Regarding adding the "Domain" preffix to properties and collections, I >> think it's not needed. >>>> >>>> As Dan's exposed, they are present on any type of class (despite being >> a "domain" or "application" level one). >>>> As they're annotations an not classes, in my current setup (based on >> Apache Isis latest snapshot): >>>> - @Property does not conflict with any other annotation (i.e., no >> identically named annotation is present on any dependency). >>>> - @Collection does not conflict with any other annotation. >>>> - @Action clashes with the javax.xml.ws.Action annotation. >>>> - @Parameter clashes with the org.junit.runners.parammetrized.Parameter >> annotation. >>>> >>>> None of them can be confused with Isis ones by a junior developer. >>>> >>>> In fact, this clash conflict was already present with @Named (that it's >> going to be kept) and same other Apache Isis annotations without being more >> relevant. >>>> >>>> So my opinion would be to not add the "Domain" prefix to them. >>>> >>>> >>>> Perhaps this could also be a good moment to add a "collateral" debate :) >>>> >>>> In my head, I also associate Collections with Properties. I would >> consider "Simple Properties" and "Collection Properties". >>>> So perhaps naming could be instead "SimpleProperty" and >> "CollectionProperty" ? :-)) >>>> >>>> >>>> >>>> HTH, >>>> >>>> Oscar >>>> >>>> >>>> >>>> >>>> >>>> >>>> El 31/12/2014, a las 12:39, Vladimir Nišević <[email protected] >> <mailto:[email protected]>> escribió: >>>> >>>> >>>> I would vote for most well described DDD terms (described in Evans >> book) - this would help users to adopt/understand ISIS framework easier and >> have a kind of reference documentation. Term 'Object' is too general, and >> "Business Object modelling antipatterns" are also very wide spreaded, e.g. >> by people like enterpise information modelling architects... >>>> >>>> Regs, Vladimir >>>> >>>> >>>> >>>> Am 31.12.2014 um 07:40 schrieb Dan Haywood < >> [email protected]<mailto:[email protected]>>: >>>> >>>> >>>> On 30 December 2014 at 23:44, David Tildesley <[email protected] >> <mailto:[email protected]>> wrote: >>>> >>>> +1 for the counter proposal (although I would suggest cloning/deriving >>>> "@DomainObjectLayout" to "@ViewModelLayout" etc. so that "Domain*" tags >> are not used in ViewModel - less confusing). >>>> >>>> On a different thread to dev@ I also made a related proposal that >> @Property, @Collection, @Action etc be renamed to @DomainProperty, >> @DomainCollection, @DomainAction etc... the primary reason being that >> clashes with @Collection clashes with java.util.Collection, plus I like the >> idea of all Isis-related annotations starting with an @DomainXxx prefix. >>>> >>>> No one's commented on that, yet. >>>> >>>> Given your preference of @ViewModel and reserving "@Domain" to be >> strictly for domain layer concepts, would I be right to guess you wouldn't >> be in favour of adding "Domain" as a prefix to all those annotations? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tuesday, 30 December 2014 3:07 AM, Dan Haywood < >> [email protected]<mailto:[email protected]>> wrote: >>>> >>>> >>>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < >> [email protected]<mailto:[email protected]>> wrote: >>>> >>>> >>>> Ok. >>>> >>>> So let's raise some questions/doubts :) >>>> >>>> *** @DomainObject *** >>>> >>>> Is a ViewModel a DomainObject at all ? >>>> it's a good question, and I've debated it myself. Let me lay out my >> thinking on this so far and see if we can collectively come to a view on >> this. >>>> >>>> First thing to note is that there are two "varieties" of view models >> (even though the implementation is identical) >>>> >>>> - those that are part of the domain layer and are, conceptually at >> least, entities, but where the persistence is managed outside of Isis. An >> example is a document in a CMS >>>> - those that are part of the application layer, and represent a view on >> top of one or more entities. >>>> >>>> Of course, we expect an application layer to depend on the domain layer >> and not vice versa, but even so, because some view models are conceptually >> entities I suspect that in a typical Isis application it will be reasonable >> to allow JDO-managed domain entities to interact with externally-managed >> view model entities. >>>> >>>> >>>> Because of this, I've been thinking of "DomainObject" as being a >> superset of both entities and view models. >>>> >>>> >>>> >>>> >>>> >>>> I would consider them as a different kind, so the @ViewModel annotation >> shouldn't be deleted. >>>> >>>> You are certainly right that quite a few of the features in >> @DomainObject don't apply to view models (even if conceptually they are >> entities)... >>>> because we rely on JDO to implement. Specifically: >>>> >>>> - auditing... requires JDO so doesn't apply to view models >>>> - publishing ... requires JDO so doesn't apply to view models >>>> - bounded = not sure... even though doesn't depend on JDO, suspect that >> it isn't supported for view models >>>> >>>> - autoComplete ... is supported for view models >>>> - editing ... is supported so long as the ViewModel.Cloneable interface >> is also implemented. I can foresee this restriction being lifted in the >> future >>>> - objectType ... is supported for view models (used as REST URLs) >>>> >>>> >>>> >>>> >>>> >>>> >>>> Also, perhaps we can introduce Isis platform logic like not >> "saving/persisting" view models, etc. If that would be the case, the >> "editing" and "editingDisabledReason" at least might not have any sense. >>>> Not sure I understand this point. But at any rate, given that some >> view models are basically externally-managed entities, the semantics of >> "saving/persisting" would also apply. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> If so, I would better align with DDD naming conventions, in order to >> gain acceptance. >>>> >>>> So, names should be @Entity or @DomainEntity (for avoiding name >> collision with JPA) - instead of @DomainObject -. >>>> I did consider @DomainEntity, but as I say, sometimes view models act >> like entities. I do quite like it though. >>>> >>>> I have a counter-proposal, see below. >>>> >>>> >>>> >>>> >>>> I like the @DomainService name, as it can act as a DDD Factory and/or >> Repository. >>>> >>>> >>>> As currently there's no "special" support for AggregateRoots or >> ValueObjects, no more annotations are needed. >>>> Sounds like a vote to deprecate. Jeroen has said the same thing. >> Perhaps they should be deleted in v2.0 and reappear, if we want them back, >> in v3.0. >>>> >>>> >>>> >>>> >>>> So the proposed set would be: >>>> • @ViewModel and @ViewModelLayout >>>> • @DomainService and @DomainServiceLayout • @DomainEntity and >> @DomainEntityLayout • @Property and @PropertyLayout • @Collection and >> @CollectionLayout • @Action and @ActionLayout • @Parameter and >> @ParameterLayout Here's my counter-proposal. It's not as symmetrical as >> before, but perhaps is less confusing overall: >>>> >>>> * replace @DomainObject(viewModel=false) with >>>> @DomainEntity(persistence=JDO) >>>> ... this would be the default >>>> * replace @DomainObject(viewModel=true) with >>>> @DomainEntity(persistence=EXTERNAL) >>>> ... for view models representing externally-persisted entities. In the >> Javadoc, say that auditing, publishing and bounded are not supported for >> these >>>> * keep @ViewModel >>>> ... extend to include the non-entity stuff from @DomainObject that does >> apply (basically, I think that's just "objectType" ) ... the intention >> being that this is used for application-layer views. >>>> >>>> keep @DomainObjectLayout, because everything in it applies equally to >> both view models (either variety) and JDO entities. >>>> >>>> >>>> I'll reply on your points on @Property and @Parameter separately. >>>> >>>> Thx >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>> >>>> Óscar Bou Bou >>>> Responsable de Producto >>>> Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO >> 20000, ITIL-F >>>> >>>> [cid:4C38BF6A-D280-4C7F-BFC2-4285B2033897] 902 900 231 / 620 267 520 >> [cid:6DF89309-F557-4C28-BDFC-AE5B9D964612] >> http://www.twitter.com/oscarbou >>>> >>>> [cid:DDC0BB1F-E0FC-4120-97F8-E2D5F0DA9BC5] >> http://es.linkedin.com/in/oscarbou >>>> >>>> [cid:F31E93E9-D0D0-4F96-9A7C-496F094117DC] http://www.GesConsultor.com >> <http://www.gesconsultor.com/> >>>> >>>> [cid:04E888F1-A5E9-49D1-832D-465FE2C6C940] >>>> >>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos >> contienen información reservada que no puede ser difundida. Si usted ha >> recibido este correo por error, tenga la amabilidad de eliminarlo de su >> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >>>> Su dirección de correo electrónico junto a sus datos personales constan >> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >> de mantener el contacto con Ud. Si quiere saber de qué información >> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >> sus archivos adjuntos no contengan virus informáticos, y en caso que los >> tuvieran eliminarlos. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> This e-mail may contain Sprint proprietary information intended for the >> sole use of the recipient(s). Any use by others is prohibited. If you are >> not the intended recipient, please contact the sender and delete all copies >> of the message. >>>> >>>> >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> This e-mail may contain Sprint proprietary information intended for the >> sole use of the recipient(s). Any use by others is prohibited. If you are >> not the intended recipient, please contact the sender and delete all copies >> of the message. >>> >>> >>> Óscar Bou Bou >>> Responsable de Producto >>> Auditor Jefe de Certificación ISO 27001 en BSI >>> CISA, CRISC, APMG ISO 20000, ITIL-F >>> >>> 902 900 231 / 620 267 520 >>> http://www.twitter.com/oscarbou >>> >>> http://es.linkedin.com/in/oscarbou >>> >>> http://www.GesConsultor.com >>> >>> >>> >>> >>> Este mensaje y los ficheros anexos son confidenciales. Los mismos >> contienen información reservada que no puede ser difundida. Si usted ha >> recibido este correo por error, tenga la amabilidad de eliminarlo de su >> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >>> Su dirección de correo electrónico junto a sus datos personales constan >> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >> de mantener el contacto con Ud. Si quiere saber de qué información >> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >> sus archivos adjuntos no contengan virus informáticos, y en caso que los >> tuvieran eliminarlos. >> >> >>
