| Oracle Agile Engineering Data Management Architecture Guide Release e6.2.0.0 E52551-02 |
|
 Previous |
| Oracle Agile Engineering Data Management Architecture Guide Release e6.2.0.0 E52551-02 |
|
Previous |
Agile e6 Web Services expose a subset of the Product Lifecycle Management (EDM) functionalities of Agile e6. These services support functionalities provided by the EDM modules in Agile e6, such as Item Management, Project Management, and many other functions of Agile e6.
Implementation of Agile e6 Web Services adheres to the following principles:
Well defined, standards based discoverable Interface.
Java based Web Services Framework using Oracle WebLogic.
Modularized Agile e6 Schema (XSD) and WSDL for easy maintenance.
Standards-based WSDL to ensure compatibility across various clients (.NET, Java, and BPEL).
Bulk APIs wherever applicable for better performance.
The Web Services Framework is an additional layer on top of Agile e6, which supports inbound and outbound communication based on standard Web Services technology.
The Agile e6 Web Services Framework:
Provides the means to call External Web Services from inside Agile e6 LogiView Procedures (outbound direction).
Allows the external applications (Web Service Clients) to call the Agile e6 APIs through Agile e6 Web Services.
The Web Service Framework comes with a set of predefined core Web Services, which, out of the box, support the most common integration scenarios like create EDM object or get EDM object.
Agile e6 Web Services are deployed on an Agile e6 WebLogic application domain. The Agile e6 Web Services Framework comprises of the following:
Web Service Wrapper
To support the outbound Web Service calls from LogiView Procedures.
Core Web Services
To support the inbound Web Service calls mapped into the ECI-API calls.
Each wrapper has to implement the Web Service Wrapper interface, which prescribes the following method:
StringList callWebService(WrapperContext context, CallableParam args) <session-timeout><time-in-second></session-timeout>
The context contains all relevant information for the wrapper to perform the call. The wrapper then transforms the arguments to an XML payload for the outbound Web Service and finally makes the call.
If it is an asynchronous Web Service, the wrapper returns a string list with the correlation ID. Otherwise, it transforms the XML payload returned by the Web Service into a string list that is expected by the calling EDM Server process.
In case the wrapper is implemented in BPEL (or in any other external Web Service language), you require a special wrapper called the ExternalWrapper. This wrapper delegates the call to the respective external Web Service Wrapper.
For the outbound calls, you are required to use the External Wrapper to call an external Web Service or a BPEL process. However, you need to first implement an interface to adapt the External Wrapper. This interface is called as BPEL facade.
Normally, this facade should be a BPEL process that you implement. In this facade, you can invoke an external Web Service or BPEL process and create their business logic. All the facades should implement a standard WSDL. The External Wrapper uses this standard WSDL to generate the proxy. Then it can use different endpoints to call different BPEL facades.
Every call of an Agile e6 Core Web Service needs an EDM server instance. It is very important to limit the number of EDM Server instances to reduce the resource loading on the server. This is handled by the following mechanisms:
HTTP Session
The Web Service first tries to find an EDM Server instance assigned to the HTTP session of the current Web Service call. If it is found, the Web Service call uses the existing EDM Server instance.
EDM Ticket
An EDM ticket is returned in response to a core Web Service operation. This ticket can be used to access the same EDM Server instance that created the ticket.
While authenticating a Web Service call, if a ticket is passed instead of the password, the session manager uses the EDM Server instance, even if no EDM Server is assigned to the HTTP session.
The EDM ticket mechanism is the only way to let the calls to different core Web Service, such as Metadata or BusinessObject Web Service use the same EDM Server instance.
A Web Service client should use the EDM ticket as soon as it has called the first operation.
This is the only way to share an Agile e6 session between two different Core Services.
To free an EDM Server instance assigned to a Web Service session, the client calls one of the closeSession operations - every core Web Service provides this function - with the EDM ticket as the password. This shuts down the EDM Server instance and frees up the server resources.
The EDM Session Manager lets you manage the EDM Session objects which are used to keep the existing connections and user contexts to the EDM Server.
The key to an existing EDM Session object is the session ID, which is generated by EDM Session Manager.
The EDM Session provides connection to EDM Server.
To retrieve an EDM Session, EDMTicket is provided. When a new EDM Session is created, the EDMTicket is set to the EDM Session, which is then set into the SOAP message to the client side.
The lifecycle of EDM Session is the same as the given HTTPSession. The timeout of an HTTPSession is specified in web.xml with the following information:
<session-config> </session-config>
A Response contains a string that can be used in subsequent calls. This string is called the EDM Ticket. The ticket gives the caller access to the same Agile e6 instance (EDM server) that was used in the last request. The ticket remains valid only as long as the Agile e6 instance is running. After obtaining a ticket, the client code needs to configure the port by setting the ticket string as password.
The EDM Ticket improves the Web Service performance and simplifies the session management, If different Web Services are used in a use-case flow, which is very likely, the ticket returned by the responses of one service operation (e.g. Configuration.setUserContext) is used as a password when the client makes a call for another service operation (e.g. BusinessObject.getObjects).
The ticket sharing among different client ports eliminates the need for the server to start new Agile e6 sessions, which would result in new EDM Servers being started.
The Agile e6 PLM Authentication Provider is required to authenticate the incoming Web Requests. It is also used for providing the EDM user name and EDM Password to the Web Services to connect to the Agile e6 application.
The authentication provider is called by the WebLogic Security Framework. The Security Realm of the domain has to be configured to use the Agile e6 EDM Authentication Provider.
The following diagram depicts the authentication mechanism:
The PLM Authentication Provider uses the standard mechanism of the WebLogic server and can be configured with the WebLogic Administration Console.
The PLM Authentication Provider is installed at the time of Agile e6 application installation. A JDBC connection is made from within WebLogic, thus the user and password are the one for the JDBC data source.
For complete details on Agile e6 application installation, including the preliminary settings of the authentication provider, refer to the installation guides for Agile e6.2.0.0.
In the implementations where scalability is critical, a lightweight context management facility for authentication is available and its use is recommended. With this facility, authentication is managed by using a combination of user credentials and a sessionID token (the standard HTTP session ID maintained by the web container):
When user credentials are presented in the SOAP header of a Web Service request, formal authentication is performed prior to the application execution of the Web Service operation. If the authentication succeeds, the operation proceeds and a special SessionID token is placed in the SOAP header of the Web Service reply.
Whenever the sessionID is included by the client in subsequent Web Service requests, this sessionID will be used to restore cached session information, thus bypassing the substantially more time consuming process of re-executing the authentication.
|
Note: When presented with both, the sessionID and a valid set of user credentials, an attempt is made to use the sessionID before resorting to the user credentials and re-authentication. As expected, the session that is tracked by the sessionID is subject to expiration and other security checks. |
The facility is a distinct alternative to the basic authentication standard described by Web Services Security. Using the UserName token, as provided in Web Service Security, while fully supported as part of Agile e6 WSI Basic Profile compliance, will not yield the same benefit as using the higher performance session optimization facility provided by the Agile e6 implementation.
The core Web Services supports the feature FastInfoSet; by default it is part of WebLogic Service 12.1.3.
The StreamingFileSevice uses "Streaming MTOM" for file transfers from the client to the service host, which then does the upload/download to the nearest File Server and the callback to the EDM server to update the file metadata.
The Web Service single sign-on solution uses WebLogic and the SAML (Security Assertions Markup Language) protocol.
The following graphic depicts the possible single sign-on use case by using a web application in case of the single sign-on client.
WebLogic Domain A
Here, the single sign-on client is running and consists of a login JSP page and a Java servlet.
WebLogic Domain B
Here, the SAML protected Web Service is running.
The following steps are executed when the user performs a single sign-on with WebLogic and SAML Web Service authentication for Agile e6.
The user enters the login credentials in the login JSP page in the browser and sends the request to Domain A where the web application is running.
This domain is configured with a SAML Identity Provider and an LDAP provider.
Authentication occurs by contacting the configured LDAP server.
The servlet sends the Web Service request to Domain B where the SAML protected Web Services are running.
WebLogic attaches the SAML assertion (created by the Identity Provider) to the Web Service request.
The Web Presentation Service with SAML policy connects the Java Daemon, requesting to launch a user specific Application Server Process and to return the connection information for this process.
If it is a valid user and the SAML assertion is accepted by WebLogic on Domain B, the Web Service invokes the login procedures for Agile e6 and executes the Web Service.
Finally, the response is sent back via Domain A to the browser.
|
Note: or further information about single sign-on with SAML please also refer to the respective Oracle WebLogic Server documentation. |
The Web Service interface leverages all the performance benefits of a DFM infrastructure, by providing key Web Services in a local deployment at the DFM site.
It ensures that file transfer happens between the client and the local File Server, whenever possible.
The following graphic depicts the typical architecture and deployment at a remote DFM site in comparison to the central site of Agile e6.
For further information please refer to the Web Service Guide for Agile e6.2.0.0.
