Skip to main content

Controversial idea : OK so tell me why this idea is nuts!

14 replies [Last post]
mranga
Offline
Joined: 2003-06-06

I like to see services composed by message passing. I would like to loosen up restrictions on the JSIP RA so that SBBs may create listening points and providers on local host. This way you can compose services by just using SIP Requests locally within a SLEE rather than use SLEE specific mechanisms such as address profiles and shared activity context. This is more intuitive to SIP programmers.

So tell me why you all hate this idea ( I am sure I will hear groans).

Ranga.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mranga
Offline
Joined: 2003-06-06

Hi David,

Good to hear your thoughts on this. First, can you explain the Newzelandeze terminology "co-programming" :-) Natually, I am kidding, but I dont know what that means so if you can explain that would be great. I like your approach. Indeed, I have been thinking along those lines for quite some time. It should in fact be possible to have a low level SIP RA which exposes almost the entire JSIP API and build a Servlet-like enviornment on top of that.

Actually the latest JAIN-SIP spec is quite flexible and it should be possible to access all its features if necessary. It would be nice to allow the application the flexibility to use both JAIN-SIP in its entirity (all except those features that could be considered hazardous) and a pseudo-servlet model on top of that.

Also consider the Jiplet project http://cafesip.org which may be along the lines of what you have in mind.

Best regards,

Ranga

Message was edited by: mranga

david_ferry
Offline
Joined: 2006-05-07

Sorry for the long post but here goes:

So first on this idea of "co-programming" - there is probably some other phrase for it but we call it "co-written services" or "monolithic services" etc.

Anyway lets take a really simple example.

You have a number translation service, and you have a barring service.

Lets say both are originating services - so when you make an outgoing call you want both number translation and barring to run.

So in the most simple form we have 1 software component which represents number translation, and another which represents barring.

How do they both run together on the same outgoing call leg ? Hence the composition discussion.

Now with co-written services you end up with some application level programming construct where you end up composing a "translation and barring" service. You can design this various ways in the SLEE model so that components aren't tightly coupled but you end up doing some programming so that they work together. You always end up having to have your software components conform to some additional contract.

The co-programming might be as simple as a Root SBB entity which receives the INVITE, creates a child SBB for barring, if the barring app indicates that the call is allowed then the root creates the translation SBB and invokes it to get the translated number.

Co-programming is useful because the app developer can have close control on exactly what occurs.

The other end of the spectrum (and what I refer to as a protocol level approach) is where you take two apps (again barring and translation) but the difference is that instead of doing a software contract between the components you use a protocol contract.

E.g. if we want barring to run before translation, lets treat our barring app as a SIP proxy ... and then lets treat the translation app as a SIP proxy. Now since SIP can chain proxies together we just created a barring and forward app without doing any programming. Actually the barring and forwarding apps could be written on different platforms in different languages.

So the protocol or broking approach is useful if you don't have software environments that talk together, or if you don't want to integrate two different applications/services.

The idea of a SIP Servlet like SIP API for JAIN SLEE is seperate from composition via co-programming or composition via protocol - but its an API at a useful level of abstraction for a lot of SIP apps. In terms of opening this up - its something that OC are interested in doing. For our own bandwidth reasons we are wanting to get Sh up and discussed etc first, and also there is already some work being done on an improved JAIN SIP RA type and that is good stuff - so we dont want to distract that (because its good near term item - also we can consider to update the 1.1 SLEE PFD appendix etc to include it).

One reason why I think its the right thing to do after getting the JAIN SIP RA type a bit further along is that there are always issues if you take a J2SE API and try to put it into an app server environment. In our experience the solution is better if you make an RA type API designed for an app server environment.

ivelin
Offline
Joined: 2003-07-13

Good read. Thanks, David.

I am fine with the proposed RA Type standardization sequence - new JAIN SIP RA (1.2), Diameter Sh, then SIP servlet RA.

Ivelin

jbemmel
Offline
Joined: 2005-03-01

Service composition through message passing is fine. However, the composition logic would have to be decoupled from the services themselves.

If you build a service A that does some processing and then says "forward to B", it may look very flexible but in fact you move from loosely coupled services to some "thing" with hidden dependencies.

