How to pass a Array's parameter to a Web service in a bpel

[phoenix_hua]

Hi,everyone:
I have a webservice with a Array's parameter,and the function of the web service is that inserting a group of data into datebase using batch sentence.I want to invoke the webservice in my bpel ,and my question is How to  pass a Array's parameter to a Web service ?


Thanks
phoenix_hua

[Vitaly Bychkov]

Hi phoenix_hua,

If I'm right understand you, then your problem is how to fulfill array
in bpel?
There are different approaches to do it.
Assume arr  is an array that you have to fulfill:
- You can directly specify arr[0].. arr[2]: right click props node in
mapper - choose "Add Predicate..."
The predicate editor appears - put numeric literal into central part and
join with the predicate node in the right tree...

- Or you can use e.g. foreach and again you have to specify
correspondent predicate as described above
... e.c. :)

Regards,
Vitaly.

phoenix_hua wrote:

> Hi,everyone:
> I have a webservice with a Array's parameter,and the function of the web
> service is that inserting a group of data into datebase using batch
> sentence.I want to invoke the webservice in my bpel ,and my question is How
> to  pass a Array's parameter to a Web service ?
>
>
> Thanks
> phoenix_hua
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[phoenix_hua]

Hi,Vitaly
Thanks for your answer !
Your answer is very worth for me ,I will try as your said!


Best Regards,
Phoenix_hua

[Karel de Bruin]

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes?

I am looking into SAML and OpenSSO.

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented;
and for authorisation you could use OpenSSO's Access Manager.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[SherryWeng]

Some javascript/style in this post has been disabled (why?)

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Karel de Bruin]

Some javascript/style in this post has been disabled (why?)

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng <[hidden email]>
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Michael.Czapski]

Some javascript/style in this post has been disabled (why?)

Hello, Karel.

If I had a bunch of existing services which to secure, and I was developing more, I would seriously consider a gateway-based solution. This way I would not need to modify existing services and I would not need to learn (as a developer) about security. The gateway would be run by the security people.

Have a look, if you have an interest , at the blog entry "Java CAPS 6 - Providing Policy-driven Web Services Security support using a XML Security Gateway", at http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy. In this entry I am discussing how a gateway can be used to secure Java CASP 6 classic services but the services can by any services, whether Java CAPS or not.

Regards

Michael

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Karel de Bruin]

Some javascript/style in this post has been disabled (why?)

Hi Michael

Thank you, I am currently reading your "WS-Security for Java CAPS the Gateway Way_1.0" document. It is providing much needed insight.

However, I am working with people that are reluctant to use any non-Sun/ non-Open Source software. I'll therefore be looking at Metro. 

Do you have experience using Metro?

Regards

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" <[hidden email]>
To: [hidden email]
Sent: Thursday, 2 July, 2009 8:27:01
Subject: Re: BPEL/Web Services Security

Hello, Karel..

If I had a bunch of existing services which to secure, and I was developing more, I would seriously consider a gateway-based solution.. This way I would not need to modify existing services and I would not need to learn (as a developer) about security. The gateway would be run by the security people.

Have a look, if you have an interest , at the blog entry "Java CAPS 6 - Providing Policy-driven Web Services Security support using a XML Security Gateway", at http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy. In this entry I am discussing how a gateway can be used to secure Java CASP 6 classic services but the services can by any services, whether Java CAPS or not.

Regards

Michael

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Michael.Czapski]

Some javascript/style in this post has been disabled (why?)

Hello, Karel.

The WS-Security 1.0 piece was a workaround for lack of WS-Security support in Java CAPS 5.1. At that time JAX-RPC was the only way to go. With Metro and JAX-WS things have changed. With OpenESB / GlassFish ESB and Java CAPS 6 you have options which were not available in Java CAPS 5.1. You can create an EJB-based web service and enable various security options through the NetBeans UI. This is the best way to get to the Metro stack and work with it. There are tutorials on the Internet on that topic. You can also use the JBI-based SOAP/HTTP Binding Component in a JBI solution to enable certain WS-Security options. That is somewhat less graphical. In both cases you are relying on a developer to know enough about WS-Security to do the right thing. In both cases you a relying on a developer to make changes if your security policies change. For small scale deployments that would work, with some discipline. For medium to large deployment it is unlikely to work well because your developers will have varying degree of security knowledge and because you will have unplanned demand for developer resource if it turns out that you need to wholesale change security policy because somebody made a political decision or because a security hole was discovered in something or another.

Some additional information and examples:
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
http://wiki.open-esb.java.net/Wiki.jsp?page=UsingTangoWebServiceAttributes
http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html - look at the WSIT Security chapter

Ideally you probably would like ot make security as painless as possible. NetBeans graphical support for WSIT heps with the EJB-based web services. SOAP/HTTP BC helps in teh JBI world.

Regards

Michael


Karel de Bruin wrote:

Hi Michael

Thank you, I am currently reading your "WS-Security for Java CAPS the Gateway Way_1.0" document. It is providing much needed insight.

However, I am working with people that are reluctant to use any non-Sun/ non-Open Source software. I'll therefore be looking at Metro. 

Do you have experience using Metro?

Regards

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" [hidden email]
To: [hidden email]
Sent: Thursday, 2 July, 2009 8:27:01
Subject: Re: BPEL/Web Services Security

Hello, Karel..

If I had a bunch of existing services which to secure, and I was developing more, I would seriously consider a gateway-based solution.. This way I would not need to modify existing services and I would not need to learn (as a developer) about security. The gateway would be run by the security people.

Have a look, if you have an interest , at the blog entry "Java CAPS 6 - Providing Policy-driven Web Services Security support using a XML Security Gateway", at http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy. In this entry I am discussing how a gateway can be used to secure Java CASP 6 classic services but the services can by any services, whether Java CAPS or not.

Regards

Michael

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Karel de Bruin]

Some javascript/style in this post has been disabled (why?)

Hi Michael

Thank you for being so patient with my limited knowledge on security.

Since we are using JBI-based Web services, we'll then configure the individual HTTP Binding Components. 

To authorize an incoming SOAP message, we'll (hopefully) access an existing Sun Directory Server LDAP and check if a user is authorized.

I suppose it is up to us to decide which security mechanism to add?

This is where confusion still comes in for me. Are there no guidelines from Sun that say e.g: "we recommend using 'this' security mechanism with 'this' product" ?

Thank you so much.

Regards,

Karel

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" <[hidden email]>
To: [hidden email]
Sent: Thursday, 2 July, 2009 9:42:14
Subject: Re: BPEL/Web Services Security

Hello, Karel.

The WS-Security 1.0 piece was a workaround for lack of WS-Security support in Java CAPS 5.1. At that time JAX-RPC was the only way to go. With Metro and JAX-WS things have changed. With OpenESB / GlassFish ESB and Java CAPS 6 you have options which were not available in Java CAPS 5.1. You can create an EJB-based web service and enable various security options through the NetBeans UI. This is the best way to get to the Metro stack and work with it. There are tutorials on the Internet on that topic. You can also use the JBI-based SOAP/HTTP Binding Component in a JBI solution to enable certain WS-Security options. That is somewhat less graphical. In both cases you are relying on a developer to know enough about WS-Security to do the right thing. In both cases you a relying on a developer to make changes if your security policies change. For small scale deployments that would work, with some discipline. For medium to large deployment it is unlikely to work well because your developers will have varying degree of security knowledge and because you will have unplanned demand for developer resource if it turns out that you need to wholesale change security policy because somebody made a political decision or because a security hole was discovered in something or another.

Some additional information and examples:
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
http://wiki.open-esb.java.net/Wiki.jsp?page=UsingTangoWebServiceAttributes
http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html - look at the WSIT Security chapter

Ideally you probably would like ot make security as painless as possible. NetBeans graphical support for WSIT heps with the EJB-based web services. SOAP/HTTP BC helps in teh JBI world.

Regards

Michael


Karel de Bruin wrote:

Hi Michael

Thank you, I am currently reading your "WS-Security for Java CAPS the Gateway Way_1.0" document. It is providing much needed insight.

However, I am working with people that are reluctant to use any non-Sun/ non-Open Source software. I'll therefore be looking at Metro. 

Do you have experience using Metro?

Regards

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" [hidden email]
To: [hidden email]
Sent: Thursday, 2 July, 2009 8:27:01
Subject: Re: BPEL/Web Services Security

Hello, Karel..

If I had a bunch of existing services which to secure, and I was developing more, I would seriously consider a gateway-based solution.. This way I would not need to modify existing services and I would not need to learn (as a developer) about security. The gateway would be run by the security people.

Have a look, if you have an interest , at the blog entry "Java CAPS 6 - Providing Policy-driven Web Services Security support using a XML Security Gateway", at http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy. In this entry I am discussing how a gateway can be used to secure Java CASP 6 classic services but the services can by any services, whether Java CAPS or not.

Regards

Michael

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[Michael.Czapski]

Some javascript/style in this post has been disabled (why?)

Hello, Kerel.

This is where I step back to let these more knowledgeable to respond. With JBI the Sun Engineers who are building the product will be better equipped to advise you.
Sherry?

Regards

Michael

Karel de Bruin wrote:

Hi Michael

Thank you for being so patient with my limited knowledge on security.

Since we are using JBI-based Web services, we'll then configure the individual HTTP Binding Components. 

To authorize an incoming SOAP message, we'll (hopefully) access an existing Sun Directory Server LDAP and check if a user is authorized.

I suppose it is up to us to decide which security mechanism to add?

This is where confusion still comes in for me. Are there no guidelines from Sun that say e.g: "we recommend using 'this' security mechanism with 'this' product" ?

Thank you so much.

Regards,

Karel

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" [hidden email]
To: [hidden email]
Sent: Thursday, 2 July, 2009 9:42:14
Subject: Re: BPEL/Web Services Security

Hello, Karel.

The WS-Security 1.0 piece was a workaround for lack of WS-Security support in Java CAPS 5.1. At that time JAX-RPC was the only way to go. With Metro and JAX-WS things have changed. With OpenESB / GlassFish ESB and Java CAPS 6 you have options which were not available in Java CAPS 5.1. You can create an EJB-based web service and enable various security options through the NetBeans UI. This is the best way to get to the Metro stack and work with it. There are tutorials on the Internet on that topic. You can also use the JBI-based SOAP/HTTP Binding Component in a JBI solution to enable certain WS-Security options. That is somewhat less graphical. In both cases you are relying on a developer to know enough about WS-Security to do the right thing. In both cases you a relying on a developer to make changes if your security policies change. For small scale deployments that would work, with some discipline. For medium to large deployment it is unlikely to work well because your developers will have varying degree of security knowledge and because you will have unplanned demand for developer resource if it turns out that you need to wholesale change security policy because somebody made a political decision or because a security hole was discovered in something or another.

Some additional information and examples:
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
http://wiki.open-esb.java.net/Wiki.jsp?page=UsingTangoWebServiceAttributes
http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html - look at the WSIT Security chapter

Ideally you probably would like ot make security as painless as possible. NetBeans graphical support for WSIT heps with the EJB-based web services. SOAP/HTTP BC helps in teh JBI world.

Regards

Michael


Karel de Bruin wrote:

Hi Michael

Thank you, I am currently reading your "WS-Security for Java CAPS the Gateway Way_1.0" document. It is providing much needed insight.

However, I am working with people that are reluctant to use any non-Sun/ non-Open Source software. I'll therefore be looking at Metro. 

Do you have experience using Metro?

Regards

---

From: "Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS" [hidden email]
To: [hidden email]
Sent: Thursday, 2 July, 2009 8:27:01
Subject: Re: BPEL/Web Services Security

Hello, Karel..

If I had a bunch of existing services which to secure, and I was developing more, I would seriously consider a gateway-based solution.. This way I would not need to modify existing services and I would not need to learn (as a developer) about security. The gateway would be run by the security people.

Have a look, if you have an interest , at the blog entry "Java CAPS 6 - Providing Policy-driven Web Services Security support using a XML Security Gateway", at http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy. In this entry I am discussing how a gateway can be used to secure Java CASP 6 classic services but the services can by any services, whether Java CAPS or not.

Regards

Michael

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[SherryWeng]

Some javascript/style in this post has been disabled (why?)

There is quite a bit of overlap between OpenSSO and Metro in terms of the security offerings. Metro is fully compliant with the WS-Security/WS-Policy specs, and an extra point is its interoperability with other BP compliant services, e.g. Microsoft .NET
I assume you're using OpenESB/HTTP BC. If I guessed it right, then the security solution is already provided for you. We use OpenSSO's Access Manager mainly for transport authentication (i.e. the username/password validation in the HTTP header), and we use Metro for webservice (SOAP message level) security.  Your task would likely be figuring out which security option is most appropriate for your application, and the rest should be just configuring the options using the tools we provide.

Here are a few more links you might want to look at in detail:
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
(see section "Configuring Security Mechanisms")
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITConfiguration
(this shows how to enable WS security options in general)

For tutorials/examples of a few well-known security options:
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITSAMLSV
http://wiki.open-esb.java.net/Wiki.jsp?page=Httpbc.using.secure.token.service
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts

For transport security:

http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBasicAuthentication
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCAccessManagerAuthorization
http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCAccessManagerClasspathSetup

HTH
--Sherry

Karel de Bruin wrote:

Hi

Thank you for the reply. I am a bit confused with all the options out there. I came across OpenSSO and thought it might be an all-in-one solution to our security needs. I have not worked with metro, but will read up about it now.. 

I should rather ask this: 

If you were to add security(specifically authorization, authentication, and message integrity) to existing BPEL processes, in your opinion, what would be the best solution?

Regards,

Karel

---

From: Sherry Weng [hidden email]
To: [hidden email]
Sent: Wednesday, 1 July, 2009 21:08:41
Subject: Re: BPEL/Web Services Security

Hi,

Please see below...

Karel de Bruin wrote:

Hi


I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.

Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes? 
  

Most likely, you want to secure the webservice that exposes the BPEL process

I am looking into SAML and OpenSSO.
  

Are you only interested in using OpenSSO to fulfill the security requirement, or is that something you'd come across which advertises the security options you're looking for?
BTW, for OpenESB/GlassFish ESB, we depend on the Metro stack for webservice security implementations. It is fully compliant with the WS-Security specification and provides various security options, including SAML

As far as I could understand:
for message integrity and message confidentiality, HTTP over SSL should be used;
for authentication, digital signatures should be implemented; 
  

AFAIK, there are quite a few options to achieve message integrity, confidentiality, authentication, trusted conversation... For a more comprehensive review, you might want to check out this doc: http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html

and for authorisation you could use OpenSSO's Access Manager. 
  

For OpenESB, we do use OpenSSO's Access Manager for transport level authentication. You could absolutely use AM for authorization too, but we don't support this today.

Any suggestions on how to implement security would be helpful.

Regards,

Karel de Bruin





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

  

[SherryWeng]

Just a few more clarifications to extend from Michael's summary:
1. EE based services provide the options to enable (message level)
security via either the OpenSSO or Metro implementation. For JBI-based
webservices, i.e. through HTTP binding, we only use the Metro
implementation, but it offers the same set of options as the EE based ones.
2. For security configuration, the JBI based solution also has NetBean
tooling support. The security configuration UI is almost identical for
both solutions, in fact, the only obvious difference would be the
"place" to launch the configuration editor.
3. Most of the time, the security policies (which is the design time
metadata to define the security option for a given webservice) would be
embedded directly in the WSDL. I believe that is what Michael pointed
out as the potential migration problem. However, there is support to
externalize the policies such that the security changes can be applied
more dynamically.

Regards
--Sherry

Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS
wrote:

