ServicesTabArchitecture

Services Tab Architecture

Modification History:

  • Feb 2, 2007 - Winston Prakash
  • Mar 20, 2007 - Added comments / feedback. - Sanjay Dhamankar


Aim: To bring back the Servers Tab (may be renamed as Services Tab, since it may not have nodes for deployment servers, which would be in the run time tab itself), to provide migration path for Creator 2U1 users, who are familiar with the concept of drag and drop for the Servers Tabs on to components in the designer to bind the data from a particular service (Ex JDBC table ) to the component.

Goal: Make the drag and drop from Servers tab generic such a way that it should be usable not only by Visual Web pack modules, but also by other modules in the IDE.

Contents


Introduction

Services tab could be considered as a repository of services from which user can add the services to the application they are working. Conceptually the services tab could be divided into three parts

A Service Producer that consists of

  • An UI (global to IDE) for user interaction to add, delete, modify and explore the contents of a service.
  • A model (global to IDE) that controls and persists the actual data corresponding to the services displayed in the UI.
  • A local storage to store service information for later consumption

A Service Consumer that consists of

  • Receiving agent (Ex. designer or JSP editor) that receives the DnD from the UI.
  • Helper - An optional abstraction that helps the receiving agent to convert the received DnD to an useful object that can be consumed by the receiving agent.

A Producer-Consumer contract

  • A Contract between the receiving agent and the UI.
  • A Contract between the receiving agent and the model.

Service fetcher interface

  • An interface through which services can be fetched from a provider and get added to the services store.

Service export/import

  • A facility provided by the Service Manager to export or import the service information stored in the service store

Naming Convention

In order to understand the architecture, the following nomenclature are used

  • Service UI - The nodes that appear in the services tab via which the user can interact and initiate DnD.
  • Service Manager - The controller and the model behind the Service UI.
  • Service Store - The local persistence store where the service Manager stores the services information.
  • Service Client - The receiving agent that consumes the DnD from Service UI
  • DnD Contract - The contract that explains the contents of the DnD Transferable (Data Flavors & transfer data etc)
  • Service Contract - The API that allows the Service Consumer or Helper to create the necessary objects from the DnD.
  • Service Helper - An optional utility that helps the Service Consumer and talks to the Service Manager to convert the DnD contents to some useful objects understood by the Service Consumer.
  • Service Producer module - Module (or set of modules) that provides the Service UI, Service Manager, DnD Contract and the Service Contract.
  • Service Consumer Module - Module (or set of modules) comprises of Service Consumer and/or Service Helper.
  • Services API - The interface used by the Service Manager to automatically obtain the services from external providers and add them to the Service Store.

Services UI

The Services Tab Top Component would provide the container for the root nodes of the Services. The root nodes and its sub nodes provides actions for user interaction For example, if it is a Webservices node, then user may be able to add a web service, test a web service method and then explore the W/S to see its method signature.

The expected way to add root nodes to this container is via layer file. The Service Producer Module would implement the root nodes and add it to this container via layer file. As an example, to add the EJBs, the EJB Service Producer Module module would add the EJB root node as

<folder name="UI">
   <folder name="Runtime">
      <file name="org-netbeans-modules-visualweb-ejb-nodes-EjbRootNode.instance" 
                    url="org-netbeans-modules-visualweb-ejb-nodes-EjbRootNode.instance"/>
   </folder>
</folder>

See Also:

The root node should minimally provide the following functionality

  • Add Service
  • Remove Service
  • Modify Service
  • Refresh Service
  • Group Services

Service manager (Global to IDE)

The Service Manager is the model and controller behind the UI. For example, when the user initiates an action in the UI to add a Service, the UI interacts with the Service Manager to added the service to the Persistence Store. Later, after receiving the DnD, the Service client or Service Helper could obtain the relevant service information from the persistence store through this Service Manager to convert the DnD information in to desirable objects to be added to the project. The Service Manager is specific to each service type. It is implemented by the Service Producer module.

Service Store (Global to IDE)

The local storage where the Service Manager stores the information about the Service. For example, when a Web Service is added via the UI, the Web Service Manager can store the following in the user directory