A second (more practical) argument against this is the performance hit. SipMessage object to ASCII bytes, send via the network layer, receive it back, parse it - these are all best avoided by passing such objects internally, rather than via 'localhost'

mranga
Offline
Joined: 2003-06-06

> Service composition through message passing is fine.
> However, the composition logic would have to be
> decoupled from the services themselves.

Jeroen,

Not sure I understand. A little explanation if you have the time would be appreicated. I was thinking use the Sip URI and route headers etc. to route requests in the normal fashion from service to service rather than using SLEE specific mechanisms - thus making it more intuitive for the SIP Programmer.

>
> If you build a service A that does some processing
> and then says "forward to B", it may look very
> flexible but in fact you move from loosely coupled
> services to some "thing" with hidden dependencies.

Not sure I quite understand this comment either. Can you elaborate.

>
> A second (more practical) argument against this is
> the performance hit. SipMessage object to ASCII
> bytes, send via the network layer, receive it back,
> parse it - these are all best avoided by passing such
> objects internally, rather than via 'localhost'

I am not so worried about this part. I think a simple hack would suffice to deal with this.

For example, I think the SIP stack can be easily optimized to realize that you are not traversing the network (i.e. routing a message back to yourself ) and hence it shoul d refrain from coverting the message to ASCII and back to a SIP Message. Rather it can just clone the Message and post it back to the event queue in this case.

jbemmel
Offline
Joined: 2005-03-01

Ranga,

Sorry I was a bit short, had little time when I posted this. See inline

Jeroen

> Not sure I understand. A little explanation if you
> have the time would be appreicated. I was thinking
> use the Sip URI and route headers etc. to route
> requests in the normal fashion from service to
> service rather than using SLEE specific mechanisms -
> thus making it more intuitive for the SIP
> Programmer.
>

My point was that both of these (i.e. SIP specific or SLEE native message passing) are pretty much useless, unless you have some mechanism to separate the composition logic from the deployed services. Hardcoding this into the service logic is not a good idea, IMHO.

> >
> > If you build a service A that does some processing
> > and then says "forward to B", it may look very
> > flexible but in fact you move from loosely coupled
> > services to some "thing" with hidden dependencies.
>
> Not sure I quite understand this comment either. Can
> you elaborate.
>

From your post I understood that you propose applications to call createSipProvider on localhost. Then they will also call sipProvider.sendRequest( r ) at one point, filling in Route headers / request URI to route 'r' to the appropriate next service. All of this (creation of local 'composition points' and routing between them) should be separated from the services themselves.

> >
> > A second (more practical) argument against this is
> > the performance hit. SipMessage object to ASCII
> > bytes, send via the network layer, receive it
> back,
> > parse it - these are all best avoided by passing
> such
> > objects internally, rather than via 'localhost'
>
> I am not so worried about this part. I think a simple
> hack would suffice to deal with this.
>
>
> For example, I think the SIP stack can be easily
> optimized to realize that you are not traversing the
> network (i.e. routing a message back to yourself )
> and hence it shoul d refrain from coverting the
> message to ASCII and back to a SIP Message. Rather
> it can just clone the Message and post it back to the
> event queue in this case.

True, it could do this.

mranga
Offline
Joined: 2003-06-06

> > Not sure I understand. A little explanation if you
> > have the time would be appreicated. I was thinking
> > use the Sip URI and route headers etc. to route
> > requests in the normal fashion from service to
> > service rather than using SLEE specific mechanisms
> -
> > thus making it more intuitive for the SIP
> > Programmer.
> >
>
> My point was that both of these (i.e. SIP specific or
> SLEE native message passing) are pretty much useless,
> unless you have some mechanism to separate the
> composition logic from the deployed services.
> Hardcoding this into the service logic is not a good
> idea, IMHO.

No I was hardly suggesting that. There has to be an external database where such information will be available. (i.e. one that says what request URI and Route address to use - be it local host or some other host). The point is SLEE Activity contexts, Activity context interfaces, fire event and assorted blah blah constrains you to a single host. This suggestion I am making does not. You can reconfigure your service mapping database and relocate your service in different hosts if you wish. After all, thats what request URI was meant for.

jbemmel
Offline
Joined: 2005-03-01

> No I was hardly suggesting that. There has to be an
> external database where such information will be
> available. (i.e. one that says what request URI and
> Route address to use - be it local host or some other
> host). The point is SLEE Activity contexts, Activity
> context interfaces, fire event and assorted blah blah
> constrains you to a single host. This suggestion I
> am making does not. You can reconfigure your service
> mapping database and relocate your service in
> different hosts if you wish. After all, thats what
> request URI was meant for.

In that case I was mislead by the 'on local host' part of your original posting. Why would SBBs need an additional 'local' SipProvider besides the 'external' one they already have?

What you are talking about is then more removing the restriction that SLEE message passing is only local. SIP (by nature) already gives you global message passing

mranga
Offline
Joined: 2003-06-06

> In that case I was mislead by the 'on local host'
> part of your original posting. Why would SBBs need an
> additional 'local' SipProvider besides the 'external'
> one they already have?
>
> What you are talking about is then more removing the
> restriction that SLEE message passing is only local.
> SIP (by nature) already gives you global message
> passing

Consider a service orchestrator that is an SBB and knows all about the wonders of the SLEE. Now that service orchestrator can be the sole reciever of events from the SLEE and from those SLEE events (which are SIP Request and Response events) it can extract the SipProvider. If we map sip provider to service on local host then it can route the incoming event to the appropriate service. Each Service is oblivious to the fact that it will run in a slee and as such is a JAIN SIP Listener (although it is not registered with the JAIN-SIP Stack -- the SLEE RA being the only such listener that is acutally registered with the stack). It is given a provider on which to run by the orchestrator and it consults the orchestrator to obtain Request URI and Route information to send request to the next service if needed -- and if that service is colocated then thats fine but not relevant. (This is sort of along the lines that the call flow scenarios have been put together in the JAIN-SIP TCK).

The SLEE of course offers its own mechanisms for service composition. Thus, the other way one can do it is the more SLEE oriented way -- i.e. use address profile, send request and have the other service be invoked using that address profile. In this case, the service has to be written as a SLEE SBB. Lots of learning for the programmer to do IMHO. A third way to do it would be entirely local - use shared activity context attributes etc. Again highly SLEE oriented.

IMHO, SLEE would do well to allow maximum flexiblity and let programmers capitalize on what they know. Hence, lets say we wanted to do a SIP Servlet like environment or a JSIP like enviornment inside SLEE, that should be possible to do. Reduces the SLEE learning curve. The way the SIP RA is being architected right now, one cannot make that claim.

jbemmel
Offline
Joined: 2005-03-01

> Reduces the SLEE
> learning curve. The way the SIP RA is being
> architected right now, one cannot make that claim.

I guess it's true what they say - "If all you have is a hammer, everything looks like a nail"

From a SLEE perspective they are trying to 'SLEEify' SIP / JAIN. What you are talking about here is to 'SIPify' SLEE. Wonder why that does not go down well with the SLEE developers...

But seriously, given that SLEE attempts to unify and abstract things, I think it makes sense (from SLEE perspective) to not introduce SIP-specific service composition, at least not to begin with. The question is whether this is viable.

You may end up with what I'd call 'fake abstraction' - e.g. everything is a message (or event or whatever), but some are more special than others. And you end up writing code like 'if (msg instanceof SIPMessage) { check that address profile is something with "sip:" }'

mranga
Offline
Joined: 2003-06-06

> > Reduces the SLEE
> > learning curve. The way the SIP RA is being
> > architected right now, one cannot make that claim.
>
> I guess it's true what they say - "If all you have is
> a hammer, everything looks like a nail"

Indeed :-). Was thinking the same thing myself.

>
> From a SLEE perspective they are trying to 'SLEEify'
> SIP / JAIN.

Whats the point of it? To program sensibly to the JAIN-SIP RA, you have to know JAIN-SIP. So why build an RA that has to conform to the SLEE abstractions of "Activity" and limit what it can do by imposing such artificial restrictions such as applications cannot create providers and listening points (even on local host). That simply takes away from the power of the JSIP API. Having said that, I understand why one cannot allow an app to listen directly to the stack and indiscriminately create listening points for security reasons. The way things are being proposed now, now expects a developer to know JSIP AND SLEE and yet you (not the literal "you") take away some JSIP capabilities for no good reason other than aesthetic ones. Thats relatively SLEEzy if you ask me. If something is being limited, I want a good reason why it is being limited.

> What you are talking about here is to
> 'SIPify' SLEE. Wonder why that does not go down well
> with the SLEE developers...

I'd venture a guess that there are far many more SIP (and I mean JSIP + SIP Servlet ) developers than there are SLEE developers at the moment and for some time to come. Therefore, it makes sense to not limit the RA and make such SIP-ification impossible. Would it not be nice, for example to have a SIP Servlet implementation live as a SLEE service? Can the current SIP RA accomodate that?

>
> But seriously, given that SLEE attempts to unify and
> abstract things, I think it makes sense (from SLEE
> perspective) to not introduce SIP-specific service
> composition, at least not to begin with.

The main point is not so much service composition as the fact that artificial restrictions are being introduced in the SIP RA that can limit evolution in the future (at least I think these restrictions are artificial).

The question
> is whether this is viable.
>
> You may end up with what I'd call 'fake abstraction'
> - e.g. everything is a message (or event or
> whatever), but some are more special than others. And
> you end up writing code like 'if (msg instanceof
> SIPMessage) { check that address profile is something
> with "sip:" }'

You have to deal with the JSIP API if you are programming to the JSLEE SIP RA anyway. So why partially restrict it?

jbemmel
Offline
Joined: 2005-03-01

> > From a SLEE perspective they are trying to
> 'SLEEify'
> > SIP / JAIN.
>
> Whats the point of it? To program sensibly to the
> JAIN-SIP RA, you have to know JAIN-SIP. So why build
> an RA that has to conform to the SLEE abstractions of
> "Activity" and limit what it can do by imposing such
> artificial restrictions such as applications cannot
> create providers and listening points (even on local
> host). That simply takes away from the power of the
> JSIP API. Having said that, I understand why one
> cannot allow an app to listen directly to the stack
> and indiscriminately create listening points for
> security reasons. The way things are being proposed
> now, now expects a developer to know JSIP AND SLEE
> and yet you (not the literal "you") take away some
> JSIP capabilities for no good reason other than
> aesthetic ones. Thats relatively SLEEzy if you ask
> me. If something is being limited, I want a good
> reason why it is being limited.
>

The reason is that you cannot have applications just randomly creating a bunch of listeningpoints, not only for security reasons but also for manageability reasons. You need a way to manage - at deploy time - which applications run on which ports

So to me it makes sense to not allow applications to create listeningpoints, as long as there is a declarative alternative in the deployment descriptor

david_ferry
Offline
Joined: 2006-05-07

Hi guys - I thought I would chip in on this thread.

Very briefly on service composition we have seen two different approaches, both which tend to get used together.

The first is at the protocol level, where you just want "SIP Services" to work together without co-programming. The second is at the app level where you want co-programming.

The SLEE spec gives the developer some programming tools to help with co-programming - ActivityContext, events, AC Naming, in the 1.1 spec writeable profiles.

In order to do a SIP specific protocol approach we have a different suggestion than what I have read here so far.

We do a new RA type for SIP - it looks like the SIP API from SIP Servlet ... rather than looking like JAIN SIP.

Therefore your onInvite in SLEE has the same looking code as the onInvite in SIP Servlet. The namespace is not the same as javax.servlet.sip because its not SIP Servlet - its a SIP API with a similar look and feel.

Inside the RA implementation you write a SIP specific composition model. E.g. each SLEE application can be an element of a SIP proxy chain - a virtual proxy.

JAIN SIP still stays around and gets updated etc, and you still keep a JAIN SIP RA - because it is a useful model of some layers in the SIP protocol. In fact you end up using the JAIN SIP API as the SIP stack inside this new RA implementation.

ivelin
Offline
Joined: 2003-07-13

David's feedback explains why there have been strong opinions on two different service compositions aproaches.

If the Open Cloud SIP servlet API is stable it is probably worth evaluating for wider adoption. I am not concerned with following exactly the SIP Servlet spec as it is actively evolving.

Ivelin