Architecture mails

On Wed, Aug 31, 2011 at 11:34 AM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

On Wed, Aug 31, 2011 at 10:34 AM, Amila Suriarachchi <ami...@wso2.com>wrote:

On Tue, Aug 30, 2011 at 2:59 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Isn't is possible to implement BAPI using a custom deployer like in DataServices.

So that we can use a custom deployment descriptor file (like .dbs) to specify parameters and it is exposed as a proper web service using a WSDL. The other advantage of this is that it can be used in a BPEL process as well.

We have that too.

ok. Then why need to have two implementations? ESB can invoke this either using send mediator or call back mediator.

thanks, Amila.

Thanks, Hiranya

thanks, Amila.

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

On Wed, Aug 31, 2011 at 10:34 AM, Amila Suriarachchi <ami...@wso2.com> wrote:

On Tue, Aug 30, 2011 at 2:59 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Isn't is possible to implement BAPI using a custom deployer like in DataServices.

So that we can use a custom deployment descriptor file (like .dbs) to specify parameters and it is exposed as a proper web service using a WSDL. The other advantage of this is that it can be used in a BPEL process as well.

We have that too.

Thanks, Hiranya

thanks, Amila.

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

On Wed, Aug 31, 2011 at 10:34 AM, Amila Suriarachchi <ami...@wso2.com> wrote:

On Tue, Aug 30, 2011 at 2:59 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Isn't is possible to implement BAPI using a custom deployer like in DataServices.

So that we can use a custom deployment descriptor file (like .dbs) to specify parameters and it is exposed as a proper web service using a WSDL. The other advantage of this is that it can be used in a BPEL process as well.

We have that too.

Thanks, Hiranya

thanks, Amila.

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

On Tue, Aug 30, 2011 at 2:59 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Isn't is possible to implement BAPI using a custom deployer like in DataServices.

So that we can use a custom deployment descriptor file (like .dbs) to specify parameters and it is exposed as a proper web service using a WSDL. The other advantage of this is that it can be used in a BPEL process as well.

thanks, Amila.

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

I am not quite sure how rich the decoded output from this tool is. When JMS is on AMQP, a single JMS message is a set of AMQP frames. So if you can read AMQP, you can decode a message sent using a C++ client and see where it would end up inside a Java broker. Is that something useful? :-).

Thanks, Danushka

On Tue, Aug 30, 2011 at 5:38 PM, Paul Fremantle <pa...@wso2.com> wrote:

Interesting. I don't quite understand how this would fit into an overall AMQP broker? Paul

On 30 August 2011 13:01, Danushka Menikkumbura < danu...@gmail.com> wrote:

http://www.inetco.com/resource-library/technology-amqp/

It looks appealing, it supports AMQP 1.0, though.

Thanks, Danushka

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse

UK: +44 207 096 0336 US: +1 646 595 7614

blog: http://pzf.fremantle.org twitter.com/pzfreo pa...@wso2.com

http://freo.me/wso2con11

wso2.com Lean Enterprise Middleware

Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Interesting. I don't quite understand how this would fit into an overall AMQP broker? Paul

On 30 August 2011 13:01, Danushka Menikkumbura < danu...@gmail.com> wrote:

http://www.inetco.com/resource-library/technology-amqp/

It looks appealing, it supports AMQP 1.0, though.

Thanks, Danushka

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse

UK: +44 207 096 0336 US: +1 646 595 7614

blog: http://pzf.fremantle.org twitter.com/pzfreo pa...@wso2.com

http://freo.me/wso2con11

wso2.com Lean Enterprise Middleware

Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

http://www.inetco.com/resource-library/technology-amqp/

It looks appealing, it supports AMQP 1.0, though.

Thanks, Danushka

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Adding one more point..

8. Making SAP transport transactional. (This will resolve many issues related to idoc losses etc.)

On Tue, Aug 30, 2011 at 2:59 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- Kasun Indrasiri Associate Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware

cell: +94 71 536 4128 Blog : http://kasunpanorama.blogspot.com/

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi Folks,

Today we had a discussion on the WSO2 SAP adapter. We briefly went through what we already have and discussed some new ideas.

