OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wsrp][all] WSRP Bi-Weekly Phone Call April, 18th




Dear WSRP TC Members,

here is the Agenda for the WSRP TC Call today 9 am PST / 12 pm EST / 6 pm
CET.

Attached, you find the relevant documents.


Accept Minutes from the last Call
---------------------------------

Duration: < 5 min

(see wsrp-minutes-2002-04-04.html attachment)

(See attached file: wsrp-minutes-2002-04-04.html)

Bob, thank you for the accurate minutes !


Monthly Sub-Group Reporting
---------------------------

Duration: 25 min

      Common Interfaces            (Alan) 5 min

      Interfaces & Protocol        (Mike) 5 min

(See attached file: InterfacesAndProtocolsStatus-April.htm)(See attached
file: InterfacesAndProtocolsStatus-April.doc)

      Pub / Find / Bind / Metadata (Mike) 5 min

(See attached file: PublishFindBind&MetadataReport-April.htm)(See attached
file: PublishFindBind&MetadataReport-April.doc)

      Markup Fragments & Styles    (Gino) 5 min

(See attached file: MarkupFragment-MonthlyReport-April.htm)(See attached
file: MarkupFragment-MonthlyReport-April.doc)

      Security, Identity & SSO     (Mark) 5 min

(See attached file: wsrp-security-April.htm)

Monthly report templates see MonthlyReportTemplate.* attachements below:

(See attached file: MonthlyReportTemplate.pdf)(See attached file:
MonthlyReportTemplate.htm)(See attached file: MonthlyReportTemplate.doc)


Business Scenarios
------------------

Duration: 20 min

In the last call we agreed that the scenarios will be posted to the mailing
list by 4/15/2002 ([wsrp][all])

I propose that we review scenarios in the order of posting, i.e. we start
with
- Content for Portals (Carsten) 10 min
  (see WSIASCenarioWebServicesForRemotePortals.htm and .doc)

(See attached file: WSIAScenarioWebServicesForRemotePortals.htm)(See
attached file: WSIAScenarioWebServicesForRemotePortals.DOC)

- Portals sharing Portlets (Carsten) 10 min
  (see Portals sharing Portlets.htm and .doc)

(See attached file: Portals sharing Portlets.htm)(See attached file:
Portals sharing Portlets.DOC)

In the next call, we can then review the remaining scenarios.


Comments on WSRP Overview Presentation
--------------------------------------

Duration: 5 min

(see WSRP Overview.ppt)

(See attached file: WSRP Overview.ppt)


Conference call details:
     In the US: 877-302-8255
     Outside US: +1 303-928-2609

When you dial in you will be asked for a "conference id".

The conference id is:  8814427


Best regards,

Thomas
Title: OASIS WSRP

OASIS WSRP

 Technical Committee

April 4, 2002

Teleconference 12:00 – 1:00pm EST

Minutes

Attendance at roll call, 12pm EST

 

Name

Organization

Attended?

Gino Filicetti

Bowstreet

Y

Srinivas Vadhri

Commerce One

Y

Bob Serr

Divine

Y

Peter Quintas

Divine

 

Alan Kropp

Epicentric

Y

Madoka Misuoka

Fujitsu

Y

Takao Mohri

Fujitsu

Y

Greg Pavlik

HP

Y

Angel Diaz

IBM

Y

Carston Leue

IBM

Y

Lothar Merk

IBM

Y

Thomas Schaek

IBM

Y

Rich Thompson

IBM

Y

Charlie Wiecha

IBM

Y

Bill Parducci

Individual

Y

Jon Klein

Lexis Nexis

Y

Adam Nolen

Lexis Nexis

Y

David Taieb

Lotus

Y

Petr Palas

Moravia IT

Y

Mark Cassidy

Netegrity

Y

Mike Friedman

Oracle

Y

Susan Levine

PeopleSoft

Y

Yossi Tamari

SAP Portals Israel

Y

Jeff Broberg

Silverstream

Y

Alejandro Abdelnur

Sun Microsystems

Y

Dave Clegg

Sybase

Y

Eilon Reshef

Web Collage

Y

 

 

 

 

 

 

 

Duration

 

12:00 pm – 1:00 pm EST

 

Chair

 

Thomas


Agenda

 

-          Approve Minutes

-          Hosting F2F Meeting

-          Revised Charter

-          WSRP Directory

-          WSRP Scenarios

-          Misc Items

 

Meeting

 

12:10 review of minutes

 

-          People have commented, Sasha will update minutes.

 

Thomas proposed that minutes are updated by next Monday; 2 more days for comments, then we post them.

 

Question: Do we post sub-group minutes on the web site.

Answer: Yes, but we need to organize it intuitively.  Leaders should send minutes to Lothar and he will post them.

 

12:10 face-to-face meeting

 

-          HP (Philadelphia), Oracle (West Coast) have volunteered to host the meeting

-          HP is part of both WSIA and WSRP; it might make sense to have HP host it next since we wanted to host them back-to-back

-          Mike: Oracle has a logistical problem in that nobody from Oracle will be at the first 2 days (since they are not on WSIA).

-          The last meeting was on the east coast.

-          Decision: we do the meeting on the west coast.

-          There is an OMG workshop in Orlando at the same time.  Nobody from WSRP said they would be going, but we don’t know about the numbers for WSIA (Charlie thinks it is a small number).  Charlie will take a day and poll people on WSIA.

-          Mike will need a confirmation to reserve dates and attendance at the conference center.

 

12:20 Charter

 

-          no comments; Thomas will publish to the website

 

12:20 Directory / Glossary

 

-          Jeff has received no feedback from the joint committees.  As soon as he receives feedback he will post an update

-          Send additions, changes, deletions: send them to wsrp and wsia mailing lists.  Jeff will reflect the changes into the document

 

12:20 Business Scenarios

 

-          Draft in 10 days (4/15 – 2-3 days before next meeting)

-          6 people volunteered to write scenarios:

o        Syndicated content – Bob Serr

o        Enterprise Application – Sasha

o        Publishers Portal – Karl

o        Current Awareness – Adam Noland

o        Corporate / WSRP Services – Tim Granshaw

o        Multimedia – Aditi

o        Mortgage Calculator – Alan Knopf

-          Template was sent around to document business scenarios; it is the same as the one used in the WSIA group

 

12:25 Misc Items / New Business

 

-          Document comments: put a tag around the comment, such as a <name>Comment</name>.  This way we can identify the comments when formatting is lost.

-          Can we share through a repository documents so we don’t have to continue sending attachments through emails?  Lothar will look into this (again we don’t want to cloud the website and we don’t want the public to see these docs yet).

-          Oasis hopefully will have something to support this in their infrastructure.

-          Apache has CVS; Oasis needs something like this (hopefully they have it).

 

-          Subcommittee Reporting: We will start this in 2 weeks.  Thomas would like to do it verbally in the meeting in addition to in written form.  The written form would be sent before the meeting so people will be briefed prior to the meeting.

-          Mike: would like to articulate sub-committee milestones in the status, but will use the summaries for detail.

-          Lothar will send a template for subcommittee reporting.

 

-          Thomas: gave a presentation at Java One about Java and Portlets, roughly 1000 people attended.  He mentioned WSRP and received a lot of interest.

 

 

-          Jeff: Can we have a short briefing of what the subcommittees are and the schedule of the calls?  Thomas will do this.

 

12:35 Meeting Adjourned

 

Title: Interfaces and Protocols Monthly Report

Interfaces and Protocols Monthly Report

 

Report for month of: April

 

Group Lead:Michael Freedman

 

Activities Finished:

 

Defined role and purpose:  this subcommittee will develop the requirements that will be used to define the API for the lifecycle and basic operations of portlets.

Basic terminolgy:  defined portlet service, portlet template, portlet instance, personalization data, and template settings

Described basic Portlet usage scenario: describes how a portal may interact with the entities defined by the above terms

Identified 90% of the core set of interactions/operations we want to focus on defining requirements for version 1.0 of the spec.

 

Activities in Progress:

 

Need to finish the discussion of what operations should be discussed as part of the core set.

Need to identify questions to resolve/requirements for operations in the core set.

Current ongoing discussion threads include:

management of personalization data.  Is it managed by the portal or the portlet?

actions and events. What are actions?  What are events?  Are they valuable enough to include in the first version of the spec?

terminology.  There is still ongoing discussions designed to clarify and tighten the terms defined above.

 

New Activities:

 

Need to idenitfy additional discussion topics that are pertinent but not included in operational set.  For example: form of SOAP message we will use.

Defining the requirements for the operations identified above.

 

Attachment: InterfacesAndProtocolsStatus-April.doc
Description: Binary data

Title: Publish, Find, Bind, and Meta Data Monthly Report

Publish, Find, Bind, and Meta Data Monthly Report

 

Report for month of: April

 

Group Lead: Michael Freedman

 

Activities Finished:

 

Activities in Progress:

 

Getting ourselves organized:  We have decided the Bind/Meta Data definition is a higher priority then Publish/Find.  We have decided that UDDI will only be one possible mechanism for Find, hence Bind operation must be defined on the portlet itself.  In general we are going to try and answer the follow:

What actions should a portal application be able to take based on the published metadata about a WSRP service? Metadata requirements should directly fall out of this.

Which metadata is required?  Which is optional?

Will we support an extension mechanism to allow vendors to include custom metadata?  Example scenario?

Specific details:

Publish:  no discussion yet

Find:  there is ongoing discussion concerning identifying/defining the tModel UDDI key in public/private UDDI servers.

Bind: no specific discussion though the topic is also on the radar of the interfaces and protocols group

MetaData: no specific discussion over and above the initial list we put together at the offsite

 

New Activities:

 

Put together a discussion document that lists the questions needing discussion.

Continue e-mail discussions.

 

Attachment: PublishFindBind&MetadataReport-April.doc
Description: Binary data

Title: Core/Toolkit/Object/DevMan Expert Group Monthly Report

Markup and Styles Sub-group Monthly Report

Report for month of:  April 2002

Group Lead:  Gino Filicetti

 

Activities Finished:

  • first conference call held on April 5
  • overview of areas of work discussed, the following high level items were agreed on:
    • Markup Rules
    • Visual Themes
    • Rewriting (including URL rewriting and Namespace encoding)

 

Activities in Progress:

  • discussions on Markup Rules for (X)HTML being held on the mailing list
  • overview document being prepared by David Taieb into which summaries of discussions and the results of our work will be captured.

 

New Activities:

  • next conference call to be held (tentatively) on Tuesday April 23, agenda as follows:
    • initial acceptance on list of restricted tags submitted by Carsten & Takao
    • discussion of items raised via email:
      • Eilon: Should we accept some tags but discourage their use, ie: <link>
      • Rich: Should the portal tell the portlet what the parent tag should be?
      • Sasha: Should we use a more robust mechanism for URL identification?
      • Sasha: Shall we let aggregators do unassisted URL rewriting?
      • Greg: Should we standardize on XHTML
    • Javascript issues, how will portlets use and/or expose JS methods?
    • And discussion on other items brought up.

 

Attachment: MarkupFragment-MonthlyReport-April.doc
Description: Binary data

Title: Core/Toolkit/Object/DevMan Expert Group Monthly Report

WSRP – Security Group Monthly Report

Report for month of:___April_______________________

Group Lead:________Mark Cassidy_________________________

 

Activities Finished:

1.  defined areas of focus for the group:

- portal identity, trust relationship between portal and portlet

            - end user identity, profile, and credentials

            - secure transmission of data

 

2.  Identified security-related standards efforts we will aim to leverage/be compatible with:

            - XML Signature(W3C/IETF)

- XML Encryption(W3C)

- SAML(OASIS)

 

 

Activities in Progress:

1.  Usage scenarios around the above topics

2.  Drilldown on requirements for each topic area

 

New Activities:

1.  Begin formal requirements document

Attachment: MonthlyReportTemplate.pdf
Description: Binary data

Title: Core/Toolkit/Object/DevMan Expert Group Monthly Report

<Expert Group Name> Monthly Report

Report for month of:__________________________

Group Lead:_________________________________

 

Activities Finished:

 

Activities in Progress:

 

New Activities:

 

Attachment: MonthlyReportTemplate.doc
Description: Binary data

Title: Business Scenario: Content for Portals

WSRP Business Scenario

Business Scenario: Content for Portals

 

Version 1.1

 

 

 

 


Revision History

Date

Version

Description

Author

27 January 2002

1.0

Initial Draft

Thomas Schäck

21 February 2002

1.1

Revision

Dr. Carsten Leue

 

 

 

 

 

 

 

 

 


Table of Contents

1.       Web Services for Remote Portals 1

1.1     Description      1

2.       Participants          1

2.1     ContentForPortlets Inc      1

2.1.1         Role            1

2.1.2         Relationships            1

2.1.3         Business Objectives            1

2.1.4         Solution Requirements            1

2.2     WESEREPOCON      2

2.2.1         Role            2

2.2.2         Relationships            2

2.2.3         Business Objectives            2

2.2.4         Solution Requirements            2

2.3     End-User      3

2.3.1         Role            3

2.3.2         Relationships            3

3.       References 3


Business Scenario: Content for Portals

1.                  Web Services for Remote Portals         

1.1               Description

ContentForPortals.com is a provider of visual, user-facing web services that plug-and-play with portals. ContentForPortals.com provides several visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc. This scenario describes the kind of business relationships that will become possible with the introduction of the Web Services for Remote Potals (WSRP) standard.

The subject scenario pertains to the proliferation of visual, user-facing web services that can be integrated and aggregated by portals in order to redistribute them to the users of those portals. This document will focus specifically on the consumption of  visual, user-facing web services by portal servers.

2.                  Participants

2.1               ContentForPortlets Inc

2.1.1          Role

ContentForPortlets.com offers a variety of visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc.

2.1.2          Relationships

ContentForPortlets.com offers their content to companies running portal servers either within corporations or on the Internet. Customers who want to use ContentForPortlets.com’s visual, user-facing web services to add value to their portals select the desired services and bind to them to make them available to the users of their respective portals.

In the subject situation, a big corporation known as WESEREPOCON wants to make some of visual, user-facing web services provided by ContentForPortlets.com available for their corporate users.

2.1.3          Business Objectives

ContentForPortlets.com wants to make their services available in a form so that portals across the world can find their services and bind to them with minimal effort so that the hurdle of using and buying their services is low.

2.1.4          Solution Requirements

§         Effective Publication: Allow ContentForPortlets.com to publish their services to a directory where all portals can find them easily.

§         Easy Integration: Allow portal administrators to find and bind to the visual, user facing web services of ContentForPortlets.com or similar providers with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used at client portals to optimize response times for the end users and avoid excessive load on the services provided by ContentForPortlets.com.

2.1.4.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols..

2.1.4.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Development and Publication

o        Develop visual, user-facing web services and generate meta data describing them

o        Publish visual, user-facing web services to a directory that can be accessed by many portals, along with metadata describing them

2.1.4.3     Usability

Ownership of Usability issue resides with the StockPlot client.

2.1.4.4     Constraints

Non-modifiable fields TBD.

2.2               WESEREPOCON

2.2.1          Role

WESEREPOCON runs a corporate portal for their employees. They develop and run custom portlets for business tasks specific to their corporation on their portal platform as well as personal information management portlets. In addition to these local portlets, they want to make external content available to their employees, including airport schedule information and the current stock quote for their company.

2.2.2          Relationships

WESEREPOCON licenses the desired content from ContentForPortals.com for use in their portal.

2.2.3          Business Objectives

WESEREPOCON wants to make relevant external information (flight schedules, current stock quote of WESEREPOCON, local news) available to their employees by just plugging it into their portal, without wasting any time for integration or even programming effort for special portlets to visualize the information.

2.2.4          Solution Requirements

§         Easy Integration: Allow WESEREPOCON portal administrators to find and bind to visual, user facing web services of many providers with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used to optimize response times for the users of WESEREPOCON’s portal.

2.2.4.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols..

2.2.4.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Finding and Binding

o        Find suitable visual, user-facing web services in a directory using appropriate portal admin UIs

o        Automatically integrate them into the portal as portlets (e.g. through portlet proxies)

o        Allow portal users to select portlet proxies representing visual, user-facing web service like local portlets

§         Run-Time Invocation

o        Invoke visual, user facing web services as appropriate

2.3               End-User

2.3.1          Role

As the final endpoint and actual Consumer of the ContentForPortlet’s visual, user-facing web services, the end-user represents the actual human user of the airport flight schedule and stock quote services. In this case they are users of WESEREPOCON’s portal.

2.3.2          Relationships

The end-user performs the actual interaction with the various visual, user-facing web services and is the ultimate trigger of all Run-Time use-cases associated with this business scenario.

3.                  References

 

 

Attachment: WSIAScenarioWebServicesForRemotePortals.DOC
Description: Binary data

Title: Information Sharing between Portal Servers

Business Scenario Document

Information Sharing between Portal Servers

 

Version 1.1

 

 

 

 


Revision History

Date

Version

Description

Author

21 February 2002

1.0

Initial Draft

Dr. Carsten Leue

Thomas Schäck

 

 

 

 

 

 

 

 

 

 

 

 

 


Table of Contents

1.       Web Services for Remote Portals 1

1.1     Description      1

2.       Participants          1

2.1.1         CentralPortalServer            1

2.1.2         Role            1

2.1.3         Relationships            1

2.1.4         Business Objectives            1

2.1.5         Solution Requirements            1

2.2     Client Portal      3

2.2.1         Role            3

2.2.2         Relationships            3

2.2.3         Business Objectives            3

2.2.4         Solution Requirements            3


Information Sharing between Portal Servers

1.                  Web Services for Remote Portals         

1.1               Description

LargeCompany is an enterprise that operates worldwide. It manages its internal information and services (e.g. backend access to legacy time management system) using portal servers. There exist several portal server clusters within the company at different locations.

LargeCompany would like to make it possible to share content between multiple portal server installations with a minimum of maintenance and administration effort. The services to share are visual, user-facing and should integrate seamlessly into each portal in which they appear.

In the current scenario LargeCompany would like to share a portlet that displays the company’s current stock price and a “tip-of-the-day” message with all other company portals. The visual design and content of this portlet are to be managed centrally.  The layout of the portlet may change frequently which means changes in either the portlet’s code or in the JSPs which render the portlet’s content. It is important that such modifications are immediately visible on all client portals.

For security reasons there must not be the need to install code on the consuming portal servers.

The subject scenario pertains to visual, user-facing web services that enable portals to share content with each other. This approach is not limited to sharing content between portal servers of the same type but only requires that the portals export their portlets adhering to the WSRP interface. This document will focus specifically on the exchange of visual, user-facing web services by portal servers.

2.                  Participants

2.1.1          CentralPortalServer

2.1.2          Role

The CentralPortalServer is a portal server that hosts the local TipOfTheDay portlet. It provides not only access to data stored on the server but also implements the visual design of the portlet. This visual design may change on a per-day basis.

2.1.3          Relationships

CentralPortalServer exposes the TipOfTheDay as a WSRP service and publishes it in the corporate’s private UDDI directory.

2.1.4          Business Objectives

CentralPortalServer wants to share TipOfTheDay information with all the company’s end users regardless which local portal server they are using. The effort to integrate the portlet into each portal server should be as simple as possible. As the portlet’s visual content often changes it should be managed centrally without any further interaction.

2.1.5          Solution Requirements

§         Easy Integration: Allow local portal administrators to find and bind to the TipOfTheDay portlet with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used at client portals to optimize response times for the end users and avoid excessive load on the CentralPortalServer.

§         Remote Access: Allow portals all over the company to access the presentation markup of the TipOfTheDay portlet via the intranet.

§         Request parameters: The user may enter data in input fields of the TipOfTheDay. These parameters must be transferred to the CentralPortalServer for processing.

§         User data: To personalize the content of the portlet the client may send parts of its user profile to the remote portlet.

§         Markup type: Portal users may connect to their local portal using a variety of different devices (browser, PDA, phone, etc). The content of the remote TipOfTheDayPortlet must take this into account and render its content depending on the requested markup type.

§         Language: LargeCompany is spread all over the world. Users want to connect to their local portals and get information in their preferred language. This is also true for the remote TipOfTheDayPortlet which must either be able to render its content in the requested language or to provide markup in a default language.

 

2.1.5.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols. This is key for an architecture in which remote content can be plugged into an existing portal without installing, writing, or modifying code. Because the interfaces are the same for all possible portlets, clients can use a generic local proxy to connect to the remote service.

§         Transfer of user data and preferences: The user of the local portlet may request different markup types and/or languages depending on his location and device. This information must be transmitted to the remote portlet with each request.

§         Binding: Prior to accessing the TipOfTheDay portlet remotely client portal servers must authenticate themselves to make sure that the portlet is only shared within LargeCompany. This step is required only once per portal by establishing a persistent binding between the two.

§         Persistent instances: Each user may integrate the remote portlet on a page in his portal server and configure personally. Such a configuration must be persistent both on the client and on the server side. If the user deletes the portlet locally the configuration information on the remote side may be deleted as well. This implies the need for life cycle management of portlet instances between the local and the remote server.

2.1.5.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Development and Publication

o        Develop an inspiring TipOfTheDay portlet with useful up-to-date information.

o        Publish this portlet to a directory that can be accessed by all portals belonging to the company, along with metadata describing the portlet’s configuration properties.

 

 

2.1.5.3     Usability

2.1.5.4     Constraints

 

2.2               Client Portal

2.2.1          Role

LargeCompany has portal servers throughout the world at many different locations. However there exists content that is of interest to the whole company and should be made available to all employees (e.g. the TipOfTheDay portlet). The client portal’s administrator would like to make this portlet available to his users without making them notice that it comes from a remote server.

2.2.2          Relationships

Administrators for client portals locate the remote TipOfTheDay portlet in a UDDI directory and import it into their portal server. Users of the client portal can integrate the imported portlet into their pages and view markup rendered by the CentralPortalServer.

2.2.3          Business Objectives

Allow information consumption from a central point across portal boundaries. In particular modifications of the TipOfTheDay portlet must not impose management costs on the client portal’s administrator.

 

The remote portlet should look exactly like any other portlet on the server (remote or local) and can be placed onto portal pages by users.

Once the administrator has imported the remote portlet, no further action by the administrator is required to keep the portlet up-to-date.

 

2.2.4          Solution Requirements

§         Easy Integration: Allow the client portal administrators to find and bind to visual, user facing web services of other portal servers with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used to optimize response times for the users of the client portal.

2.2.4.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols..

2.2.4.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Finding and Binding

o        Find suitable remote portlets in a directory using appropriate portal admin UIs

o        Automatically integrate them into the portal as portlets (e.g. through portlet proxies)

o        Allow portal users to select portlet proxies representing remote portlets as local portlets

§         Run-Time Invocation

o        Invoke remote portlets as appropriate

 

Attachment: Portals sharing Portlets.DOC
Description: Binary data

Attachment: WSRP Overview.ppt
Description: Binary data



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC