[Architecture] Endpoint Unification - Design and milestone plan

Wed Jun 9 02:49:23 EDT 2010

So I guess there are some registry specific stuff that has to stay in
the registry. So one possibility is that
adding registry specific things as properties to the endpoint.

Thanks
Srinath

On Wed, Jun 9, 2010 at 11:31 AM, Dimuthu Gamage <dimuthu at wso2.com> wrote:
> On Fri, Jun 4, 2010 at 9:21 AM, Senaka Fernando <senaka at wso2.com> wrote:
>> Hi all,
>>
>> Attached herewith a sample endpoint resource from the Registry. As you can
>> see, the content just has the endpoint URL. We have a property explaining
>> the transport (Dimuthu what does this exactly do?), and there are a few
>
> Hi Senaka,
>
> We store all the known details of the endpoint as properties.  If
> endpoints are added while adding wsdls, we will store the bound
> transport details. When the endpoint is added with service, the
> environment (whether is is Dev, QA, Test) are stored.
>
> Thanks
> Dimuthu
>
>> associations to the WSDL and Service artifacts that use this endpoint.
>>
>> Thanks,
>> Senaka.
>>
>> On Fri, Jun 4, 2010 at 6:36 AM, Srinath Perera <srinath at wso2.com> wrote:
>>>
>>> Hi Supun;
>>>
>>> I guess we can let users refer to a parts of the configurations
>>> externally, e.g. through registry keys. However, IMO we have to
>>> support embedded self contained configurations as well, because
>>> otherwise it will make the simple case complex. For example, if a
>>> client want to send a Endpoint to the server (e.g. take ODE
>>> orchestrating a service which has security and special http options),
>>> we want to let them send a one XML element, not a graph created out of
>>> references.
>>>
>>> Thanks
>>> Srinath
>>>
>>> On Thu, Jun 3, 2010 at 5:57 PM, Supun Kamburugamuva <supun at wso2.com>
>>> wrote:
>>> > On Thu, Jun 3, 2010 at 6:19 AM, Srinath Perera <srinath at wso2.com> wrote:
>>> >> Hi Supun;
>>> >>
>>> >> "If we can have this configuration as pluggable components that will be
>>> >> great"
>>> >>
>>> >> Could you explain what you mean by above bit more.
>>> >>
>>> >
>>> > My idea was in the lines of separating different functional components
>>> > that are optional or can be changed without changing the basic
>>> > semantics of the endpoint in to separate components. One this may be
>>> > to change transport specific things in to a different configuration.
>>> > For example we can have a separate HTTP transport specific
>>> > configurations and refer them from the endpoint.
>>> >
>>> > Or we can have a monitoring section separately and refer them from the
>>> > endpoint. This way we can share the same monitoring across different
>>> > endpoints. Or we can have a separate error handling section etc.
>>> >
>>> > Thanks,
>>> > Supun..
>>> >
>>> >
>>> >> In general, main idea is to use WS-EPR metadata tag to hold the
>>> >> additional endpoint data. Rest is basically we are trying to cleanup
>>> >> information presented through endpoint in different places and put
>>> >> them all one one information model.
>>> >>
>>> >> Thanks
>>> >> Srinath
>>> >>
>>> >> On Wed, Jun 2, 2010 at 7:24 PM, Supun Kamburugamuva <supun at wso2.com>
>>> >> wrote:
>>> >>> I went through the proposed endpoint configurations. My first
>>> >>> impression was it is quite complex and hard to understand. If we can
>>> >>> have this configuration as pluggable components that will be great.
>>> >>>
>>> >>> Thanks,
>>> >>> Supun..
>>> >>>
>>> >>> On Wed, Jun 2, 2010 at 7:06 PM, Senaka Fernando <senaka at wso2.com>
>>> >>> wrote:
>>> >>>> Hi all,
>>> >>>>
>>> >>>> G-Reg too has a concept of an endpoint in a WSDL. These are treated
>>> >>>> as
>>> >>>> separate resources. If we are looking forward for a unified
>>> >>>> implementation,
>>> >>>> shouldn't we consider that too?
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Senaka.
>>> >>>>
>>> >>>> On Tue, Jun 1, 2010 at 2:47 PM, Kasun Indrasiri <kasun at wso2.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Yes, we need to change the package name as well.In fact, what we
>>> >>>>> have in
>>> >>>>> components/endpoint is some endpoint serialization/ui stuff in ESB
>>> >>>>> but the
>>> >>>>> real endpoint implementation resides in
>>> >>>>> Synapse(org.apache.synapse.endpoints).
>>> >>>>> IMO, we can proceed with a different name other than existing ESB's
>>> >>>>> 'endpoint' for the initial milestones.
>>> >>>>>
>>> >>>>> On Mon, May 31, 2010 at 8:22 PM, Supun Kamburugamuva
>>> >>>>> <supun at wso2.com>
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>> On Mon, May 31, 2010 at 8:19 PM, Supun Kamburugamuva
>>> >>>>>> <supun at wso2.com>
>>> >>>>>> wrote:
>>> >>>>>> > On Mon, May 31, 2010 at 3:32 PM, Srinath Perera
>>> >>>>>> > <srinath at wso2.com>
>>> >>>>>> > wrote:
>>> >>>>>> >> Does ESB endpoint module disappear when other endpoint module
>>> >>>>>> >> has
>>> >>>>>> >> matured? If so we can rename the esb endpoint module to
>>> >>>>>> >> esb-endpoint
>>> >>>>>> >> and  name new one endpoint. I that possible? I think we have to
>>> >>>>>> >> only
>>> >>>>>> >> change the directory name in the parent pom to do that change,
>>> >>>>>> >> nothing
>>> >>>>>> >> else.
>>> >>>>>> >> WDYT?
>>> >>>>>> >
>>> >>>>>>
>>> >>>>>> Even if we change the folder name we need to think about the
>>> >>>>>> package
>>> >>>>>> names as well. So what is the package name of the new module? Is it
>>> >>>>>> org.wso2.carbon.endpoint? But this name is already taken by the ESB
>>> >>>>>> endpoints and we may need to change that as well.
>>> >>>>>>
>>> >>>>>> Thanks,
>>> >>>>>> Supun..
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> > +1
>>> >>>>>> >
>>> >>>>>> > Supun..
>>> >>>>>> >
>>> >>>>>> >> --Srinath
>>> >>>>>> >>
>>> >>>>>> >>
>>> >>>>>> >>
>>> >>>>>> >> On Mon, May 31, 2010 at 3:24 PM, Kasun Indrasiri
>>> >>>>>> >> <kasun at wso2.com>
>>> >>>>>> >> wrote:
>>> >>>>>> >>> Since we are going to implement Endpoint unification as an
>>> >>>>>> >>> independent
>>> >>>>>> >>> module, how are we going to name it under carbon components ?
>>> >>>>>> >>> The ESB's 'endpoint' module already exists under
>>> >>>>>> >>> carbon/components
>>> >>>>>> >>> and we
>>> >>>>>> >>> should have a name other than 'endpoint'.
>>> >>>>>> >>> WDYT?
>>> >>>>>> >>>
>>> >>>>>> >>> On Wed, May 26, 2010 at 6:49 PM, Srinath Perera
>>> >>>>>> >>> <srinath at wso2.com>
>>> >>>>>> >>> wrote:
>>> >>>>>> >>>>
>>> >>>>>> >>>> Following are bit more info about the implementation.
>>> >>>>>> >>>>
>>> >>>>>> >>>> Info in the Ednpoint instructs  how a client should invoke the
>>> >>>>>> >>>> service
>>> >>>>>> >>>> represented by the endpoint. That info, IMO falls into three
>>> >>>>>> >>>> categories.
>>> >>>>>> >>>>
>>> >>>>>> >>>> 1. Simple ones - they translates to simple properties set in
>>> >>>>>> >>>> the
>>> >>>>>> >>>> Axis2
>>> >>>>>> >>>> message context. They can be implemented through a Axis2
>>> >>>>>> >>>> Handler.
>>> >>>>>> >>>> 2. This category--e.g. security--needs the Axis2 execution
>>> >>>>>> >>>> chain to
>>> >>>>>> >>>> be
>>> >>>>>> >>>> modified as well. So the handler has to change the execution
>>> >>>>>> >>>> logic,
>>> >>>>>> >>>> hence need bit more careful code.
>>> >>>>>> >>>> 3. Finally, Handlers can not implement load balancing and
>>> >>>>>> >>>> fault
>>> >>>>>> >>>> tolerance. So we force the user to use "cluster:xxxx" in the
>>> >>>>>> >>>> address,
>>> >>>>>> >>>> which will forward executions to a Cluster transport, which
>>> >>>>>> >>>> does the
>>> >>>>>> >>>> LB or FT code as needed. by calling transports of endpoints
>>> >>>>>> >>>> listed
>>> >>>>>> >>>> for
>>> >>>>>> >>>> the cluster. One thing to note is that, before sending, the
>>> >>>>>> >>>> cluster
>>> >>>>>> >>>> transport must build the OMEnvelope so that it can be replayed
>>> >>>>>> >>>> if
>>> >>>>>> >>>> required.
>>> >>>>>> >>>>
>>> >>>>>> >>>> So the milestones are arranged according to three categories.
>>> >>>>>> >>>>
>>> >>>>>> >>>> Thanks
>>> >>>>>> >>>> Srinath
>>> >>>>>> >>>>
>>> >>>>>> >>>> On Wed, May 26, 2010 at 2:21 PM, Kasun Indrasiri
>>> >>>>>> >>>> <kasun at wso2.com>
>>> >>>>>> >>>> wrote:
>>> >>>>>> >>>> > Hi all,
>>> >>>>>> >>>> > Based on the 'Endpoint Unification' proposal[1] we are
>>> >>>>>> >>>> > planning to
>>> >>>>>> >>>> > start
>>> >>>>>> >>>> > the
>>> >>>>>> >>>> > implementation of the Endpoint Unification concept.
>>> >>>>>> >>>> > Endpoint Unification model basically extends form
>>> >>>>>> >>>> > WS-Addressing
>>> >>>>>> >>>> > Endpoint
>>> >>>>>> >>>> > in
>>> >>>>>> >>>> > WS-Addressing specification [2] and therefore it won't break
>>> >>>>>> >>>> > the
>>> >>>>>> >>>> > existing
>>> >>>>>> >>>> > Web Service APIs that uses WS-Addressing Endpoint Reference
>>> >>>>>> >>>> > model.
>>> >>>>>> >>>> > Since
>>> >>>>>> >>>> > the
>>> >>>>>> >>>> > new Endpoint Information Model should be able to represent
>>> >>>>>> >>>> > any
>>> >>>>>> >>>> > kind of
>>> >>>>>> >>>> > Endpoint in our platform, we need to verify that this
>>> >>>>>> >>>> > generic
>>> >>>>>> >>>> > model
>>> >>>>>> >>>> > addresses all the scenarios (such as Load Balancing, Fail
>>> >>>>>> >>>> > Over
>>> >>>>>> >>>> > etc)
>>> >>>>>> >>>> > where
>>> >>>>>> >>>> > the Endpoints are used.
>>> >>>>>> >>>> > As the initial step we prefer to implement Endpoints as an
>>> >>>>>> >>>> > independent
>>> >>>>>> >>>> > carbon component and later we can convert/wrap the existing
>>> >>>>>> >>>> > Endpoints
>>> >>>>>> >>>> > with
>>> >>>>>> >>>> > the new Unified Endpoint. (When it comes to Endpoints in ESB
>>> >>>>>> >>>> > for
>>> >>>>>> >>>> > instance, I
>>> >>>>>> >>>> > think, we should support the existing format and internally
>>> >>>>>> >>>> > we can
>>> >>>>>> >>>> > wrap
>>> >>>>>> >>>> > that
>>> >>>>>> >>>> > with new Endpoint representation).
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > Once we've finalized the Information Model, we are planning
>>> >>>>>> >>>> > to
>>> >>>>>> >>>> > start the
>>> >>>>>> >>>> > implementation(by this week) and here is the draft milestone
>>> >>>>>> >>>> > plan:
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > Milestone Plan
>>> >>>>>> >>>> > M1
>>> >>>>>> >>>> > - Write a schema for the formats
>>> >>>>>> >>>> > - Support serialization/building of Unified Endpoints and
>>> >>>>>> >>>> > support
>>> >>>>>> >>>> > storing
>>> >>>>>> >>>> > end retriving endpoints (registry)
>>> >>>>>> >>>> > - Write a custom UI for endpoints. (Initial UI component
>>> >>>>>> >>>> > would
>>> >>>>>> >>>> > address
>>> >>>>>> >>>> > the
>>> >>>>>> >>>> > basic requirements only)
>>> >>>>>> >>>> > - Implement a transport which support options other than
>>> >>>>>> >>>> > security.
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > M2
>>> >>>>>> >>>> > - Add secuirty support (need to engage security handlers
>>> >>>>>> >>>> > from
>>> >>>>>> >>>> > Endpoint
>>> >>>>>> >>>> > Handler)
>>> >>>>>> >>>> > - Write a transport to support load balancing and failover
>>> >>>>>> >>>> > usecases
>>> >>>>>> >>>> > - Write a transport that support discovery scenario by name
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > ...
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > [1]
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > https://docs.google.com/a/wso2.com/Doc?docid=0AcUIlB9H3rv_ZGQ2Nnp6c3BfMjNoazkzdDRkcg&hl=en
>>> >>>>>> >>>> > [2] http://www.w3.org/Submission/ws-addressing/
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > Regards,
>>> >>>>>> >>>> > --
>>> >>>>>> >>>> > Kasun Indrasiri
>>> >>>>>> >>>> > Senior Software Engineer
>>> >>>>>> >>>> > WSO2, Inc.; http://wso2.com
>>> >>>>>> >>>> > lean.enterprise.middleware
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > cell: +94 71 536 4128
>>> >>>>>> >>>> > Blog : http://kasunpanorama.blogspot.com/
>>> >>>>>> >>>> >
>>> >>>>>> >>>> > _______________________________________________
>>> >>>>>> >>>> > Architecture mailing list
>>> >>>>>> >>>> > Architecture at wso2.org
>>> >>>>>> >>>> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>>>>> >>>> >
>>> >>>>>> >>>> >
>>> >>>>>> >>>>
>>> >>>>>> >>>>
>>> >>>>>> >>>>
>>> >>>>>> >>>> --
>>> >>>>>> >>>> ============================
>>> >>>>>> >>>> Srinath Perera, Ph.D.
>>> >>>>>> >>>>   WSO2 Inc. http://wso2.com
>>> >>>>>> >>>>   Blog: http://srinathsview.blogspot.com/
>>> >>>>>> >>>>
>>> >>>>>> >>>> _______________________________________________
>>> >>>>>> >>>> Architecture mailing list
>>> >>>>>> >>>> Architecture at wso2.org
>>> >>>>>> >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>>>>> >>>
>>> >>>>>> >>>
>>> >>>>>> >>>
>>> >>>>>> >>> --
>>> >>>>>> >>> Kasun Indrasiri
>>> >>>>>> >>> Senior Software Engineer
>>> >>>>>> >>> WSO2, Inc.; http://wso2.com
>>> >>>>>> >>> lean.enterprise.middleware
>>> >>>>>> >>>
>>> >>>>>> >>> cell: +94 71 536 4128
>>> >>>>>> >>> Blog : http://kasunpanorama.blogspot.com/
>>> >>>>>> >>>
>>> >>>>>> >>
>>> >>>>>> >>
>>> >>>>>> >>
>>> >>>>>> >> --
>>> >>>>>> >> ============================
>>> >>>>>> >> Srinath Perera, Ph.D.
>>> >>>>>> >>   WSO2 Inc. http://wso2.com
>>> >>>>>> >>   Blog: http://srinathsview.blogspot.com/
>>> >>>>>> >>
>>> >>>>>> >> _______________________________________________
>>> >>>>>> >> Architecture mailing list
>>> >>>>>> >> Architecture at wso2.org
>>> >>>>>> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>>>>> >>
>>> >>>>>> >
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Kasun Indrasiri
>>> >>>>> Senior Software Engineer
>>> >>>>> WSO2, Inc.; http://wso2.com
>>> >>>>> lean.enterprise.middleware
>>> >>>>>
>>> >>>>> cell: +94 71 536 4128
>>> >>>>> Blog : http://kasunpanorama.blogspot.com/
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Architecture mailing list
>>> >>>>> Architecture at wso2.org
>>> >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Senaka Fernando
>>> >>>> Associate Technical Lead
>>> >>>> WSO2 Inc.
>>> >>>> E-mail: senaka AT wso2.com;  Mobile: +94 77 322 1818
>>> >>>>
>>> >>>> http://www.wso2.com/ - "Lean . Enterprise . Middleware"
>>> >>>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Architecture mailing list
>>> >>> Architecture at wso2.org
>>> >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> ============================
>>> >> Srinath Perera, Ph.D.
>>> >>   WSO2 Inc. http://wso2.com
>>> >>   Blog: http://srinathsview.blogspot.com/
>>> >>
>>> >> _______________________________________________
>>> >> Architecture mailing list
>>> >> Architecture at wso2.org
>>> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> ============================
>>> Srinath Perera, Ph.D.
>>>   WSO2 Inc. http://wso2.com
>>>   Blog: http://srinathsview.blogspot.com/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture at wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>>
>> --
>> Senaka Fernando
>> Associate Technical Lead
>> WSO2 Inc.
>> E-mail: senaka AT wso2.com;  Mobile: +94 77 322 1818
>>
>> http://www.wso2.com/ - "Lean . Enterprise . Middleware"
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture at wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>

-- 
============================
Srinath Perera, Ph.D.
   WSO2 Inc. http://wso2.com
   Blog: http://srinathsview.blogspot.com/