<user-dir>  
     - websvc
          - JavaTravellerService.wsdl
          - JavaTravellerService.jar 
          - JavaTravellerServiceDesigntime.jar

Issues: In order to minimize the time between the drop of DnD and the corresponding binding to appear in the designer, the W/S proxy client is created and zipped as jar and also the design time jar is also generated when the W/S is added in the UI. This may note be required by other Service Consumer module. For example some project type may want to create the client proxy when the W/S is actually added to the project. Additionally the some service persistence (Ex JavaTravellerServiceDesigntime.jar), may be required only by specific Service Consumer Module, in this case VWP.

Would the solution be to provide the option for the Consumer modules also to participate in the service adding process via lookup. The Consumer Modules can implement an extension of Service Manager (as NB service). Service manager can look up this extended service and call them to create additional storage support required by these service consumer modules.

Ex.

Interface WsServiceManagerExtension{
  public boolean wsServiceAddedExtension(File wsServiceLocation, WsService ws);
  public boolean wsServiceRemovedExtension(File wsServiceLocation, WsService ws);
}

The Consumer Module like VWP W/S service consumer implements the extension as

public final class VwpWsServiceManagerExtensionImpl implements WsServiceManagerExtension{
    public boolean wsServiceAddedExtension(File wsServiceLocation, WsService ws){
         // Create the client jar if needed (if not found in the location)
         // Create the design time jar in the wsServiceLocation if needed
         return true; // false if creation failed
    }
} 

Now, the additional step taken by Web Serice Manager while adding the service is

public final class  WsServiceManager{
   public boolean addWebService(WsService ws){
       // Add the W/S to location wsLocation
       ...
       // Call the W/S add extensions
       WsServiceManagerExtension[] wsmExts = Lookup.lookup("WsServiceManagerExtension");
       for (for int i = 0; I < wsExs.lenght; i++){
            wsmExts[I].wsServiceAddedExtension(wsLocation, ws); 
       }
       fireWebServiceAdded(ws);
   }
...
}

See Also:

Service Client

This is the receiving agent of the DnD initiated by the user from the UI. Examples of Service Clients are JSP page or Visual Web designer. When the DnD is received y the Service Client, it can consume it directly by extracting the info in the DnD using the DnD Contract and creating the relevant consumable client object or pass the DnD to a Service Helper and get back the consumable client object.

Let us see an example how how Visual Web Pack web designer (here after just designer) consumes the Database dropped on to the designer. When the designer does not creates the consumable object. The consumable object is called BeanCreateInfoSet (a generic definition of consumable object holder defined by the VWP Design Time System). The designer could implement the required code to convert the DnD to an BeanCreateInfoSet. That means designer needs to understand the DnD contract defined by various Service Manager. This impractical, if not impossible.

The solution would be to use a Service Helper and pass on the DnD Transferable to it. The Service Helper would take the DnD and creates the BeanCreateInfoSet and gives it back to the designer. The advantage of this approach is, designer need not have to know about the DnD Contract nor the Service Contract to convert the DnD Transferable to a consumable object, but relies on the Service Helper to do the job.

This allows to implement Service Consumer Modules independent of Service Client. The Service Helper will be the part of Service Consumer Module. Since there could be multiple Service Clients (VWP designer, JSP editor), there could be multiple Service Consumer Modules and again one for each type of service. For example VWP could implement, VWP specific Web Service consumer module or EJB consumer module.

One more problem need to be addressed here. If there are multiple Consumer Service Modules (one for each type), then the Service Client (ex. VWP designer), need to interact with each of these modules. VWP has solved this by defining a single wrapper consumable object through design time API and relies on NB lookup mechanism to pass the DnD transferable to the Service Helper.

Here is an Example interface that could be defined by the Service Client (VWP designer)

public interface VwpServiceHelper{
  ConsumableObject getConsumableObject(Transferable trans);
}

The Service Consumer Module can implement the VWP specific Service Helper and register it