> Hello, Karel.
>
> The WS-Security 1.0 piece was a workaround for lack of WS-Security
> support in Java CAPS 5.1. At that time JAX-RPC was the only way to go.
> With Metro and JAX-WS things have changed. With OpenESB / GlassFish
> ESB and Java CAPS 6 you have options which were not available in Java
> CAPS 5.1. You can create an EJB-based web service and enable various
> security options through the NetBeans UI. This is the best way to get
> to the Metro stack and work with it. There are tutorials on the
> Internet on that topic. You can also use the JBI-based SOAP/HTTP
> Binding Component in a JBI solution to enable certain WS-Security
> options. That is somewhat less graphical. In both cases you are
> relying on a developer to know enough about WS-Security to do the
> right thing. In both cases you a relying on a developer to make
> changes if your security policies change. For small scale deployments
> that would work, with some discipline. For medium to large deployment
> it is unlikely to work well because your developers will have varying
> degree of security knowledge and because you will have unplanned
> demand for developer resource if it turns out that you need to
> wholesale change security policy because somebody made a political
> decision or because a security hole was discovered in something or
> another.
>
> Some additional information and examples:
> http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts
> http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
> http://wiki.open-esb.java.net/Wiki.jsp?page=UsingTangoWebServiceAttributes
> http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html 
> - look at the WSIT Security chapter
>
> Ideally you probably would like ot make security as painless as
> possible. NetBeans graphical support for WSIT heps with the EJB-based
> web services. SOAP/HTTP BC helps in teh JBI world.
>
> Regards
>
> Michael
>
>
> Karel de Bruin wrote:
>> Hi Michael
>>
>> Thank you, I am currently reading your "WS-Security for Java CAPS the
>> Gateway Way_1.0" document. It is providing much needed insight.
>>
>> However, I am working with people that are reluctant to use any
>> non-Sun/ non-Open Source software. I'll therefore be looking at Metro.
>>
>> Do you have experience using Metro?
>>
>> Regards
>>
>> ------------------------------------------------------------------------
>> *From:* "Michael Czapski, Principal Field Technologist, ANZ APS,
>> SOA/BI/Java CAPS" <[hidden email]>
>> *To:* [hidden email]
>> *Sent:* Thursday, 2 July, 2009 8:27:01
>> *Subject:* Re: BPEL/Web Services Security
>>
>> Hello, Karel..
>>
>> If I had a bunch of existing services which to secure, and I was
>> developing more, I would seriously consider a gateway-based
>> solution.. This way I would not need to modify existing services and
>> I would not need to learn (as a developer) about security. The
>> gateway would be run by the security people.
>>
>> Have a look, if you have an interest , at the blog entry "Java CAPS 6
>> - Providing Policy-driven Web Services Security support using a XML
>> Security Gateway
>> <http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy>",
>> at
>> http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy.
>> In this entry I am discussing how a gateway can be used to secure
>> Java CASP 6 classic services but the services can by any services,
>> whether Java CAPS or not.
>>
>> Regards
>>
>> Michael
>>
>> Karel de Bruin wrote:
>>> Hi
>>>
>>> Thank you for the reply. I am a bit confused with all the options
>>> out there. I came across OpenSSO and thought it might be an
>>> all-in-one solution to our security needs. I have not worked with
>>> metro, but will read up about it now..
>>>
>>> I should rather ask this:
>>> If you were to add security(specifically authorization,
>>> authentication, and message integrity) to existing BPEL processes,
>>> in your opinion, what would be the best solution?
>>>
>>> Regards,
>>>
>>> Karel
>>> ------------------------------------------------------------------------
>>> *From:* Sherry Weng <[hidden email]>
>>> *To:* [hidden email]
>>> *Sent:* Wednesday, 1 July, 2009 21:08:41
>>> *Subject:* Re: BPEL/Web Services Security
>>>
>>> Hi,
>>>
>>> Please see below...
>>>
>>> Karel de Bruin wrote:
>>>> Hi
>>>>
>>>>
>>>> I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.
>>>>
>>>> Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes?
>>>>  
>>> Most likely, you want to secure the webservice that exposes the BPEL
>>> process
>>>> I am looking into SAML and OpenSSO.
>>>>  
>>> Are you only interested in using OpenSSO to fulfill the security
>>> requirement, or is that something you'd come across which advertises
>>> the security options you're looking for?
>>> BTW, for OpenESB/GlassFish ESB, we depend on the Metro
>>> <https://metro.dev.java.net/> stack for webservice security
>>> implementations. It is fully compliant with the WS-Security
>>> specification and provides various security options, including SAML
>>>> As far as I could understand:
>>>> for message integrity and message confidentiality, HTTP over SSL should be used;
>>>> for authentication, digital signatures should be implemented;
>>>>  
>>> AFAIK, there are quite a few options to achieve message integrity,
>>> confidentiality, authentication, trusted conversation... For a more
>>> comprehensive review, you might want to check out this doc:
>>> http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html
>>>> and for authorisation you could use OpenSSO's Access Manager.
>>>>  
>>> For OpenESB, we do use OpenSSO's Access Manager for transport level
>>> authentication. You could absolutely use AM for authorization too,
>>> but we don't support this today.
>>>> Any suggestions on how to implement security would be helpful.
>>>>
>>>> Regards,
>>>>
>>>> Karel de Bruin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>  
>>>
>>
>> --
>>
>> --
>>
>> <http://www.sun.com/books/catalog/java_caps.xml>
>>
>> Podcast 1
>> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P1of2Java/details>  
>> Podcast 2
>> <http://mediacast.sun.com/users/Michael..Czapski-Sun/media/JavaCAPS_Czapski_Marry_P2of2Java/details>
>>
>>
>>
>>
>>  
>>
>>
>>
>> *Michael Czapski, BSc Computing, MSc eBus.Tech.*
>> Principal Field Technologist, Software
>> SOA/BI/Java CAPS
>>
>> *Sun Microsystems*
>> 33 Berry Street, North Sydney
>> NSW 2060  Australia
>> Phone [phone]
>> Email [hidden email] <mailto:[hidden email]>
>>
>> Blog: http://blogs.sun.com/javacapsfieldtech/
>>
>> LinkedIn: MichaelCzapski <http://www.linkedin.com/in/michaelczapski>
>>
>> Skype: michaelczapski <skype:michaelczapski>
>>
>> Screencasts and Document Archives:
>> http://mediacast.sun.com/users/Michael.Czapski-Sun
>>
>> JavaOne 2008 SYS-CON.TV Interview with Michael Czapski and Brendan
>> Marry: http://tv.sys-con.com/node/674561
>>
>>  
>>
>>
>
> --
>
> --
>
> <http://www.sun.com/books/catalog/java_caps.xml>
>
> Podcast 1
> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P1of2Java/details>  
> Podcast 2
> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P2of2Java/details>
>
>
>
>
>  
>
>
>
> *Michael Czapski, BSc Computing, MSc eBus.Tech.*
> Principal Field Technologist, Software
> SOA/BI/Java CAPS
>
> *Sun Microsystems*
> 33 Berry Street, North Sydney
> NSW 2060 Australia
> Phone [phone]
> Email [hidden email] <mailto:[hidden email]>
>
> Blog: http://blogs.sun.com/javacapsfieldtech/
>
> LinkedIn: MichaelCzapski <http://www.linkedin.com/in/michaelczapski>
>
> Skype: michaelczapski <skype:michaelczapski>
>
> Screencasts and Document Archives:
> http://mediacast.sun.com/users/Michael.Czapski-Sun
>
> JavaOne 2008 SYS-CON.TV Interview with Michael Czapski and Brendan
> Marry: http://tv.sys-con.com/node/674561
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[SherryWeng]

Yes, it makes most sense to have the solutions architect/developer
decide which security mechanism to use based on the need of the
application.
For example, if you simply want to prevent network eavesdropping, SSL
encryption would probably suffice; If you need to make sure only legit
users can access the service, user name authentication is probably a
good choice; If you'd like more sophisticated ways to define
authentication/authorization rights with single sign-on, SAML may be
your choice...
Bottom line is you have the flexibility, you might want to invest a bit
research time to make the right choice. OpenESB provides the means, but
we don't dictate the option.

Regards
--Sherry

Michael Czapski, Principal Field Technologist, ANZ APS, SOA/BI/Java CAPS
wrote:

> Hello, Kerel.
>
> This is where I step back to let these more knowledgeable to respond.
> With JBI the Sun Engineers who are building the product will be better
> equipped to advise you.
> Sherry?
>
> Regards
>
> Michael
>
> Karel de Bruin wrote:
>> Hi Michael
>>
>> Thank you for being so patient with my limited knowledge on security.
>>
>> Since we are using JBI-based Web services, we'll then configure the
>> individual HTTP Binding Components.
>>
>> To authorize an incoming SOAP message, we'll (hopefully) access an
>> existing Sun Directory Server LDAP and check if a user is authorized.
>>
>> I suppose it is up to us to decide which security mechanism to add?
>> This is where confusion still comes in for me. Are there no
>> guidelines from Sun that say e.g: "we recommend using 'this' security
>> mechanism with 'this' product" ?
>>
>> Thank you so much.
>>
>> Regards,
>>
>> Karel
>>
>>
>> ------------------------------------------------------------------------
>> *From:* "Michael Czapski, Principal Field Technologist, ANZ APS,
>> SOA/BI/Java CAPS" <[hidden email]>
>> *To:* [hidden email]
>> *Sent:* Thursday, 2 July, 2009 9:42:14
>> *Subject:* Re: BPEL/Web Services Security
>>
>> Hello, Karel.
>>
>> The WS-Security 1.0 piece was a workaround for lack of WS-Security
>> support in Java CAPS 5.1. At that time JAX-RPC was the only way to
>> go. With Metro and JAX-WS things have changed. With OpenESB /
>> GlassFish ESB and Java CAPS 6 you have options which were not
>> available in Java CAPS 5.1. You can create an EJB-based web service
>> and enable various security options through the NetBeans UI. This is
>> the best way to get to the Metro stack and work with it. There are
>> tutorials on the Internet on that topic. You can also use the
>> JBI-based SOAP/HTTP Binding Component in a JBI solution to enable
>> certain WS-Security options. That is somewhat less graphical. In both
>> cases you are relying on a developer to know enough about WS-Security
>> to do the right thing. In both cases you a relying on a developer to
>> make changes if your security policies change. For small scale
>> deployments that would work, with some discipline. For medium to
>> large deployment it is unlikely to work well because your developers
>> will have varying degree of security knowledge and because you will
>> have unplanned demand for developer resource if it turns out that you
>> need to wholesale change security policy because somebody made a
>> political decision or because a security hole was discovered in
>> something or another.
>>
>> Some additional information and examples:
>> http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSITMutualCerts
>> http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBindingComponentSecurity
>> http://wiki.open-esb.java.net/Wiki.jsp?page=UsingTangoWebServiceAttributes
>> http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html 
>> - look at the WSIT Security chapter
>>
>> Ideally you probably would like ot make security as painless as
>> possible. NetBeans graphical support for WSIT heps with the EJB-based
>> web services. SOAP/HTTP BC helps in teh JBI world.
>>
>> Regards
>>
>> Michael
>>
>>
>> Karel de Bruin wrote:
>>> Hi Michael
>>>
>>> Thank you, I am currently reading your "WS-Security for Java CAPS
>>> the Gateway Way_1.0" document. It is providing much needed insight.
>>>
>>> However, I am working with people that are reluctant to use any
>>> non-Sun/ non-Open Source software. I'll therefore be looking at Metro.
>>>
>>> Do you have experience using Metro?
>>>
>>> Regards
>>>
>>> ------------------------------------------------------------------------
>>> *From:* "Michael Czapski, Principal Field Technologist, ANZ APS,
>>> SOA/BI/Java CAPS" <[hidden email]>
>>> *To:* [hidden email]
>>> *Sent:* Thursday, 2 July, 2009 8:27:01
>>> *Subject:* Re: BPEL/Web Services Security
>>>
>>> Hello, Karel..
>>>
>>> If I had a bunch of existing services which to secure, and I was
>>> developing more, I would seriously consider a gateway-based
>>> solution.. This way I would not need to modify existing services and
>>> I would not need to learn (as a developer) about security. The
>>> gateway would be run by the security people.
>>>
>>> Have a look, if you have an interest , at the blog entry "Java CAPS
>>> 6 - Providing Policy-driven Web Services Security support using a
>>> XML Security Gateway
>>> <http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy>",
>>> at
>>> http://blogs.sun.com/javacapsfieldtech/entry/java_caps_6_providing_policy.
>>> In this entry I am discussing how a gateway can be used to secure
>>> Java CASP 6 classic services but the services can by any services,
>>> whether Java CAPS or not.
>>>
>>> Regards
>>>
>>> Michael
>>>
>>> Karel de Bruin wrote:
>>>> Hi
>>>>
>>>> Thank you for the reply. I am a bit confused with all the options
>>>> out there. I came across OpenSSO and thought it might be an
>>>> all-in-one solution to our security needs. I have not worked with
>>>> metro, but will read up about it now..
>>>>
>>>> I should rather ask this:
>>>> If you were to add security(specifically authorization,
>>>> authentication, and message integrity) to existing BPEL processes,
>>>> in your opinion, what would be the best solution?
>>>>
>>>> Regards,
>>>>
>>>> Karel
>>>> ------------------------------------------------------------------------
>>>> *From:* Sherry Weng <[hidden email]>
>>>> *To:* [hidden email]
>>>> *Sent:* Wednesday, 1 July, 2009 21:08:41
>>>> *Subject:* Re: BPEL/Web Services Security
>>>>
>>>> Hi,
>>>>
>>>> Please see below...
>>>>
>>>> Karel de Bruin wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>> I am doing research regarding the different options available for adding security to BPEL processes, running on a clustered GlassFish v2.1.
>>>>>
>>>>> Am I correct in saying that to secure a BPEL process, you should secure the web services it invokes?
>>>>>  
>>>> Most likely, you want to secure the webservice that exposes the
>>>> BPEL process
>>>>> I am looking into SAML and OpenSSO.
>>>>>  
>>>> Are you only interested in using OpenSSO to fulfill the security
>>>> requirement, or is that something you'd come across which
>>>> advertises the security options you're looking for?
>>>> BTW, for OpenESB/GlassFish ESB, we depend on the Metro
>>>> <https://metro.dev.java.net/> stack for webservice security
>>>> implementations. It is fully compliant with the WS-Security
>>>> specification and provides various security options, including SAML
>>>>> As far as I could understand:
>>>>> for message integrity and message confidentiality, HTTP over SSL should be used;
>>>>> for authentication, digital signatures should be implemented;
>>>>>  
>>>> AFAIK, there are quite a few options to achieve message integrity,
>>>> confidentiality, authentication, trusted conversation... For a more
>>>> comprehensive review, you might want to check out this doc:
>>>> http://java.sun.com/webservices/reference/tutorials/wsit/doc/index.html
>>>>> and for authorisation you could use OpenSSO's Access Manager.
>>>>>  
>>>> For OpenESB, we do use OpenSSO's Access Manager for transport level
>>>> authentication. You could absolutely use AM for authorization too,
>>>> but we don't support this today.
>>>>> Any suggestions on how to implement security would be helpful.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Karel de Bruin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>  
>>>>
>>>
>>> --
>>>
>>> --
>>>
>>> <http://www.sun.com/books/catalog/java_caps.xml>
>>>
>>> Podcast 1
>>> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P1of2Java/details>  
>>> Podcast 2
>>> <http://mediacast.sun.com/users/Michael..Czapski-Sun/media/JavaCAPS_Czapski_Marry_P2of2Java/details>
>>>
>>>
>>>
>>>
>>>  
>>>
>>>
>>>
>>> *Michael Czapski, BSc Computing, MSc eBus.Tech.*
>>> Principal Field Technologist, Software
>>> SOA/BI/Java CAPS
>>>
>>> *Sun Microsystems*
>>> 33 Berry Street, North Sydney
>>> NSW 2060  Australia
>>> Phone [phone]
>>> Email [hidden email] <mailto:[hidden email]>
>>>
>>> Blog: http://blogs.sun.com/javacapsfieldtech/
>>>
>>> LinkedIn: MichaelCzapski <http://www.linkedin.com/in/michaelczapski>
>>>
>>> Skype: michaelczapski <skype:michaelczapski>
>>>
>>> Screencasts and Document Archives:
>>> http://mediacast.sun.com/users/Michael.Czapski-Sun
>>>
>>> JavaOne 2008 SYS-CON.TV Interview with Michael Czapski and Brendan
>>> Marry: http://tv.sys-con.com/node/674561
>>>
>>>  
>>>
>>>
>>
>> --
>>
>> --
>>
>> <http://www.sun.com/books/catalog/java_caps.xml>
>>
>> Podcast 1
>> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P1of2Java/details>  
>> Podcast 2
>> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P2of2Java/details>
>>
>>
>>
>>
>>  
>>
>>
>>
>> *Michael Czapski, BSc Computing, MSc eBus.Tech..*
>> Principal Field Technologist, Software
>> SOA/BI/Java CAPS
>>
>> *Sun Microsystems*
>> 33 Berry Street, North Sydney
>> NSW 2060  Australia
>> Phone [phone]
>> Email [hidden email] <mailto:[hidden email]>
>>
>> Blog: http://blogs.sun.com/javacapsfieldtech/
>>
>> LinkedIn: MichaelCzapski <http://www.linkedin.com/in/michaelczapski>
>>
>> Skype: michaelczapski <skype:michaelczapski>
>>
>> Screencasts and Document Archives:
>> http://mediacast.sun.com/users/Michael.Czapski-Sun
>>
>> JavaOne 2008 SYS-CON.TV Interview with Michael Czapski and Brendan
>> Marry: http://tv.sys-con.com/node/674561
>>
>>  
>>
>>
>
> --
>
> --
>
> <http://www.sun.com/books/catalog/java_caps.xml>
>
> Podcast 1
> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P1of2Java/details>  
> Podcast 2
> <http://mediacast.sun.com/users/Michael.Czapski-Sun/media/JavaCAPS_Czapski_Marry_P2of2Java/details>
>
>
>
>
>  
>
>
>
> *Michael Czapski, BSc Computing, MSc eBus.Tech.*
> Principal Field Technologist, Software
> SOA/BI/Java CAPS
>
> *Sun Microsystems*
> 33 Berry Street, North Sydney
> NSW 2060 Australia
> Phone [phone]
> Email [hidden email] <mailto:[hidden email]>
>
> Blog: http://blogs.sun.com/javacapsfieldtech/
>
> LinkedIn: MichaelCzapski <http://www.linkedin.com/in/michaelczapski>
>
> Skype: michaelczapski <skype:michaelczapski>
>
> Screencasts and Document Archives:
> http://mediacast.sun.com/users/Michael.Czapski-Sun
>
> JavaOne 2008 SYS-CON.TV Interview with Michael Czapski and Brendan
> Marry: http://tv.sys-con.com/node/674561
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]