cancel
Showing results for 
Search instead for 
Did you mean: 

ESR & the registry seperate

Former Member
0 Kudos

Clearly, the ESR, modelled on CCTS seems like a clear way to help organizations with 3rd patry repository vendors. But - any organization will never have just SAP NetWeaver as the SOA platform. Does it mean that the need of multiple repositories will still exist? Without the "outside In" development done in XI, can enterprise services, based on the metamodel definitions using the ESR GDTs & structure, published into the registry, be possible?

Or is it - that if there are 2 platforms for SOA development existing in an organization, will it warrant the use of 2 repositories - one ESR & the other a best of breed?

Any inputs will be of help.....thank you.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

nice question Kartik

I think there is no doubt that in principle there can only be one ESR and one set of GDTs (would they be global otherwise??).

Unfortunately AFAIK there is no independent vendor who offers a standalone ESR, fully featured and with no other intent to generically support service management.

Following the SOA paradigm, there shouldn't be a need to confine development to a certain number of 'SOA development platforms' but every development platform featuring the development of SOA services should equally fit. How easily those services developped elsewhere are to be sustainably integrated into one central repository remains to be seen.

anton

Former Member
0 Kudos

Anton~

Many thanks for the reply! I guess I see it this way - let there be ONE respository, say ESR. For the outside In & Inside out development with SAP, it makes sense. For the other platform environment, as long as I can use the GDTs out of ESR (which is there on the ABAP stack today), it remains to be seen.

If I develop my es on an IBM platform, using the GDTs defined in the ESR (once I guess I use PI & when its available - use the NWDS to create proxies and subsequent code in it after creating the services) and implement the same into the repository. Seems like a long shot though.

All the same - A single repository approach seems to be the right idea for both platforms in this contect. So, a design time governance is fulfilled. But any thoughts on the runtime governance?

Thank you and best regards

Kartik Iyengar~

AndreasHuppert
Product and Topic Expert
Product and Topic Expert
0 Kudos

The ESR entities can be deployed into ABAP or Java environments, so they are the same in design time and runtime. Thus, I don't see a difference between design time and runtime governance.

Former Member
0 Kudos

Andreas~

Thank you for the reply. probably, most of my questions will be answered when there is documentatiion available on ESR (Details, release strategy etc.). The closest I can get to answers today are the standard on the metadata registries standards - ISO/IEC 11179-4 only. or what one saw @ the techeds.

From a governance perspective, thank you for the reply. Yes, it helps!!

Thank you and best regards

Kartik Iyengar~

Former Member
0 Kudos

Kartik,

my thoughts concerning runtime governance:

Talking of service runtime:

As mentionend earlier, well designed services should be able to be run on any runtime featuring SOA standards(not only NW ABAP or NW Java). On the other hand there should ideally be only one service repository, which obviously "runs on one platform". So, there is potentially a difference between design time governance and runtime governance.

Talking of process runtime governance:

processes run on a process execution platform which is not logically required to be the same as the repository runtime. IMHO, it should even be possible (though it my not necessarily be advisable) to run different processes on different process runtimes if the central designtime repository is "world"(better enterprise) readable.

I can even imagine scenarios where a more complex process executed on one runtime embeds sub-processes executed on other process runtimes.

just my thoughts on it,

anton

Former Member
0 Kudos

You make an extremely good point. The catch is the "Well designed services" aspect. As long as there is the methodology of creating services, inside out or outside in, into a common repository, the chances of the soa journey makes sense.

Thank you for your replies!!

Kartik~