public final class VwpServiceHelperImpl implements VwpServiceHelper{
   ConsumableObject getConsumableObject(Transferable trans){
      // Use the DnD contract to get the info about service
      // If the transferable is not understood (may not be a W/S service DnD)
      // return null
      // Use the Service contract to get ServiceProxy
       new ConsumableObject(service_proxy);
   }
}

The VWP Service Client (designer) obtains the Consumable Object as

public final class  VwpWebDesigner{
    ....
   public boolean handleDnD(Transferable trans){
        
       // Call the VWP Service Helper to get the consumable object
       VwpServiceTransferHelper[] vwpHelpers = Lookup.lookup("VwpServiceTransferHelper");
       ConsumableObject consObj;
       for (for int i = 0; I < wsExs.lenght; i++){
            consObj = vwpHelpers[I].getConsumableObject(trans); 
            if (consObj!= null) break;
            // Continue to ask other Helper if they understand the Transferable
       }
       If (consObj != null){
          // Ok we got a consumable object, consume it now
       }else{
          // OOPS sorry, I can't consume this Transferable
       } 
    }
...
}

The above design would help to keep the Service Consumer Modules independent of the Service Client. But it is not mandatory and it is up to the Service Client developers to implement one or not.

See Also:

Drag and Drop Contract

The Service Producer Module must publish the contract explaining the contents of the Transferable, Data Flavors etc. This information is used by the Service Helper (or by the Service Client as explained above). Here is an example of DnD Contract published by database service module. The TableInfo class is sent as Transfer data

public final class DatabaseMetaDataTransfer 
  public static DataFlavor TABLE_FLAVOR;
  public static final class TableInfo{
     private final DatabaseConnection dbconn;
     ...
  }  
} 

The Database Service Consumer can now obtain the TableInfo from the DataFlavor as follows.

    DataFlavor supportedFlavor = DatabaseMetaDataTransfer.TABLE_FLAVOR;
    if (transferable.isDataFlavorSupported(supportedFlavor)){
        transferData = transferable.getTransferData(supportedFlavor);
            DatabaseMetaDataTransfer.TableInfo tableInfo =  
                (DatabaseMetaDataTransfer.TableInfo) transferData;
            // Obtain the database connection from the 
            DatabaseConnection dbConnection = 
                (DatabaseConnection)tableInfo.getDatabaseConnection();
            // Now use DatabaseConnection as needed
        }
    }

The DatabaseConnection is one the Service Contract APIs published by the Service Producer module

Service Contract

The Service Producer module also must publish set of API for the Service Consumer Modules to get relevant information about the Service, and to work with the data in the Service Store.

For example, Database Service module publishes public API, whose implementation could be reached via the DnD contract as explained above

public interface DatabaseConnection {
     public String getDriverClass(); 
     public String getDatabaseURL(); 
     public String getPassword(); 
     public String getUser();
}

The Service Helper could create a DataSource object (a consumable object by the Service Client) from the DatabaseConnection and add it to the project or inject the relevant source to the JSP.

See Also:

Services API

Even though the Services Producer, provides the information about the services in its store, by itself it does not know how to fetch the services and add it to the store. User need to explicitly add the service via the UI in to the store. The services added to the store will be reflected in the UI.

Enterprise group is proposing an API called Services API. This API can be used by the service producer to fetch the services from the provider such as Service provider project (Ex. Webservice being created in a project) or Application Server


Summary

Services Tab

  • This is the first level abstraction, a simple UI container, which in turn is nothing but an explorer.
  • The public contract to add the top level nodes to this explorer is via a folder in the layer.
  • The implementation of Services Tab UI is simple and it knows nothing about any Services being added it.
  • It just displays the nodes added to it via the folder in the layer file.
  • Provides facility to start the DnD of nodes from the explorer.


Services

The second level abstraction is the services level which are getting added to this services tab. This abstraction can be defined in terms of "Producer - Consumer" design pattern. Basically divided in to two parts.

Part1 (producer)

  • Creates the Root nodes for the Services Tab and defines all the interaction with UI (add, remove, modify etc)
  • Saves the metadata about the services and also providing facilities such as export/import.
  • Global to IDE and knows nothing about how the services will be consumed by projects etc.
  • There will be one producer per service and knows nothing about each other