Participants: Sanjiva, Kasun, Hiranya

Points discussed:

1. Current BAPI transport uses a custom XML representation of BAPI. This means the user has to do a lot of XSLT/XPath stuff even to invoke a simple BAPI. 2. Look into using BSF/JavaScript to directly invoke the JCo API from the mediation level. 3. Get rid of the BAPI/IDoc endpoint model which uses an external properties file. Instead, introduce a new endpoint format where all the relevant SAP parameters can be defined within the endpoint itself. 4. Look into developing a tooling layer in CStudio using JCo. This should be able to connect to a SAP system, browse available BAPIs and generate the necessary transformations (XSLT/Smooks) - Also look for any existing Eclipse tools for SAP 5. BAPI listener can be used to replace a legacy SAP system without breaking existing SAP clients - So we need this 6. Move the source to public SVN - Person who builds the source should provide the JCo library - Check whether we can configure Maven to build the component only when the JCo library is present 7. Write some articles around the SAP adapter

Please add if I've missed anything.

Thanks

-- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi all,

For my internship project, I'm helping develop the AppDev model, which is a server-side scripting environment where all application logic is intended to be written in JavaScript alone. It facilitates script execution on the server using the Apache Bean Scripting Framework and Mozilla Rhino.

As part of the JavaScript AppDev effort, I'm developing $subject for accessing Cassandra through Hector. This will consist of a .js file, a Java class and is intended to be run on Rhino. The architecture for same is as follows:

- The JavaScript file will act as a means of accessing Hector classes and methods from a server-side JavaScript environment made using Mozilla Rhino and Apache BSF. This will in effect act as a JavaScript wrapper for Java methods which will accept either a JSON string or a JavaScript object as arguments and provide a means to do the following: creating columns & supercolumns, deleting columns & supercolumns, column query (using the Hector class ColumnQuery) and initializing the schema (i.e. creating keyspaces, column families). This library will also use the JSON.stringify() method from the standard JSON2.js library to convert any encountered JavaScript objects into JSON before sending them over to the Java class.

- The Java class will handle calls to the Cassandra cluster via the Hector API. It will provide the methods for use by the above .js file. The methods are planned to be implemented as follows:

- The methods for inserting string columns and column supercolumns will accept JSON strings of a particular format, extract the values from them and use an instance of me.prettyprint.hector.api.mutation.Mutator from the Hector 0.8.0 API in a managed environment to insert either a column or supercolumn into a column family (normal or of type "super", respectively). An example JSON for creation of a new column would be:

{

"ExampleKey":{

"Name":"ExampleName", "Value":"ExampleValue"

}

}

- The methods for deleting columns & supercolumns and querying will act in a similar manner, and they will accept a similar json, but without the "Value" attribute. The query method will return the result of the query as JSON.

- The method for schema manipulation will facilitate creation of keyspaces and column families. It will also accept a JSON string, such as:

{

"Schema":{

"Host":"ExampleHostName", "Port":"9160" "Cluster":"ExampleClusterName", "Keyspace":"ExampleKeyspace", "ColumnFamily":"ExampleColumnFamily"

}

}

for creating or initializing the schema. If the specified keyspace and/or column families exist, they will be authorized for use by the other methods; and if not, they will be created on the specified cluster.

- The reason behind wrapping the above Java class with JavaScript is to hide the fact that a Java class exists and is being used to access Cassandra; as AppDev is envisioned to be an environment where the user will write his/her logic purely in JavaScript.

WDYT? Questions and comments are welcome.

-- Regards, Gokul

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi All,

In BAM Gadgets, we need to get data from the BAM backend to the browser. Those data sources are basically Web Services. Among these, Data Services and serveral Admin Services can bee seen. The previous model of the data retrieval flow was as below.

All bam gadgets call a jsp with the a particular string key(i.e. name of the operation such as getAllServers). Depending on the key,

- Jsp get the correct service and operation - Invoke the service - Result is converted either to a string/json and send back to the browser.

In the above model, there was a long list of if-else check for each operation. Further, if someone wanted to get data from a new service, then he will have to add certain set of logic into the JSP as well.

In order to get rid of that model, I created a tryit proxy like jsp which allow us to call any service without any changes to that JSP. Further, I tried to use Axis2 JSON support to invoke the services as in the 1 diagram of the attached image. But, it didn't allow as to invoke several services(such as admin services) due to a limitation of Axis2 JSON support, but it worked for Data services.

Then, I though of changing jsp proxy-to-Web Service call into a SOAP call and return the response as a JSON. At this level, JSP receives only XML responses from its services and there we should be able to convert the XML into JSON without any service/operation specific logic. So, I though of using Badgerfish conversion for that(although it too has limitations, it was the only method to convert ANY XML to JSON without loosing much information and knowing about the structure of the XML). So, Badgerfish was used as it was the best convention to keep even namespaces of the original XML in the resulting JSON.

Although in JSON world, there is nothing like XML namespaces, I thought of keeping that up as we are dealing with XML responses. As an example, I will assume that a web service respond us with an XML as below.

<p:name xmlns:p="p.com"> <a:name xmlns:a="a.com">Ruchira</a:name> <a:name xmlns:a="aa.com">Wageesha</a:name> </p:name>

So, this XML has 2 name element in two different namespaces. i.e. One will need to differentiate two name elements depending on the namespace.(This is a small example, but there are many occasions where one will need to do namespace aware queries in a gadget).

Again, lets assume that withing a gadget, I wanted to get the value of "name" in the "aa.com" namespace. i.e. Wageesha. So, if we loose the namespace information, then it would be impossible. Btw, we can ask the JSON to give us the second "name" element. But again, the order might not be consistent(depending on the output schema).

Like wise, although we are in an environment where namespaces aren't, we will have think about them as we are dealing with namespace aware XML data. So, Badgerfish was the solution.

Now, lets see what is the badgerfish representation of above XML.

{ "p:name": { "@xmlns": { "p": "p.com" }, "a:name": [{ "@xmlns": { "p": "p.com", "a": "a.com" }, "$": "Ruchira" }, { "@xmlns": { "p": "p.com", "a": "aa.com" }, "$": "Wageesha" }] } }

It is an unreadable JSON even for the above small XML. Geting the value of "name" element in "aa.com" namespace, directly from the JSON is even a little bit harder. We can't get it simply using favorite "." notation(as we aren't aware of the order of the "a:name" array in the above JSON). So we will have to iterate through the JSON and find the matching element.

Writing code to iterate over the JSON, each time we want to get an element value might make the code messy. Then I though of writing a simple "Axiom"(name "axiom" might give you a wrong expression) like JSON wrapper over the Badgerfish JSON. I.e. one can create an object named "Axiom" and access elements as we do in XML environment or E4X environment. For our above scenario, it would be

var xml = new Axiom(badgerfishJSON); var name = xml.getChildrenWithNamespaceURI("aa.com")[0];

Axiom object will have a pointer to the passed "badgerfishJSON". So once the "getChildrenWithNamespaceURI" method is called, it will iterate through the properties and return the relevant value. So the iteration logics for reading namespace aware elements/attributes won't be duplicated. That was the main idea behind using Axiom like wrapper over JSON.(Creating an new Axiom object won't duplicate the whole JSON, rather it will keep several pointers to the elements of the original JSON, so it won't take much browser memory)

If you are thinking it as an effort to use XML/namespaces in JSON environment and it shouldn't be done, please let this thread know. But point I though is if we are dealing with XML data, then there should be a good replacement for XML manipulation in the browser environment. Otherwise can send customized simple JSON, but the structure depends on each and every response. Further, not all the browsers doens't support XML DOM[2], but HTML DOM[1]. In HTML DOM, we can't do namespace aware queries.

One other thing I noted during gadget development using wso2vis is,

wso2vis.js - 7605 lines of codes with 653K wso2vis-min.js - 914 lines of codes with the size of 555K(I can't open it even in gedit)

So, each time we use a wso2vis or any big library within a gadget, what it does is read those JS files and put the content in the gadget xml. As those are put inline within the gadget xml, they won't get cached at least in the browser. So, for 10 gadgets, it load 10 times and keep everything in the memory. So, if we are using wso2vis or any other big libraries, we will have to load either the needed modules like google does or dynamically load from a common url. Btw, I am not aware whether it violates the gadget spec. Just a thought.

[1] http://www.w3schools.com/jsref/dom_obj_all.asp [2] http://www.w3schools.com/dom/dom_element.asp

-- Ruchira Wageesha Software Engineer - WSO2 Inc. www.wso2.com

Email: ruch...@wso2.com Blog: ruch...@blogspot.com Mobile: +94771083017

Lean . Enterprise . Middleware

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

This is a proposal for adding JCA support across Carbon platform.

0. Motivation

------------------ Integration of different systems is always a challenging task. The J2EE Connector Architecture (JCA)[0] simplifies the difficulties in integration by defining a common set of APIs. By complying with the JCA standard, an EIS (Enterprise Information System) vendor will ensure that its EIS will integrate with any Java based application server. In the same way Java application server vendor needs only ensure that the application server enabled for JCA connectivity. This way any JCA enabled application server can integrate with any JCA complaint EIS. EIS will implement the JCA complaint bride using a third software component called Resource adapter which will deploy in application server.

The primary aim is to allow Carbon to provide the infrastructure for hosting JCA complaint resource adapters.

1. Aims

----------- 1. Carbon should be able to provide infrasturre for deploying JCA Resource adapters. 2. A EIS such as Enterprise Resource Planning(ERS), Transaction Processing Monitor(TPM), Supply Chain Management (SCM), client will talk to Carbon (which has the relevant Resource adapters deployed) and will receive the connection and will communicate to EIS system through Carbon. 3. Carbon should be able to treat as a JCA complaint Application server which provide; - connection managment - security - transactions management 4. Example; Say a user deploy the SAP resource adapter into Carbon. So following task should be possible. a). Carbon should be able to communicate with the SAP system. b). A SAP Java client that need to talk to SAP system should be able to do that through Carbon (SAP Java client talks to Carbon which in terms talk to the SAP system).

2. What would Carbon users benefit from having JCA in-house?

------------------------------------------------------------------------------------------ Carbon can connect to any JCA complaint EIS providers (Siebel, SAP, Great Plains System, Oracle DB, Oracle JMS provider for example). See the attached diagram for a possible usage scenario.

3. How to implement?

------------------------------ A lightweight JCA server/runtime will be embedded into Carbon run time, and will be implemented as a feature for Carbon. This will let users to deploy various JCA complaint resource adapters into Carbon. JBoss JCA[1] and Jencks[2] are possible candidates. See below for a possible comparison.

3.1 IronJacamar(JCA from JBoss)

------------------------------------------------ 0. LGPL v2.1. 1. Implements JCA 1.6 spec. 2. Configurations is done via XML config file 3. Has three mode of operation; standalone, inside JBoss AS, Embedded 4. Tools support - validation, code generator 5. Comprensive documentation 6. Very active communitiy.

3.2 Jencks

---------------- 0. No much active - last released in 2007 1. Need to deploy inside Spring in order to provide Message Driven POJOs. 2. Didn't find much documentation

4. Programming model for JCA users of Carbon

---------------------------------------------------------------- Once a JCA components is integrated with Carbon, it can act as a JCA complaint server. Users will deploy resource adapters in Carbon and will program their client application against an EIS through Carbon. See the attached diagram.

5. Milestone plan

--------------------- Plan is to come up with a working module by end of September.

If you have any comments please share.

Rajika

[0] - http://java.sun.com/j2ee/connector/ [1] - http://www.jboss.org/ironjacamar [2] - http://docs.codehaus.org/display/JCA/Home

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

This is a proposal for adding JCA support across Carbon platform.

0. Motivation

------------------ Integration of different systems is always a challenging task. The J2EE Connector Architecture (JCA)[0] simplifies the difficulties in integration by defining a common set of APIs. By complying with the JCA standard, an EIS (Enterprise Information System) vendor will ensure that its EIS will integrate with any Java based application server. In the same way Java application server vendor needs only ensure that the application server enabled for JCA connectivity. This way any JCA enabled application server can integrate with any JCA complaint EIS. EIS will implement the JCA complaint bride using a third software component called Resource adapter which will deploy in application server.

The primary aim is to allow Carbon to provide the infrastructure for hosting JCA complaint resource adapters.

1. Aims

----------- 1. Carbon should be able to provide infrasturre for deploying JCA Resource adapters. 2. A EIS such as Enterprise Resource Planning(ERS), Transaction Processing Monitor(TPM), Supply Chain Management (SCM), client will talk to Carbon (which has the relevant Resource adapters deployed) and will receive the connection and will communicate to EIS system through Carbon. 3. Carbon should be able to treat as a JCA complaint Application server which provide; - connection managment - security - transactions management 4. Example; Say a user deploy the SAP resource adapter into Carbon. So following task should be possible. a). Carbon should be able to communicate with the SAP system. b). A SAP Java client that need to talk to SAP system should be able to do that through Carbon (SAP Java client talks to Carbon which in terms talk to the SAP system).

2. What would Carbon users benefit from having JCA in-house?

------------------------------------------------------------------------------------------ Carbon can connect to any JCA complaint EIS providers (Siebel, SAP, Great Plains System, Oracle DB, Oracle JMS provider for example). See the attached diagram for a possible usage scenario.

3. How to implement?

------------------------------ A lightweight JCA server/runtime will be embedded into Carbon run time, and will be implemented as a feature for Carbon. This will let users to deploy various JCA complaint resource adapters into Carbon. JBoss JCA[1] and Jencks[2] are possible candidates. See below for a possible comparison.

3.1 IronJacamar(JCA from JBoss)

------------------------------------------------ 0. LGPL v2.1. 1. Implements JCA 1.6 spec. 2. Configurations is done via XML config file 3. Has three mode of operation; standalone, inside JBoss AS, Embedded 4. Tools support - validation, code generator 5. Comprensive documentation 6. Very active communitiy.

3.2 Jencks

---------------- 0. No much active - last released in 2007 1. Need to deploy inside Spring in order to provide Message Driven POJOs. 2. Didn't find much documentation

4. Programming model for JCA users of Carbon

---------------------------------------------------------------- Once a JCA components is integrated with Carbon, it can act as a JCA complaint server. Users will deploy resource adapters in Carbon and will program their client application against an EIS through Carbon. See the attached diagram.

5. Milestone plan

--------------------- Plan is to come up with a working module by end of September.

If you have any comments please share.

Rajika

[0] - http://java.sun.com/j2ee/connector/ [1] - http://www.jboss.org/ironjacamar [2] - http://docs.codehaus.org/display/JCA/Home

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

This is a proposal for adding JCA support across Carbon platform.

0. Motivation

------------------ Integration of different systems is always a challenging task. The J2EE Connector Architecture (JCA)[0] simplifies the difficulties in integration by defining a common set of APIs. By complying with the JCA standard, an EIS (Enterprise Information System) vendor will ensure that its EIS will integrate with any Java based application server. In the same way Java application server vendor needs only ensure that the application server enabled for JCA connectivity. This way any JCA enabled application server can integrate with any JCA complaint EIS. EIS will implement the JCA complaint bride using a third software component called Resource adapter which will deploy in application server.

The primary aim is to allow Carbon to provide the infrastructure for hosting JCA complaint resource adapters.

1. Aims

----------- 1. Carbon should be able to provide infrasturre for deploying JCA Resource adapters. 2. A EIS such as Enterprise Resource Planning(ERS), Transaction Processing Monitor(TPM), Supply Chain Management (SCM), client will talk to Carbon (which has the relevant Resource adapters deployed) and will receive the connection and will communicate to EIS system through Carbon. 3. Carbon should be able to treat as a JCA complaint Application server which provide; - connection managment - security - transactions management 4. Example; Say a user deploy the SAP resource adapter into Carbon. So following task should be possible. a). Carbon should be able to communicate with the SAP system. b). A SAP Java client that need to talk to SAP system should be able to do that through Carbon (SAP Java client talks to Carbon which in terms talk to the SAP system).

2. What would Carbon users benefit from having JCA in-house?

------------------------------------------------------------------------------------------ Carbon can connect to any JCA complaint EIS providers (Siebel, SAP, Great Plains System, Oracle DB, Oracle JMS provider for example). See the attached diagram for a possible usage scenario.

3. How to implement?

------------------------------ A lightweight JCA server/runtime will be embedded into Carbon run time, and will be implemented as a feature for Carbon. This will let users to deploy various JCA complaint resource adapters into Carbon. JBoss JCA[1] and Jencks[2] are possible candidates. See below for a possible comparison.

3.1 IronJacamar(JCA from JBoss)

------------------------------------------------ 0. LGPL v2.1. 1. Implements JCA 1.6 spec. 2. Configurations is done via XML config file 3. Has three mode of operation; standalone, inside JBoss AS, Embedded 4. Tools support - validation, code generator 5. Comprensive documentation 6. Very active communitiy.

3.2 Jencks

---------------- 0. No much active - last released in 2007 1. Need to deploy inside Spring in order to provide Message Driven POJOs. 2. Didn't find much documentation

4. Programming model for JCA users of Carbon

---------------------------------------------------------------- Once a JCA components is integrated with Carbon, it can act as a JCA complaint server. Users will deploy resource adapters in Carbon and will program their client application against an EIS through Carbon. See the attached diagram.

5. Milestone plan

--------------------- Plan is to come up with a working module by end of September.

If you have any comments please share.

Rajika

[0] - http://java.sun.com/j2ee/connector/ [1] - http://www.jboss.org/ironjacamar [2] - http://docs.codehaus.org/display/JCA/Home

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi all,

Today we are reviewing exposing UM-API to tenants at 1.30PM.

thanks, dimuthul

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi Dimuthu,

When we do this, please send an invite to strategy@ and sanjiva so this appears in people's calendar.

--Srinath

p.s. pls add a invite to me as well, I am away this week though.

On Thu, Aug 25, 2011 at 11:38 AM, Dimuthu Leelarathne <dimu...@wso2.com> wrote:

Hi all, Today we are reviewing exposing UM-API to tenants at 1.30PM. thanks, dimuthul

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

-- ============================ Srinath Perera, Ph.D.    http://www.cs.indiana.edu/~hperera/    http://srinathsview.blogspot.com/

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Hi,

OpenStack is having an Amazon EC2 API but they've put more effort to the REST API. Support for SOAP API is said to be in the latest release but it's hard to figure out how complete it is without actually running it. We have to verify this by installing OpenStack and test the autoscaling stuff.

-Chintana

-- Chintana Wilamuna Associate Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware

phone: +94 75 211 1106 blog: http://engwar.com/ photos: http://flickr.com/photos/chintana linkedin: http://www.linkedin.com/in/engwar

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

ESB team any progress on $subject? Can you send a sample?

Sanjiva.

-- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 blog: http://sanjiva.weerawarana.org/

Lean . Enterprise . Middleware

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

*Plans for BAM 2.0 - M2 * * * Deadline - *Sep. 23* (tentative - accounting also for WSO2Con) * * - Scalable Analyzer framework - The analyzer tasks do not scale as machines are added. We have to evaluate the feasibility of Hadoop (or any other solution) and port the analyzer framework to that solution. - Rewrite gadget generation using Google Closure compiler & enrich with theming support and additional bar, pie charts - Multi node monitoring support with graph generation - Complete concrete impl. of new BAM data publishers - integrate support for CEP, multi node monitoring & measure performance - Discuss to implement composable CEP flows with CEP team - CEP Flow UI, Composable CEP connectors, operators and sinks, CEP Rule generation * * *Note:* At the end of M2, there should be distro that is complete with UIs, to download if needed. * * * * *Notes from BAM 2.0 - M1 - Demo*

Today we concluded, a successful demo of BAM 2.0 - M1.

Participants: Sanjiva, Sumedha, Deep, Tharindu, Kasun, Buddhika, Manu, Ruchira, Chanaka, Isuru, Sameera

Used slides are attached. The used demo setup is given in the slides. In short, Event Receiver Configs, Analyzer framework language and configuration for data manipulation, 12 generated gadgets and 2 alerts were shown in this demo.

*Features demonstrated* - Single & Multiple Node monitoring - Cassandra based Event persistence - Analyzer task framework - Re-usable analyzer tasks that can be used to compose data flows, poll 3rd party/WSO2 APIs for events, etc. - KPI & Alerting - Re-usable CEP flow components that can be used to compose CEP flows - Gadget generation - Gadget generation through a intuitive UI with "zero code" - Ability to monitor different carbon versions *Issues & Resolutions* - Cassandra disadvantages - Internal data structure manipulation to support different queries, affects queries for gadget generation - Acceptable for scalability and performance support - Tight coupling to Cassandra - Customer concerns for additional data stores or unfamiliar data stores - Cannot support relational model for that level of data storage. Abstracting out data store is not easy and may not be feasible

- Multiple node monitoring - Adhoc implementation, No standard for defining execution paths, topology, Use of work flow IDs - Use {from, to, data} from publishers to construct path graph. Users pr-configuring message paths is not feasible. - wso2vis drawbacks - No proper advantage of using wso2vis, slows down development wso2vis users will discuss this on @architecture to judge the future of wso2vis - Security - No standard mechanism for server-server authentication in Carbon, Can't use mutual SSL, Using UT not cheap, Option to use custom authenticator - not standard and affects 3rd party app integration No security OOTB. If security is needed, separate receiver to another Carbon server and apply mutual auth - Lack of Batch event API - Batch events are a huge performance boost for data publishers to counter network latency Let's not clutter the receiver by introducing a new API for batch eventing support.

- Lack of Integrated UI - New BAM is extremely configurable, but lack of a integrated UI steepens the learning curve and affects usability ToDo * *

-- Regards,

Tharindu

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Participants were Sanjiva, Samisa, Shanker, Azeez, Sumedha, Damitha

- ApplicationServer(AS) like Stratos product that can be used to host PHP, Python, Ruby scripting apps.

- PHP is not specific to WSF/PHP, but any php app like SugarCRM. WSF/PHP may act like an agent.

- Statically allocate tenants to some node and scale that node. See attached diagram. php.stratos.com/t/shanker/sugar php.stratos.com/t/azeez/sugar php.stratos.com/sugar

- Solution may be somewhat similar to Stratos database solution

- Use chroot for creating usage restricted environment for tenants. Note that chroot is for file restriction but not intended to restrict the use of resources like I/O, bandwidth, disk space or CPU time.

- Need to figure out how many Apache server processes we can run in a chroot environment in one instance. lightweight httpd like lighttpd?

- We need tenant aware load balancing. But that may not work out of the box currently.

- In EC2 we can create identical copy of an instance using API calls. We may use this to scale

- Do we need to incorporate tooling for PHP developers using CStudio?. But this may not be appealing to PHP developer community who are more inclined towards emacs, zend studio etc. Target customers could be varied from php fan who host his application for 30$ or enterprise. For enterprise CStudio may be good solution.

- A front end (FE) process to manage deployment to the php cloud. A separate machine could be used to host this. This could be like AS minus all AS related things. We can use this to control security, php deployment packs handling(eg. add, delete etc). Or we may only allow zip file uploading?. Or just give ftp access to tenants to deploy files?.

- Can FE be a Carbon component?

- For this FE we can use an existing java script gui ftp client.

- An interceptor(PHP module) to handle managed environment?

- LAMP packages preinstalled

- For logging use Syslog.

- We should not change PHP world way of doing things in our effort

Milestones:

M1: setup nodes with chrooted access without load balancing

M2: Incorporate LB

M3: Partitioning across tenants

M4: Do for Python, Ruby, Perl. Mono?

- Rough target would be to have this at the end of year for PHP

Please add to this or correct if I have missed anything. Thanks, Damitha

--

__________________________________________________________________

Damitha Kumarage Technical Lead; WSO2 Inc. "Oxygenating the Web Service Platform; " http://www.wso2.com/

blog: " http://damithakumarage.wordpress.com/

__________________________________________________________________

_______________________________________________ Architecture mailing list Arch...@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture