I'm happy to announce that we're going to have our first meeting of the Boston Chapter of the Cloud Security Alliance on Wednesday, April 27th at 6:00 at the Oracle office in Burlington, MA.
The topic for this meeting is Cloud Security Architecture. We wanted to cover both the conceptual (NIST, CSA Reference Architecture, etc) and the practical - real world examples of what people are using/deploying in their environments. The agenda will be something like this:
6:00 - 6:15 Introductions
6:15 - 6:45 Presentation 1 - Cloud Security Architecture - Conceptual
6:45 - 7:15 Break/Networking Session
7:15 - 7:45 Presentation 2 - Cloud Security Architecture - Practical/Use Case
7:45 - 8:00 Closing
We're looking for speakers on both the abstract notion of "What is Cloud Security Architecture?" and a more practical hands on use-case driven view of the topic. If you are interested in speaking or participating in a round-table type discussion, please send me which topic you're interested in presenting, and speaker's BIO (linkedin profile). Please send this to me (josh.bregman@vordel.com) by Thursday, March 31st.
Looking forward to a great first session.
Monday, March 21, 2011
Friday, March 4, 2011
Minutes from the Boston Chapter of the CSA's first Board Meeting
After many scheduling challenges, we had our first CSA Boston Chapter Board Meeting. The "Board" consists of me (Vordel), Prateek Mishra (Oracle),Matthew Gardiner (CA), and Kevin Fox (Cisco). A really good session for planning out the year. Here's the basic thinking:
- Divide the CSA guidance into 4 units and have 1 meeting focused around each unit
- The events will be about 2 hours - 1 hour on high-level information contained in the CSA guidance and 1 hour on a lower level details of someone who is actually living/implementing the scenario
- We'll rotate the location among CA, Oracle and Cisco locations - basically 128/495
The next steps are to have Matt, since it was his idea, to group the domains into the four meeting "buckets", and for us to meet again in two weeks to start the planning of the 1st meeting - targeted for some time in April.
Once we get the meeting "themes" worked out, we'll be publishing them with some tentative dates, and we'll be issuing a pseudo "call for speakers". Ultimately we're looking to have some really interesting speakers and presentations that are worth the trip - but for that to happen we'll need everyone's help. Ping any of the board members if you have a topic to suggest (aligned with the CSA Guidance) or a speaker that you think would be good.
We're also open to any other suggestions/guidance that people may have, so don't hesitate to speak up.
- Divide the CSA guidance into 4 units and have 1 meeting focused around each unit
- The events will be about 2 hours - 1 hour on high-level information contained in the CSA guidance and 1 hour on a lower level details of someone who is actually living/implementing the scenario
- We'll rotate the location among CA, Oracle and Cisco locations - basically 128/495
The next steps are to have Matt, since it was his idea, to group the domains into the four meeting "buckets", and for us to meet again in two weeks to start the planning of the 1st meeting - targeted for some time in April.
Once we get the meeting "themes" worked out, we'll be publishing them with some tentative dates, and we'll be issuing a pseudo "call for speakers". Ultimately we're looking to have some really interesting speakers and presentations that are worth the trip - but for that to happen we'll need everyone's help. Ping any of the board members if you have a topic to suggest (aligned with the CSA Guidance) or a speaker that you think would be good.
We're also open to any other suggestions/guidance that people may have, so don't hesitate to speak up.
Wednesday, March 2, 2011
How to turn an XML Gateway into a Maven Repository
I've made some real progress on the Maven integration with the Vordel XML Gateway. I've updated the incubator with the latest set of policies. These policies provide two main features:
One of the main challenges in getting a technology like the gateway that isn't built using Maven into the Maven world is the mapping of jars to POMs. As I showed previously, you can do this, but its a manual process. You could automate it with ANT tasks, but its still tricky. I encountered this problem before when I was trying a similar exercise with Oracle Entitlements Server. For that I wrote a bunch of custom code and deployed it as a WAR to the OES Admin Server. Not bad, but with the gateway it was even simpler.
Basically I used the static content service to point to the directories on gateway, and then used a policy to handle a view of the subtleties - we only have MD5 checksums, POMs need to get generated since we don't have them, some of the mappings for the org.eclipse libraries are irregular. For the main case, retrieving the jar, I'm just manipulating the http.request.uri property and passing it to the static content service. Magically, it returns the POM, the JAR, and the MD5 checksum of the JAR. I also used a cool feature new to 6.0.3 - the ${env.xxx} capabilities. You can use this namespace from inside of a policy, and the gateway will resolve the value based on the envSettings.props file. I used this to specify the values of the location of the gateway in my environment
In order to take advantage of my gateway as a repository, I modified the parent POM of the sample-filter, to include:
This means that when its looking for the dependencies, it will check the gateway, and they will be downloaded to your local repository so you can compile. Maven supports SSL and Basic Authentication, so these things could easily be added to both the Maven configuration as well as applied to the Maven policies running on the gateway.
The first question is "Why would you want to do that?". One use case that I'm working on is for custom filters. Once the jar is built, it needs to be copied to the gateway's lib directory, so this is the foundation for that. I'm not there yet - need to do something with the file once its there, but I like the simplicity of using the mvn deploy task to push the artifact to the gateway for me. Ultimately my goal is to package up all of the dependent artifacts and push/deploy them to the gateway.
The policies for this one were a little more complicated because the static content service only gets me so far - it doesn't handle HTTP PUT requests- which is what Maven uses to push the files to the server. No problem - I simply used the Save to File filter - to store the file on disk. Again, I used the ${env.xxx} to define the location on disk for the repository.
In order for projects to take advantage of this capability, I again modified the parent POM:
This means than when you run mvn deploy the artifact can be pushed and stored on the gateway. Presumably, in addition to just deploying the file, other actions could be taken - synchronously or asynchronously.
Notice that in the parent POM, there is the same server (localhost) referenced both times. I put the two separate repositories on different relative paths to simplify the implementation, but in practice these repositories are likely to be on separate instances. The idea is that a developer working on a sandbox instance can download the libraries to their local repository, develop the component and then deploy it to the dev-integration-gateway. The thinking here is that this gateway is the first managed gateway. The gateway's configuration is then pushed using the policy directory from the dev-integration gateway to QA. Getting all of this to work end-to-end using Maven is the goal of Maven Integration project on the incubator.
If you like where this is headed, get involved, join the incubator at cloudservicebroker.googlecode.com.
- The ability to download the Gateway libraries as dependencies directly from the gateway
- The ability to deploy Maven artifacts to the gateway
Exposing the libraries of the Gateway as POMs
One of the main challenges in getting a technology like the gateway that isn't built using Maven into the Maven world is the mapping of jars to POMs. As I showed previously, you can do this, but its a manual process. You could automate it with ANT tasks, but its still tricky. I encountered this problem before when I was trying a similar exercise with Oracle Entitlements Server. For that I wrote a bunch of custom code and deployed it as a WAR to the OES Admin Server. Not bad, but with the gateway it was even simpler.
Basically I used the static content service to point to the directories on gateway, and then used a policy to handle a view of the subtleties - we only have MD5 checksums, POMs need to get generated since we don't have them, some of the mappings for the org.eclipse libraries are irregular. For the main case, retrieving the jar, I'm just manipulating the http.request.uri property and passing it to the static content service. Magically, it returns the POM, the JAR, and the MD5 checksum of the JAR. I also used a cool feature new to 6.0.3 - the ${env.xxx} capabilities. You can use this namespace from inside of a policy, and the gateway will resolve the value based on the envSettings.props file. I used this to specify the values of the location of the gateway in my environment
env.maven.gateway.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\vordelgateway\\system\\lib
env.maven.policystudio.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\policystudio\\plugins
env.maven.repo2.path=c:\\Users\\jbregman\\repo2
In order to take advantage of my gateway as a repository, I modified the parent POM of the sample-filter, to include:
<repositories>
<repository>
<id>vordelgateway</id>
<url>http://localhost:9090/repo</url>
</repository>
</repositories>
This means that when its looking for the dependencies, it will check the gateway, and they will be downloaded to your local repository so you can compile. Maven supports SSL and Basic Authentication, so these things could easily be added to both the Maven configuration as well as applied to the Maven policies running on the gateway.
Deploying Maven Artifacts to the Gateway
The first question is "Why would you want to do that?". One use case that I'm working on is for custom filters. Once the jar is built, it needs to be copied to the gateway's lib directory, so this is the foundation for that. I'm not there yet - need to do something with the file once its there, but I like the simplicity of using the mvn deploy task to push the artifact to the gateway for me. Ultimately my goal is to package up all of the dependent artifacts and push/deploy them to the gateway.
The policies for this one were a little more complicated because the static content service only gets me so far - it doesn't handle HTTP PUT requests- which is what Maven uses to push the files to the server. No problem - I simply used the Save to File filter - to store the file on disk. Again, I used the ${env.xxx} to define the location on disk for the repository.
In order for projects to take advantage of this capability, I again modified the parent POM:
<distributionManagement>
<repository>
<id>dev-integration-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</repository>
<snapshotRepository>
<id>dev-integration-snapshot-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</snapshotRepository>
</distributionManagement>
This means than when you run mvn deploy the artifact can be pushed and stored on the gateway. Presumably, in addition to just deploying the file, other actions could be taken - synchronously or asynchronously.
Implications for the SDLC
Notice that in the parent POM, there is the same server (localhost) referenced both times. I put the two separate repositories on different relative paths to simplify the implementation, but in practice these repositories are likely to be on separate instances. The idea is that a developer working on a sandbox instance can download the libraries to their local repository, develop the component and then deploy it to the dev-integration-gateway. The thinking here is that this gateway is the first managed gateway. The gateway's configuration is then pushed using the policy directory from the dev-integration gateway to QA. Getting all of this to work end-to-end using Maven is the goal of Maven Integration project on the incubator.
If you like where this is headed, get involved, join the incubator at cloudservicebroker.googlecode.com.
Subscribe to:
Posts (Atom)