For example, think of Database Explorer Node, runtime tab doesn't know anything about this node per se, since it was defined in the layer file runtime tab just adds it to the runtime Explorer. However, DB Node provides all the functionalities for user interaction and saves the meta information about the database connection etc in the local store.

Part2 (consumer)

  • The actual consumer of the services.
  • Knows nothing about how the services are being managed by the producer.
  • Just gets the service information in the Transferable (via public DnD contract) (if added by DnD)
  • Gets the actual service (ex client proxy jar for W/S) or metadata (may be just url for WSDL) from the producer and consumes it (via service metadata contract)
  • There can be multiple consumer for each service type (VWP designer or JSP editor)
  • Implementation of consumer is independent of producer and could be project specif
  • Implementation of different consumers are independent of each other
 (VWP dataconnectivity knows nothing about  how Matisse consumes the  database table)

Think of dataconnectivity module in VWP as the consumer. It does not know anything about Database Explorer Node implementation, its UI interaction or how it stores the metadata about connections etc. But it knows how to get the table information from DB Node (producer) and consumes it. For this it need to interact with producer via DnD & Service Metadata contract.

DnD & Service Metadata contract

As an example again think of how both VWP and Matisse (both different consumers) could consume the same service (database table) from DB Explorer Node. This is because of the information about table in the Transferable is exported by the producer as public DnD contract .

Once the table information is obtained from the Transferable (using DnD contract) by the consumer, the actual connection information from the producer is obtained via Service Metadata Contract (Example Database Connecton API exported by DB Explorer). Once this is done, now the actual consumption is done differently by both consumers. Creator dataconnectivity module (a Service Helper for designer), converts it in to a dataprovider for components in the designer to consume. Matisse converts the connection info in to a JPA entity and consumes it via beans binding.

To reiterate

  • Services Tab is a visual representation of a centralized repository of Metadata corresponding to various services or resources.
  • Producers are the keepers of these metadata.
  • Producers export Metadata Contract (API) to allow access to the repository.
  • Consumers use these Metadata Contract to read from or write to this repository.
  • Users can add Service Metadata via Node Actions in the Services Tab and drag and drop them on to their project.
  • Consumer may provide other visual ways (dialogs populates with services obtained via Contract API), to allow user to pick certain services to add to their project.

Feedback and Comments

From Chris Webster and Srividhya Narayanan :

  • The expectations is to support drag and drop (somewhat similar to the palette); however, unlike the palette the contents of the services tab is fixed. For example, the BPEL editor may only want to show artifacts which can be consumed directly (WSDL documents). Other services which require indirect consumption should be optionally displayed to reduce the trial and error discovery required by the user for what services can be consumed.

Winston Prakash : As per the Services Tab design, the producer (here the W/S node) should not enforce how the consumer (here BPEL editor) would consume the service. If it requires to operate only WSDL, then it should get only the WSDL from the producer and operate on it. Note, as per the design the consumer also gets a chance to participate in how the meta-data will be stored for its later consumption. Producer required to store only the least common factor required by most of he consumers. It may be possible to selectively hide/show services tab. But that should be designed carefully to avoid user distraction.

Chris Webster:Perhaps if the focused window were able to select the types of services it could consume, the number of services would be reduced for views which definitely could not consume some services. The potential problem here is that some confusion may arise for windows which can consume only a subset of available services. A user could get used to dragging and dropping whatever is available from the service tab, but why show services not consumable in the current view.

Frank Kieviet: It appears an issue is that the services tab is not really a tab that can be reused for all editor types, but more of a palette that is specific for each editor type. In that case, each editor type will show only the set of services that it can handle.

_Winston Prakash_:As per my design (borrowed from Creator), Services Tab is not context sensitive, but a centralized repository where "services" can be hosted for consumption by applications developed in the IDE. However, looks like that design may not be enough as different requirements are being brought by other groups.


Winston Prakash :We could provide context sensitive view of the nodes. But how to let know the view to filter out the W/S based on a certain context. Unlike Palette which is predefined in the layer file, Services can be added arbitrarily by the users. Looks like proving the view also need to be moved to the consumer side. i.e the producer will have the repository of the W/S and based on the consumer context, the W/S need to be filtered out by the consumer and then create a view (root node) and give it to the Services Tab to display it. Sigh!, getting more complicated  :-( Another option is grouping. The view provides grouping of W/S. Assuming we could group W/S that would be consumed by BPEL editor under "BPEL W/S" or something like that.

  • Currently in the UI spec, I see a wizard to add services; how would services already available on the known servers be displayed?

Winston Prakash :As we discussed, currently user manually types in the URL. But as you mentioned we could use some API (services API? ) for this purpose for automatic discovery by pointing to a particular server.

  • The Services name may be confusing and make it somewhat difficult to discover the functionality for non creator users. Is there a more generic term that may make sense ?

Winston Prakash :In Creator this tab was called "Servers". During a brain storming session during NB visit, the name "Services" came up. But it is not necessary that we should stick to that name. I'm open for any suitable name.

  • The web service core team is currently implementing the service api for EE type projects. The responsibility for providing the service api discovery features through the AS plugin is out of scope for this effort. The owner for the implementation of this piece needs to be identified.

Winston Prakash :Hmmm.. this is one reason for NB 6.0 we may not have auto discovery feature in the add W/S dialog as mentioned above. Chris Webster:We should also attempt to encompass the JBI runtime environment as well, if possible.

  • The service tab is specifying only Network available resources (i.e., those which are already deployed and have a stable API/interface). For example, what is the expectation for a Web module which uses a web service which are both deployed together. The workflow of deploying and then getting the URL becomes problematic in this scenario as the development is blocked until the service is deployed. This also prevents a problem as the URL for the deployed service is not stable (this is local to the developers machine and will likely change on production deployment).

Petr Jiricka : The same comment applies to EJBs. Typically, both an EJB and its client will be deployed together, so having to first deploy the EJB to be able to consume it is cumbersome and clumsy. Services Tab architecture does not enforce, any such restrictions. It provides an infrastructure to host services in a known place. It is up to the service producer (W/S nodes or EJB nodes) to provide the desirable functionalities.

Winston Prakash :We have to look at three scenarios of adding W/S or EJB - Manually adding using a dialog - Automatically discover from a Server

(Ex. When a Server added to the IDE at run time tab)

- W/S or EJB currently being developed in the IDE itself First one is a no brainer. Creator already has that functionality. For latter two we need some kind of interface. AFAIK, no such interface exists. If any such interface exists, I don't see a reason why we should force deployment first (from the project being developed) to consume it.I know J2EE project finds the EJB or W/S project and able to add the corresponding EJB or W/S to the project. If that functionality can be converted in to a proper interface (like the Services API proposed by enterprise team), then the EJB manager of EJB root node in the Services Tab could use that for discovering and adding the EJB to the Services Tab.


Winston Prakash : Think of palette as a infrastructure provider. VWP adds the Palette Items and Matisse adds the palette items. But palette infrastructure is unaware of what these palette items would do, how they will be consumed by the VWP or Matisse. But using some known interface it just gets the components, their name, icon and display in its UI. Same way Services Tab is an infrastructure. It is up to the implementor of the Web Services nodes to do what ever they want. It provides an explorere where the "Services" root nodes are added. Services Tab, simply defines an uniform and expected way of interaction among Service producers and consumer. It does not dictate how these producers and consumers need to be implemented. Just like palette does not dictate what the palette item must do and the how they should be consumed, just provides a known place to find the palette items

Chris Webster:I think this goes back to the idea of service tab context, some services may only be available in certain contexts.

  • What is the relationship with the Enterprise Resource (and call web service) features of NetBeans ? Should these wizards display only things available from the service tab? Also, how would JMS fit in?

Winston Prakash : Again it depends on how you design the wizard and how you want to interact with W/S manager (to interact with W/S nodes) I would imagine, the wizard would display a drop down list of available W/S from Services Tab W/S node and also provision to add new WSDL. This is very similar to adding JDBC datasource to a web application. Either you create a datasource from existing connections in the runtime tab or user can enter new connection parameters.

  • One potentially common use case we were considering in EP was the ability to provide a resource project (XML library project). This project would provide the ability to store common artifacts (non java) such as XML Schema and WSDL which could be shared between projects as well as developers. One potential synergy here would be the ability to discover and create service tab contents in some form that could be version controlled and shared. This would reduce the need for each developer to run a wizard to add the data sources. This would be a potential alternative to the import export services.

Winston Prakash : This is entirely up to this module. Create the needed root node and just add it to the Services Tab, via the known interface. Services Tab will be blissfully unaware of what new "Service" what this newly added entity would do.

From Petr Pisl :

Service Tab Architecture document:

  • You wrote about DnD support for the Service Tab, which is typical for palette items. There will be as well text editor as consumers of the services. Basically I can do in the Project Tab (Navigator and other tabs) almost everything via keyboard. If I'm writing a jsp file or java file and I want to use just keyboard.

Winston Prakash: DnD is just one way. Not a must. In Creator we gave Keyborad access also (Ex. Add To From menu item). Service Node implementation must be flexible enough to support other scenarios.

  • Versioning Support - how it will work? I have a projects, which consumes WS or EJB from Services Tab, in a VCS. How other people will work with such project? What is the expected user flow? I know there is an Export / Import functionality for WS / EJB, but it doesn't cover the VCS usecase.

Winston Prakash:IMO, it is implementation dependent. For Creator when the W/S or EJB was added to the project, the proxy jar was added to the project, so the project was self contained and can be put in the VCS. Export/Import is to share the metadata about the service in the user-dir with other users.

  • In the Sevice Store chapter, you wrote that the Consumer Modules can implement an extension of Service Manager to create additional storage support required by service Consumer Module. But how this functionality will be handled in the case, when the Consumer Module is installed after adding the service? I don't think that this is a corner case.

Winston Prakash: Hmm... Good question. I haven't thought about that. As I mentioned, Consumer Module participates in the storage creation mainly to avoid lag during DnD of Service to the consumer (Especially VWP designer). In such case, I believe, consumer need to take the hit when the service is added to the project and create additional stuff it needs.

Web Services Node in the Services Tab document:

  • These WS service node is to WSDL oriented. I think we want to add REST WS in the near future. I think the plan is even for NetBeans 6.0. I know that this is not task of Sevices Tab.
  • Updating the Web Service - in the update will the WsServiceManagerExtension involved in the update?

Services Tab Web Services Public Contracts document:

  • WsServiceManagerExtension - this is problem, how it will be handled the situation, when a W/S Consumer module will be installed later.

Visual Web Consumer of Web Services from Services Tab

  • Adding Web Service to Project - you wrote that when the WS is dropped into a web project, all the client jars and the wrapper jar will be added into the project. Where are there added? Where will be displayed?
  • How it will be handled the contract between this and project? The Service Tab will work with all projects including J2SE. In other words, do you expect an SPI, which the project types need to implement?

EJB Node in the Services Tab document:

  • At first the document is to EJB 2.1 centric. You relay on the ejb-descriptor. But in the EJB 3.0, you don't have to have the descriptor and in the bulk of cases there is not. So I'm not sure how we will able to recognized the right interfaces from client jars.
  • I can imagine that the information about the installed EJB can be obtained via Server plugins. But it means that the server plugins has implement an spi for this.

Winston Prakash:This document certainly needs lots of re-write. Please feel free to assign the document to some one in your group who knows lot about EJB 3.0. I admit, my EJB knowledge is limited  :(

From Martin Adamek :

basically I like the idea of the common way for consuming the EE resources all around the IDE. I have few comments.

To the process of adding the API to IDE (as this is planned as IDE-wide feature, e.g Matisse is mentioned on few places), I would expect: - official NetBeans API review + link to assigned issue - official NetBeans UI review + link to assigned issue

To the name of the tab: - what about calling it just 'Bookmarks'? I should be able to drag EJB from Server node in Runtime tab (deployed resource) or from the project logical view (not yet deployed) directly to any designer or editor, or eventually I can add this resource to this new 'Bookmark' tab (or palette) if I want to use it often.

From Petr Jiricka : (3/7/2007)

Yesterday we had a discussion about the EJB functionality in the services tab and about the services tab in general between Petr Pisl, Martin Adamek and myself. I'll try to summarize what we discussed - Petr and Martin, please correct me or fill in if I forget about something we discussed.


1/ Regarding the EJB data binding feature for the visual designer, we believe there are three possible scenarios:

a/ The EJBs are deployed on the server by another entity, and the development team accesses the EJB interfaces through the deployed instances on the server. This happens when e.g. creating a client for an existing EJB application. b/ The EJBs are developed by another developer or another team than the client, but are a part of the same software project. So they are in the same source code repository, there is a NetBeans project for the EJB module, but this project is often not open in the IDE of the web client developer. c/ The EJBs and the web client are developed by the same person. In this case, the EJB project is open in the IDE.

Winston Prakash:Correct. All three are possible scenarios and we must support all three. Since in Creator we did only a/ (and I know about it), I put it in the spec.

Petr Jiricka:Currently, the functional spec: http://wiki.netbeans.org/wiki/view/ServicesTabEjbNodeFuncSpec supports only scenario a/, the other scenarios are not supported.

Winston Prakash: The only reason it is not there in the spec is, I do not know the specifics. I will gladly work with any one in your team to understand about b & c and include the specifics in the spec. But IMO, there is a generic support for b/ c/ (See below)

Petr Jiricka:Yet, we believe that in practice a/ is the least common case, scenarios b/ and c/ will be much more common. a/ is so rare that it may not be worth supporting, and we should only invest into supporting b/ and c/.

Winston Prakash: While, I certainly agree that b/ & c/ are common and thus must be include in the services Tab spec, out there, there are developers who rely on existing EJB components, developed by another team (may be in the same company). But this team may not have access to the EJB component source. Only way to access them is via Deployed Server (may be with in the company network).

Ludovic Champenois: Maybe, maybe not...I would love to have real customer surveys there regarding company teams not having access to the EJB source, and groups of developers (not deployers) sharing a 'deployed server'... One mistake the J2EE spec did is to artificially separate roles and we have yet to recover from that. The 'remotability' of independent EJB modules exposing EJBs APIs is imo less and less used, compared to either EJBs within the same EAR that the Web App, or published Web Services accessible via WSDL urls... The remaining advantage to EJBs (accessed via a web app package in the same EAR) is mainly the transaction management done by the container and not the developers...


Winston Prakash:Several such users are Creator users and I worked with them via Creator forum. To support such users we must also support a/. In fact we included only a/ in Creator because, out Marketing analysis showed that, the kind of developers Creator was sorting after, did only a/ most of the time. In order to widen the horizon of Netbeans to such market, we must support a/ along with b/ & c/.


Petr Jiricka:Here is a proposal for how scenarios b/ and c/ could be supported: First, there is a logical view in EJB projects that displays all EJBs (currently it's only enabled for J2EE 1.4, but it should be also enabled for Java EE 5). It should be possible to drag and drop an EJB from this logical view into the designer. Next, the IDE can provide a global list of session EJBs available in all open projects. These can be displayed in some kind of a UI - a global "EJB references" node is one option, but a better option could be to display these in the palette. This list would be dynamically updated as the user creates EJBs/deletes them/opens and closes projects containing EJBs. In addition, there could be a UI that would allow opening a project (that is not yet open in the IDE) and offering EJBs from this project - this would take care of the case when EJBs exist somewhere in the version control repository, but the EJB project is not open in the IDE.

Winston Prakash:I thought my Generic Services Spec (for all type of services) already covers this. If you look at my presentation slide (Slide 17). Ability to dynamically add or remove services via Service manager and other module interaction. Petr Jiricka:I am not looking for a "generic" specification. As Martin Adamek pointed out in his e-mail on March 5, what is needed is a very concrete UI spec for the exact UI that will be implemented, including the discussion of use cases. I did not see such a spec so far.

Winston Prakash:Assume, some module could discover the EJB being developed in a project or from un-opened projects from certain location and then it could create the corresponding EJB Service Descriptor (based on public API from EJB Service Manager) and add them to the manager. Using EJB Service Manager public API, this module could first create a group (say "Project EJB references"). Then add the EJB Service Decriptors to this group. Since EJB Node UI is listeneing to EJB Service Manager model change, it would immediately reflect the "Added EJB services" along with the group node in the UI dynamically. Now the user can Drag and Drop the EJB services to their project from this added EJB Node. I'm leaving the implementation details to who ever would implement based on this generic architecture.

Petr Jiricka: 2/ Regarding the overall UI of the "services tab".

We think the major issue with the current proposal is that 4 tabs open simultaneously are too many, because they don't fit on the screen well. See also the attached screenshot taken with screen resolution 1024x768 (which *is* a supported resolution). Also, the purpose of a dedicated "Services tab", which is only used for data binding, will not be clear to the user.

Dusan Pavlica:I completely agree with that 4 tabs (views) opened in the upper left corner of the IDE are too many and when we designed new Windows system and came up with concept of tabs we agreed that three tabs side by side should be the maximum there.

Petr Jiricka:We believe it would be better to combine the Runtime and Services tabs into one, with a suitable name.

Dusan Pavlica: We spoke about the right name for the Services tab and two variants occurred, "Services" and "Resources". I like both but more tend to use Resources, which could be more clear and discoverable name for all kind of users.

Petr Jiricka:We would only need to add the Web Services (and potentially EJB references, depending on the exact UI in this area) node to this tab. Also, the Runtime tab should be cleaned up, as it currently contains some UI that does not fit in there. In particular, I am planning to move the "HTTP Server" node out of the runtime tab; the "DTD and XML Schema Catalogs" node could also be a candidate for moving to another place. We believe that this can result in a cleaner and more comprehensive user interface.

Winston Prakash: I'm not hard fast on having a separate window. I'm leaving it up to the UI gurus (HIE team) to decide on which ever they feel may be right. As long as there is a parking place for "Nodes" corresponding to various services for user interaction, it should be OK. However, as you said, if we decide to use "runtime" tab, it should be renamed to some thing suitable.

Dusan Pavlica: Yes and I have already mentioned this approach (I mean clean up Runtime tab with different name) during Winston's presentation. And it's better to utilize existing concepts/parts of the IDE then create new ones sometimes. But is it doable for NB 6.0? Because I think somebody mentioned that it's not planned to be done for NB 6.0 release.

So, we have three possible places/solutions for the Services that have been mentioned so far: 1... Cleaned up Runtime tab with different name as it's described above

2... Another tab next to Navigator tab... and if the Navigator is empty at the start then we can hide it by default. Then there will be just two window areas (Projects/Files/Runtime area and another one below it in the same column: Services tab by default + Navigator in the same area when any project is opened).

3... Another tab next to Palette tab in the right column of the IDE's work place... This tab (and all views on right side of the Editor area) can be accessible only when some project is opened, so it can't be accessible without that. That's the disadvantage of this place.


Then we should consider discoverability of this services/resources tab according to another activity that is currently happening which is new Welcome screen covering all work place of the IDE. It means there will not exist tabs after the start of the IDE just one huge Welcome screen. I don't know more details about it just that some prototype is going to be implemented. So I can check actual state and I would like to discuss possible solution with the rest of the HIE team once again, when I return from vacation (March 12).

John Baker:In Creator we had the Palette and Server Navigator (similar to this Resources/Services tab) adjacent to each other.In some sense it made sense as drag and drop was started from the same general area of the IDE (easier to find if tabs have similar attributes). Resources aren't really used until a project is open, at least I thought this was one of the characteristics of the Resources/Services tab

Craig McClanahan: It is true that resources aren't "used" (in the sense of being a drag source) until a project is open, but it will definitely be common to configure resource entries external to the context of any particular project.

John Baker:So that we're on the same page, the availability or visibility of the Resources/Services tab didn't occur until a project was opened, is what meant. I can see that this would imply that the resources are project specific. This what I was trying to understand - will there be any resources that appear in the Resources/Services tab only when a project is created? We might want users to configure database access or configure a Theme before opening a project. These use cases really should be listed in a spec, as Petr suggested

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo