Micro API GW will not be lacking anything for API GW'ing when we're done. Else its a big problem for APIM.
We're currently re-thinking how server connectors work in Ballerina .. that's necessary to improve the handler like model we hacked up to make the APIGW work. Once that's done you should be able to write a "gw" that intercepts any kind of network traffic and does stuff .. whatever stuff (throttling, securing, analyzing, logging, etc.). We're going to be moving the APIGW to Ballerina platform. So you can come and help with that work - need to write a small OAuth keyserver in Ballerina itself. Should be easy .. are you volunteering? On Thu, Jan 18, 2018 at 1:48 PM, Sumedha Rubasinghe <[email protected]> wrote: > ok.. got it..stupid question. > was trying to piggy back on an existing implementation. :) > Micro API G/W is done on top of Ballerina. But is lacking other transport > supports. > > So the approach will be, > - take micro API G/W > - implement missing transports / connectors > - once Ballerina has streaming support powered by Siddhi runtime > everything will fall in to a single picture.. > > > > On Thu, Jan 18, 2018 at 1:33 PM, Sanjiva Weerawarana <[email protected]> > wrote: > >> Um .. Ballerina? >> >> On Thu, Jan 18, 2018 at 1:28 PM, Sumedha Rubasinghe <[email protected]> >> wrote: >> >>> *First, my definition of a (micro) G/W* >>> - connection point between the cloud, service impls, sensors, etc >>> - all data movements happen through it >>> - supports various transports / protocols >>> - deals with security >>> - ability to shadow/access throttle endpoints behind it >>> - cloud server provides the holistic view of all (micro) G/W deployments >>> - provides external integration points via APIs >>> >>> We have following options now. >>> >>> *Micro API G/W* >>> We have a micro API G/W doing pretty much of above capabilities. But >>> AFAIK it lacks following. >>> - limited transport support (only support HTTP and websockets) >>> - no streaming/event receiving support >>> >>> *Siddhi runtime:* >>> - consist of input/output adaptors covering vast transports/protocols. >>> - streaming / event processing capabilities >>> >>> But with not much of build in support for >>> - exposing APIs >>> - security verifications >>> >>> We are trying to rethink IoT G/W part within IoT Server to support >>> APIs, events and Streams. Right now it is built around C4 based API G/W, >>> hence supporting HTTP only. >>> >>> So wondering what is the correct path to take... >>> >>> >>> >>> --- >>> Sumedha Rubasinghe >>> Director - IoT Architecture, >>> WSO2 >>> m: +94 773017743 <+94%2077%20301%207743> >>> >> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairperson & Chief Architect; WSO2, Inc.; http://wso2.com/ >> email: [email protected]; office: (+1 650 745 4499 <(650)%20745-4499> | >> +94 11 214 5345) x5700; cell: +94 77 787 6880 <077%20787%206880> | +1 >> 408 466 5099 <+1%20408-466-5099>; voip: +1 650 265 8311 >> <+1%20650-265-8311>; twitter: @sanjiva >> Lean . Enterprise . Middleware >> > > > > -- > --- > Sumedha Rubasinghe > Director - IoT Architecture, > WSO2 > m: +94 773017743 <+94%2077%20301%207743> > -- Sanjiva Weerawarana, Ph.D. Founder, Chairperson & Chief Architect; WSO2, Inc.; http://wso2.com/ email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311; twitter: @sanjiva Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
