This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 142975 - CASA Editor supporting dummy endpoints + provide relational information between endpoints and messagetype(with operation)
Summary: CASA Editor supporting dummy endpoints + provide relational information betw...
Status: NEW
Alias: None
Product: soa
Classification: Unclassified
Component: Composite Application (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Venkat Chellasamy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-05 22:34 UTC by Sreenivasan Genipudi
Modified: 2008-08-05 23:00 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sreenivasan Genipudi 2008-08-05 22:34:01 UTC
In POJO SE perspective  we have the following requirements for CASA Editor and comp. app .

   1) Ability to connect consumer and provider in CASA Editor even when interface name does not match.

    Scenario:  In POJO Service the user may consume a service without knowing actual endpoints / interface name. POJO 
    service is message oriented and does not require WSDL. The POJO service to consume another service may use a dummy
endpoint.
    
    The service unit jbi.xml will have that dummy endpoint as consumer. The connection between the dummy consumer and actual
    provider will happen using CASA editor.

    In current version  the interface name between consumer and provider must match for a connection to happen in CASA
editor.  
    This needs to  be relaxed for the above scenario to work.  CASA editor needs to support dummy endpoints.
    
	
    If POJO Service unit and CASA Editor has some kind of contract for dummy endpoints, POJO SU can use those dummy
endpoints 
    for consumer in jbi.xml. CASA Editor can then allow linking provider and consumer. The dummy endpoint naming
convention which 
    can be used for the contract should be valid as per the JBI spec.
    

  2) Comp. app providing the relation between Endpoint and Message type ( with  Operation)   to POJO Service unit.

      Assuming requirement  1) is supported, POJO SE needs to know the message type of the consuming service to invoke
the service.
      POJO project is WSDL agnostic. It is purely message oriented and will not package the WSDL in service unit. 
      
      Comp. app seems to be reading  wsdls for providers while building. It would be helpful if  comp. app can provide the 
      mapping between the consuming dummy endpoint and  messagetype ( with operation) information to POJO Service unit.
      
      something like - compappmapping.xml
       
     <compapp:mappings xmlns:compapp="http://compapp.sun.com/mapping" >
     <compapp:mapping
 	  xmlns:myns="http://myworkspace" type="myns:mymsgtype" endpoint-name="DummyEndpoint1"
interfaceName="DummyEndpointPT1" serviceName="DummyServiceS1" 
 	  interfaceNS="http://DummyEndpointNS1" serviceNS="http://DummyEndpointNS1"
operationNS="http://actualoperationnamespace" operationName="actualOperation1"
 	  />
 	  
     <compapp:mapping
 	  xmlns:myns="http://myworkspace" type="myns:mymsgtype2" endpoint-name="DummyEndpoint1"
interfaceName="DummyEndpointPT1" serviceName="DummyServiceS1" 
 	  interfaceNS="http://DummyEndpointNS1" serviceNS="http://DummyEndpointNS1"
operationNS="http://actualoperationnamespace" operationName="actualOperation2"
      />
 	  
     </compapp:mappings >