Reuse of open ESPI code- Please provide response to my questions

[Indranil Banerjee]

We are looking at a requirement where an organization  would like to host their services on Google Cloud Platform and would preferably like to reuse their existing technology stack.

I  am looking to implement a green button pilot where my client  is looking at extending its existing customer portal to handle 3rd Party Registration and Authorization and Access Management and use a separate ESPI service hosted on Google cloud to handle Subscription and Data Exchange.

The plan is to use the Ontario ESPI Model as the starting point for building the ESPI service however I would like to reuse the existing solution stack which consists of OATH2, JBoss RestEasy, IBatis and Google Guice. As I am working with a different solution stack what would be the reusable factor to use the OpenESPI code. From  past experience does this group have any recommendations on following this approach.

I  understand that the key is to create a handshaking between the customer Portal which handles authorization and the ESPI Service. Both the applications will be hosted on Google Cloud but will be separate instance. Can somebody help us on how to do the necessary handshaking between these 2 solutions ?

Also my customer wants to implement a data cache to store the data retrieved from their MDM System. I am planning to propose a RDBMS instead of an In-Memory Solution. Does this group  have any recommendations on this approach?

[Teeter, John]

Indranil,

Thank you for your questions concerning Green Button, frame-works, and integration with existing systems. A few notes:

> We are looking at a requirement where an organization  would like to host their services on Google Cloud Platform and would preferably like to reuse their existing technology stack.

 The google cloud platform is somewhat unique in that it does not normally support the deployment of a full (Linux) stack. Do you intend to just use the GData aspects of the google cloud? If so, it would be very interesting to work as well with the OData libraries to accomplish EUI/ESPI integration. We have within OpenESPI, a proposed library project into that may have relevance to this effort. We are looking at Ruby libraries as well. If you can describe in more detail (for example, are you intending to use Google AppEngine as the runtime framework?) then we can certainly find a welcome home within OpenESPI. This would be a very effective DataCustodian.ResourceServer.

>I  am looking to implement a green button pilot where my client  is looking at extending its existing customer portal to handle 3rd Party Registration and Authorization and Access Management and use a separate ESPI service hosted on Google cloud to handle Subscription and Data Exchange.

As you know, within Green Button Connect My Data, both the DataCustodian and the ThirdParty must cooperate in the authorization process using the three-legged OAuth2 message patterns. If you were to provide the DataCustodian.AuthorizationServer within the "…existing customer portal…", you must still provide the ThirdParty elements of that exchange.

The plan is to use the Ontario ESPI Model as the starting point for building the ESPI service however I would like to reuse the existing solution stack which consists of OATH2, JBoss RestEasy, IBatis and Google Guice. As I am working with a different solution stack what would be the reusable factor to use the OpenESPI code. From  past experience does this group have any recommendations on following this approach.

Our current work with java is within the Spring framework. Google Guice is a (somewhat) similar, though much lighter weight, framework. Other elements – JBoss/RestEasy and IBatis (now MyBatis) provide capabilities similar to native java  JAXB2 and JPA respectively. I am not familiar with the OAUTH2 reference, but the Spring Security/OAuth2 is providing support within our Java implementation. As with the above, if a stack including the elements you describe is desired, we should look at a coding effort that reuses as much of the spring effort as possible, but the code base is likely to be somewhat unique and desiring of a separate repository. If there is broad community support for undertaking that development, OpenESPI would be happy to support your efforts.

I  understand that the key is to create a handshaking between the customer Portal which handles authorization and the ESPI Service. Both the applications will be hosted on Google Cloud but will be separate instance. Can somebody help us on how to do the necessary handshaking between these 2 solutions ?

You may find more detailed information concerning the message patterns related to ESPI's use of OAuth2 at:

    http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAuthorization.docx

Also my customer wants to implement a data cache to store the data retrieved from their MDM System. I am planning to propose a RDBMS instead of an In-Memory Solution. Does this group  have any recommendations on this approach?

Our Java implementation is three (configurable) approaches now (in memory, MySQL, and Postgres), and we have a proposed project to integrate with the Hadoop repository.

Hope this helps.

John Teeter

-----

Office: 301-975-4743 

Mobile: 301-325-7608

Presidential Innovation Fellow

Green Button for America

[Teeter, John]

I have been working to get API documentation ready in advance of the completion of the java code base. Although still a work in progress, you all may find it interesting/useful. 

It is in draft. It is being served directly from our github repository and is available for both downloading, forking, and contributing. 

Note1: The "gh_pages" is the default branch.

Note 2: there are some hard-coded URLs in the index and api-docs files that will be need modified if you serve this from your own github repository.

Thx,

John

====

Github repository: 

https://github.com/energyos/OpenESPI-GreenButtonDeveloper

Live pages:

http://energyos.github.io/OpenESPI-GreenButtonDeveloper/API/

--
--
You received this message because you are subscribed to the "energyos_espi" group.
To post to this group, send email to energy...@googlegroups.com
To unsubscribe from this group, send email to: energyos_esp...@googlegroups.com
 
http://www.energyos.org/espi/
 
---
You received this message because you are subscribed to the Google Groups "energyos_espi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to energyos_esp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Indranil Banerjee]

Thanks John , we are reviewing the below notes and will come back to
the group for further clarifications.

> --
> --
> You received this message because you are subscribed to the "energyos_espi"
> group.
> To post to this group, send email to energy...@googlegroups.com
> To unsubscribe from this group, send email to:
> energyos_esp...@googlegroups.com
>
> http://www.energyos.org/espi/
>
> ---

> You received this message because you are subscribed to a topic in the
> Google Groups "energyos_espi" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/energyos_espi/RmvZrlhvUmM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to